Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

A Informação em Perspectiva

Os Dados do Passado

A Estratégia de Aquiles

A Informação do Presente

O Futuro da TI

O Projeto EAGLE e os seus Dados

Índice

Os Dados do Passado

“No início”, eram os dados…

Enormes computadores chamados “mainframes” – com pouco mais do que sistema operacional e um banco de dados “relacional” – armazenavam os dados, em mídias no formato de [rolos de] fita magnética (primeira figura, à direita). Para “manipulá-los”, escrevia-se um “programa”, geralmente em Cobol, Natural, Assembler, LISP, FORTRAN, ALGOL etc.; que então eram “transcritos” para cartões perfurados (segunda figura). Na maioria das vezes eram necessários centenas [de centenas] desses cartões para “representar” um programa; e para executá-lo era necessário inserir os cartões em um leitor (primeira figura, máquina mais à frente, com a lateral cinza). O computador então “lia” as instruções, armazenando-as na memória (volátil, temporária): se há um furo, a energia passa = 1; se não, a energia não passa = 0 (os pontinhos pretos no cartão são furos; cada cartão com seu “padrão único”). E todos os monitores [então chamados de terminais] (UI – User Interface) se conectavam a uma rede diretamente conectada ao “computador central”, geralmente localizado em um CPD – Centro de Processamento de Dados.

Então, após uma breve fase de transição – na qual apareceram algumas “soluções” peculiares; como mini-computadores com a metade do tamanho de um fogão de quatro bocas, midi-computadores, etc. – surgiram os PCs. Os dados, os programas e as UIs permaneceram. As linguagens “evoluíram” (para C++, dBase, dBase III Plus, Clipper etc); os programas se transformaram em “sistemas”; os terminais começaram a se converter em estações de trabalho (WS – workstations); e, é claro, RDBMSs (relational database management systems) como o ORACLE e o SQL Server também evoluíram.

As “aplicações” de então se dividiam em [apenas] duas categorias: data-centric e content-centric. O “padrão”, ou melhor, o normal era assim:

  • Se meu foco está na área de publicidade, eu compro um MAC (da Apple), que dispõe de melhores recursos gráficos;
  • Se, por outro lado, eu lido com aplicações corporativas, como Folha de Pagamento etc., eu opto pela plataforma Windows (de preferência com um database ORACLE).

E era isso! Não havia uma terceira opção. O termo PC era usado para se referir a computadores de uso pessoal, privado, doméstico; não-profissional, não-corporativo. De repente estávamos na era dos ambientes [de duas camadas, ou layers] client-server, RDA – Rapid Development Applications [na qual, inclusive, o Visual Studio, “pegou uma carona”], HTML Forms, JavaScripts, AJAX, ASP (“clássico”) etc.

Esta “época” também testemunha o surgimento uma outra solução (ou pior, cultura) psicodélica, que – infelizmente – perdura até os nossos dias. De repente os usuários de PCs/WSs descobriram o “poder das planilhas”. Era [e ainda é, muito] Excel pra cima e pra baixo; Excel para todo lado, Excel pra tudo. Afinal, com algumas [dezenas de] macros e um pouco [cada vez menos “pouco”] de VBA, “eu” podia ter total “controle” sobre os “meus” dados. Ótimo para PCs domésticos! Horrível para WSs corporativas! Queiramos ou não [admitir], a introdução de planilhas em ambientes profissionais tem causado [muito] mais mal do que bem.

Em uma organização profissional não existe essa coisa de “meus dados”.

worldGrade

Em uma empresa em que trabalhei, por exemplo, havia um senhor – da área de QA, então chamada de Auditoria – que se orgulhava de manter uma super-hiper-mega-trans-incrivelmente-maravilhosa-completa planilha [na qual ele “investia” grande parte de seu tempo]. Tal “artefato” de gestão (gerado a partir de uma ferramenta) era, no mínimo [para não falar mal], redundante e supérfluo. A empresa, é claro, não podia se dar ao luxo de armazenar seus “sensíveis” dados corporativos ali, certo? Havia um permanente alto risco de inconsistência e falhas na comunicação (miscommunication), com graves potenciais impactos nos “processos de negócio”; ou seja, nas ações, tarefas e funções executadas por “colaboradores” que eventualmente baseassem suas “atividades” e decisões em tais dados, certo?

Em outra empresa, mais recentemente, tínhamos o [excelente, diga-se de passagem] hábito, cultura, regra, obrigação de nos reunir semanalmente, para o “alinhamento” e “sincronização” das nossas metas e responsabilidades, individuais e coletivas. No entanto, apesar das planilhas [às quais eu logo passei a recusar dar crédito ou atenção] serem versionadas e armazenadas em um repositório central (o SharePoint, no caso [outra “todo-poderosa” “ferramenta” mal compreendida e, subsequentemente, mal utilizada]); era incrivelmente surpreendente a frequência com que falhas na comunicação nas decisões originavam-se em informações derivadas da inconsistência de seus dados (basta a alteração do valor em uma única célula da planilha para impactar o conteúdo de numerosas outras).

Então eu percebi que as pessoas não percebem/percebiam [claramente, pelo menos] a “enorme” diferença entre dado e informação. E isso, meu caro, faz “toda” a diferença… Afinal, lidamos com TI – Tecnologia da Informação, mas falamos em Banco de Dados, não é mesmo? Em uma planilha [bem como em uma tabela de banco de dados], por exemplo, o conteúdo de uma célula é simplesmente um valor; que só adquire o “status” de dado quando analisado em relação às suas respectivas coluna e linha [e a seus meta-dados], ou seja, em relação ao seu “contexto”. Da mesma forma, um dado precisa ser analisado em relação a um contexto, para que possa ser considerado uma informação. E como existem vários contextos, uma informação só passa a ser de fato útil e relevante quando o analisada em relação a um [determinado] contexto mais abrangente. Simples [e lógico] assim.

data piramids

Source: Google Images

Figura 1. Data Pyramids

Em uma organização profissional [de qualquer tamanho], dados devem ser armazenados primariamente em databases (DBs); e o “comportamento” dos sistemas é [ou deveria ser] derivado – em última instância – dos processos de negócio que os definem, de uma forma ou de outra [e aqui está o “calcanhar de Aquiles” de muitos “sistemas”]. Muito, radicalmente diferente do que ocorre em uma planilha, na qual toda a lógica é definida em segundo plano, por trás das cortinas [under the hood], através de fórmulas, macros e rotinas VBAs [atômicas, isoladas, e potencialmente contraditórias] “espalhadas” arquivo “adentro”.

Com o tempo a tecnologia dos DBs foi evoluindo, e hoje em dia os mesmos estão “muito bem, obrigado”. O problema é que são muitas vezes mal utilizados [e/ou implementados]. Conceitos como normalização e ERM – Entity Relationship Model, entre outros, quando aplicados corretamente, resultam em excelentes DBs, que cumprem a sua função com maestria [o problema via de regra está naquela pecinha que fica na frente do monitor, em cima da cadeira]. E é claro que os outros recursos de um DB devem ser igualmente bem (criteriosamente) utilizados. Triggers, functions e stored procedures (SPs), por exemplo, nos permitem adicionar “comportamento” ao DB [com o poder/potencial de alterar o “estado” de seus dados] – mas tais comportamentos deve[ria]m se restringir ao “contexto” dos dados (segurança, integridade etc.), sem jamais contemplar regras de negócio.

Na verdade, existem exceções a esta “regra”; mas estas devem ser tratadas como exceções, como casos extraordinários, e não como regras – como sói acontecer no mais das vezes. Além do mais, tais exceções deveriam ser consideradas somente a posteriori, após a implementação e a validação das regras de negócio externamente ao DB, como uma extensão [plugável, de preferência, loose-coupling]; exclusivamente para fins de “confirmação” das regras, em cenários em que os dados possam ter sido corrompidos ou alterados (hackeados) durante o seu trajeto pela rede. Embora comum e apropriada nos tempos de soluções de duas camadas (UI – DB), esta prática de implementar regras de negócio em SPs está obsoleta; é deletéria e arriscada, e deveria ser criteriosamente empregada, pois aqui está o outro calcanhar do Aquiles.

page

A Estratégia Aquiles →

Como cuidar da saúde de seus calacanhares corporativos.

A evolução dos DBs avançou, então, para o “reino” dos DW/DMs – Data Warehouse – Data Mart; seus mecanismos [processos] de ETL – Extract, Transform, Load; e seus “serviços” de data mining. DWs são basicamente grandes DBs não-normalizados e read-only, otimizados para desempenho/performance, utilizados para armazenar dados “históricos” para análise e reporting [aqui].

dwFlow

Source: Google Images

Figura 2. Data Warehouse

DMs são subsets de DWs, e representam a camada de acesso a seus dados [aqui]. Mecanismos de ETL se baseiam fundamentalmente em “scripts” [aqui] que definem a transferência de dados entre dois ou mais “bancos” (storages). E “data mining” é um termo muitas vezes mal utilizado [até por livros] e representa um (sub) processo do KDD – Knowledge Discovery in Database [aqui].

↑ Topo ↑
 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: