Re-Estimando Projetos de ETL

Em 2012 eu escrevi um post sobre como eu estimava o tempo gasto em projetos de ETL. Editorando a coletânea do GeekBI 2012 eu o reli, e fiquei horrorizado com os meus parâmetros: uma mísera estrela dava três meses! Tudo bem que eu incluía o tempo para implantação, estabelecimento do ambiente de desenvolvimento etc., mas mesmo assim é muito tempo para rodar a primeira iteração de um projeto. Em minha defesa, naquela época eu não via o mundo tão Scrum, e pensava ainda no formato cascata.

Hoje, quase três anos depois, eu já aprendi um monte sobre Scrum e Data Vault e não sou mais tão pessimista. Eu achava que não havia como algo não dar errado, e pior ainda, eu tinha certeza que construir as dimensões e fatos eram uma profissão de fé! Eu estava às voltas com coisas tão complexas, tão enroladas que eu realmente estava levando algumas semanas para construir uma transformação para carregar uma mera dimensão. Fatos, então, eram coisas aracnóides, de tantos ramos e ligações entre passos…

Vou refazer aquele mesmo processo, que eu continuo usando aliás, à luz dessas novidades. Vamos ver o que é que vai sair.

Introdução

Eu estimo a duração e o esforço necessários em projetos de BI baseado na minha experiência. Depois de alguns anos eu fiz uma nova auto-análise e separei passos que eu sigo mentalmente para chegar em um número inicial.

Coletando os Parâmetros

Antes eu ignorava intencionalmente a necessidade do cliente e encarava como parâmetro apenas a quantidade de dimensões e fatos – afinal elas traduzem fielmente a necessidade do cliente. Só que, à luz do Data Vault, descartar esse conhecimento “rouba” informações importantes, que são úteis para estimar o tamanho do projeto.

Por isso hoje eu começo coletando outras informações: uma maquete da necessidade do cliente (veja a figura abaixo.)

Descrevendo a necessidade do cliente.

A função dessa maquete é ilustrar que dados serão puxados dos sistemas de origem. Essa informação dá números importantes: a quantidade de hubs e satélites necessários, bem como a provável quantidade de links entre cada hub. Apenas para facilitar: entre dois hubs costuma haver pelo menos um link.

Daí eu procuro descobrir o seguintes:

1. Quantos analistas você terá dedicados integralmente a construir o DW;
2. Quantas fontes de dados você terá que tratar. Fonte de dados é tudo que possa vir a alimentar o DW: bancos relacionais de sistemas transacionais, files Adabas, arquivos texto/excel, páginas web etc.;
3. Quantas fatos e quantas dimensões o MD precisa ter atender para atender a demanda inicial.Esse item, no primeiro post, era o mais propenso a erros. Eu discutia como estimar a quantidade de dimensões e fatos a partir dos processos de negócio da empresa, pois eu acreditava que um DW Corporativo deve ser montado como estrelas ligadas a um barramento dimensional. Minha visão mudou, e agora eu entendo que o DW Corporativo deve ser a combinação dos dados historiados em um Data Vault e explorados em estrelas dimensionais. Graças a isso agora é muito fácil estimar a quantidade de dimensões e fatos a partir do protótipo: cada hub (e seus atributos) representam uma dimensão, e cada conjunto de métricas implica em uma tabela fato.No nosso exemplo parecemos ter uma dimensão (Item, com três atributos: Nome, Tipo e Origem) e uma fato, com uma métrica (veja mais adiante);
4. Volume de dados. Pode ser o tamanho de todas as bases de origem, em bytes, e quanto essas bases crescem por dia ou mês. Preferencialmente, pode ser a quantidade de linhas iniciais e os incrementos regulares (por dia ou por mês);
5. Se os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
6. Se os dados de origem estão limpos ou sujos, do ponto de vista do relacionamento entre as fontes. Por exemplo: os dados do cliente estão divididos entre duas fontes (CPF, RG e nome numa, RG, endereço e estado civil em outra; ela é suja se houver lacunas ou diferenças de formato na chave, o RG.)

Completando o Cenário

Para nosso exemplo precisamos completar a história. A partir da figura anterior podemos supor que existe pelo menos um hub (Item) e um satélite (de onde tiramos Nome, Tipo e Origem.) Usando essa informação podemos supor que o diagrama abaixo representa um Data Vault que atenderia essa demanda:

Provável Data Vault para a necessidade anterior.

Veja esse post para saber mais sobre esses objetos de um Data Vault.

Um Data Vault serve para acumular dados, não como fonte para análises. Se queremos analisar os dados que estão em um DV devemos primeiro levá-los a uma forma mais amigável ao usuário final. Isso significa construir um tabelão ou uma estrela com os dados que o cliente quer ver. A estrela do diagrama abaixo, derivada do Data Vault acima, atende a necessidade do cliente:

Provável estrela deste caso.

O Processo de Estimativa

Pelo que eu tenho visto, em média:

1. Uma equipe entrosada monta o ambiente de desenvolvimento (servidores, programas de desenvolvimento, repositórios, bases de dados etc.) em uma semana. Uma equipe desconexa leva mais ou menos o dobro;
2. Uma equipe pode levar até uma semana a mais para montar a linha de produção de um Data Vault;
3. Os elementos do Data Vault têm um teto de 1h/artefato;
4. A partir de um Data Vault, um desenvolvedor PDI proficiente leva até uma semana por dimensão ou fato;

Da primeira vez eu considerei que a quantidade de fontes de dados acrescentaria mais alguns dias nesse número. Esse impacto tende a sumir quando usamos Data Vault porque os dados já entram integrados, e a fonte de dados é tratada automaticamente na linha de produção do ETL de carga do DV. Eu diria que mesmo dados originados em arquivos ou via webservices podem ser intermediados por um banco relacional, e assim cair de volta ao caso mais simples.

Há duas técnicas de carga de dados em dimensões e fatos: trunca-e-recarrega ou carga incremental. Truncar e recarregar exige menos trabalho de desenvolvimento e mais do ambiente de ETL, enquanto que a carga incremental tende a custar mais em termos de desenvolvimento e menos em termos de infra-estrutura. Eu aventava a possibilidade de o processo levar mais tempo no caso de ser necessário desenhar essa a carga incremental. De novo, com o Data Vault na parada esse fato tende a ser minimizado por quê podemos postergar o desenvolvimento da carga incremental até que uma limitação de infra-estrutura nos obrigue. Podemos começar usando trunca-e-recarrega e, quando a infra-estrutura não suportar mais isso, refatoramos o projeto para carga incremental.

Você pode argumentar que isso troca “seis” por “três mais três”, pois no final acabamos fazendo “6”. Bom, o fato é que uma carga incremental nem sempre é necessária. Quando montamos o DW com outro modelo que não o Data Vault, essa decisão via de regra precisa ser tomada antes, porque a refatoração é cara demais ou até mesmo inviável. A refatoração é fácil se temos um Data Vault, e postergar decisões não-críticas passa a ser uma boa estratégia.

Alguns modificadores:

1. Obviamente, à medida que essa experiência aumenta, o tempo cai, e vice-versa. Assim, dominar a ferramenta, conhecer o modelo e os dados e já ter executado algumas iterações é o máximo da proficiência. Na ponta oposta está o novato com o software, começando o primeiro projeto de DW com dados que ele nunca viu mais gordos;
2. Sujeira nos dados. Esse é o fator mais selvagem. Tradicionalmente ele afeta a entrada dos dados no DW e tende a aumentar a complexidade do processo de ETL.Só que um Data Vault aceita tudo, inclusive sujeira, sem sofrer nenhum impacto no ETL. Devido a isso, os dados precisam ser limpos apenas na saída para a base que vai servir para exploração. Meu sentimento é que dados muito sujos podem até dobrar o tempo de desenvolvimento da carga de uma fato ou dimensão. Mas de novo, podemos começar aceitando dados sujos para exploração, e limpar à medida que o usuário demandar isso.Como o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo, eu descarto esse fator para estimativas.

Finalmente, e só para ter um número para fazer as contas, vamos supor que um desenvolvedor seja capaz de entregar 4H de trabalho útil por dia. Vamos dizer que o modelo de dados (de DV e Dimensional) já estejam diagramados, faltando apenas serem levados ao banco.

Estimando…

Então, para nosso exemplo, estimando pelos tetos e arredondando para cima, temos:

• 1 semana para iniciação do projeto;
• 1 semana para estabelecimento da linha de produção do Data Vault;
• ETL do Data Vaul: ( 1 hub + 1 satélite ) * 1 hora = 2 horas -> arredondando, 1 dia;
• ETL do Data Mart (trunca e recarrega): (1 dimensão + 1 fato) * 1 semana = 2 semanas.

Total: 1 semana + 1 semana + 1 dia + 2 semanas ~ 4 semanas

Parece muito, e é. Veja que a carga da dimensão e a fato que usamos de exemplo precisam de muito pouco trabalho, e não devem levar uma semana cada. Eu diria que a complexidade do exemplo dá um dia para cada um. Mantendo a inicialização do projeto em duas semanas (estamos sendo muito precavidos aqui), o desenvolvimento mesmo levaria três a 5 dias, ou uma semana aproximadamente. Novo total: três semanas de trabalho. Tamanho da equipe: um desenvolvedor (e seu eventual gerente.)

Lembrando que para isso já tivemos levantamento de requisitos e primeiro desenho do modelo de dados – estamos tratando apenas do ETL!

No post anterior eu estimava como três semanas o tempo para dois analistas. Eu não dava tantos detalhes do cenário, e na minha cabeça era um caso mais complexo – e por isso era mais “cara”.

A melhor parte vem na iteração seguinte, quando o custo de inicialização já ficou para trás.

Estimando Mais Adiante

Suponha agora que o cliente pediu mais duas estrelas (duas fato), envolvendo um total de 9 dimensões, e que todas serão construídas a partir de um Data Vault com trunca-e-recarrega.

Se cada dimensão equivale, grosso modo, a um hub mais um satélite, e há links entre diversos hubs, então o diagrama abaixo representa o nosso caso:

Diagrama DV para nova necessidade.

Cada hub aparece ligado ao “vizinho” por meio de um link, isto é, temos um link para cada par de hubs.

Exemplos:

H1 – H2 = Link 1-2

H2 – H3 = Link 2-3

etc.

Há oito links óbvios: L12, L23, L34, L45, L56, L67, L78 e L89. Para encorpar o problema vamos supor que há um link os hubs 3 e 6 (L36) e entre os hubs 3 e 9 (L39).

Isso dá (1 hub + 1 satélite) * 9 + 10 Links = 28 objetos.

E quanto ao modelo de dados que o cliente vai explorar? Nele temos 9 dimensões e 2 fatos.

Finalmente nossa origem é um único banco relacional, nossos dados são 100% limpos e teremos dois analistas (mais um gerente).

Estimando:

28 Objetos DV * 1H/objeto = 28 horas -> 28/40 Semana = 0,7 Semana
9 Dimensões = 9 Semanas
2 Fatos = 2 Semanas

Isso é o tempo gasto por um desenvolvedor só: cerca de 12 semanas ou três meses. Como a criação do ETL de cada dimensão é um processo independente de outros desenvolvimentos, podemos paralelizar a criação das dimensões. Assumamos, para simplificar, que desenvolver o processo de carga de uma fato depende da existência do processo de carga das dimensões usadas. Trocando em miúdos, o ETL para as fatos pode ser desenvolvido em paralelo, mas apenas depois do ETL para as dimensões.

Com dois desenvolvedores o tempo estimado cairia de 3 meses para aproximadamente um mês e meio.

No primeiro post eu ainda triplicava minha estimativa inicial porque eu via esse fator se concretizando nos meus projetos. Tendo desenvolvido um pouco com Data Vault, eu não sinto necessidade de incluir essa gordura. Muito pelo contrário, como o desenvolvimento de dimensões a partir de um Data Vault é um treco repetitivo, eu acho que esse tempo é até demais. Eu não vou cortar a estimativa, mas eu vou dizer que agora (com Data Vault) eu sinto mais previsibilidade nos projetos.

Finalmente, um overhead de gerenciamento continua existindo. Eu colocaria um mês para esse fator – nunca subestimo a capacidade de a burocracia nos amarrar!

Conclusão

E esse é meu chute, atualizado em função do que eu aprendi usando Data Vault. Lembre-se que estou descontado o levantamento de requisitos, documentação etc. e que mesmo achando que minha precisão melhorou, eu nunca ignoro o fato que estou tratando de uma estimativa, e nunca de uma medida – variáveis desconhecidas podem mudar tudo completamente, de uma hora para outra.

Continua valendo a mesma sugestão que encerrava aquele post: a quantidade de variáveis desconhecidas e incertezas berram pela adoção de Scrum como técnica de gestão. A propósito, eu adotaria três semanas como tamanho inicial das sprints, simplesmente porque rodei durante um tempo com sprints de duas semanas e me senti pressionado demais, o tempo todo.

E agora, o que você achou? Deixe seu comentário!

---

Washignton, tá liberado para dizer que este post é muito complicado! ;-)

Cruel Sucesso

Vou contar uma história usando Scrum, para simplificar. Mas se você conseguir imaginar um projeto Waterfall que dê certo, pode aplicar a mesma história, pois o resultado seria o mesmo.

No começo tudo são flores: o cliente e a equipe constroem o backlog do produto. Neste caso, uma prosaica solução de análise multidimensional, OLAP.

A equipe trabalha duro, sempre em contato com o cliente, e no final da primeira sprint conseguem demonstrar a ferramenta, instalada e funcionando, e uma estrela simples: uma fato com uma métrica de quantidade, e a dimensão Cliente. O usuário consegue, por exemplo, contar a quantidade de clientes por cidade ou estado. “Beleza, mas você vai me dar mais coisas, né?” pergunta o ansioso usuário final. Claro, reassegura-mo-lo, vai ter a sua estrela completa no final da próxima iteração.

Ao final dessa primeira demonstração o PO (Product Owner) e a equipe se reúnem para planejar a segunda sprint. O planejamento praticamente endossa o backlog anterior, com pequenas mudanças pontuais e inconsequentes. A segunda sprint começa, evolui bem e termina em ordem. Nova apresentação é feita para o cliente, agora com a primeira estrela completa. O cliente decide colocar o sistema em produção, mesmo faltando mais duas estrelas, previstas para a próxima iteração.

A apresentação ocorreu de manhã, e a retrospectiva à tarde. No dia seguinte o PO vem para o planejamento da próxima sprint.

É quando a porca torce o rabo.

Pensando Bem…

“… e este”, conclui o Scrum Master, “é o backlog atual.Acredito que vamos manter as mesmas demandas, não? Com isso nós vamos completar a primeira release do OLAP no final deste mês, daqui a duas sprints.”

O cliente olha no fundo dos olhos do SM e diz “Sabe, depois da apresentação ontem, eu voltei e pedi ao Sr. BI que me deixasse testar um pouco mais o sistema.” O Scrum Master olha para o Sr. BI, que olha de volta, inocentemente. “Ele deixou?”, pergunta o SM. Sim, ele havia deixado, e até respondeu algumas perguntas, tanto que ele se atrasou para o começo da retrospectiva. “E você achou algum problema? Quer cancelar a entrada em produção desta estrela?”

– “Não, claro que não. É que, pensando bem… Acho que as próximas estrelas não são bem o que eu preciso.”

Paciente e diligentemente, o Scrum Master e a equipe escutam as novidades, debatem para entender e ajustam o backlog.

Veja: estamos começando a terceira sprint. Da primeira para segunda, tudo certo. No final da segunda o usuário conseguiu usar o produto por umas poucas horas e, antes de começar a terceira ele pediu uma mudança. Tudo dentro do bem-comportado processo do Scrum e, até aí, nada demais.

Sprint 3

E assim a Sprint 3 começou. Como das outras vezes, a equipe buscava o PO para tirar dúvidas e manter o trabalho alinhado com o backlog, mas parece que os selvagens tempos das Cascatas insinuavam-se pelas frestas: o cliente tentou mudar o backlog quase todas as vezes!!

Não era intencional, claro, afinal o cliente sabe que sabotar a equipe de desenvolvimento causa só uma vítima – ele mesmo. Não, muito ao contrário. Ele queria evitar que a equipe entregasse algo pouco valioso. Por isso o cliente sempre estava preocupado em mostrar como, a partir da Estrela 1, que ele estava usando desde sua entrega no final da Sprint 2, ele havia descoberto que a Estrela 2 (e a 3 também) trariam uma dimensão incorreta. O grão dessas duas novas estrelas servia, para a análise que ele achava que precisava fazer, mas não serviriam para a análise que ele descobriu que precisa fazer.

Esse é um problema grave: havia um desalinhamento fundamental entre o backlog prometido no início da Sprint 3 e a realidade do cliente. Quando o cliente começou a usar a Estrela 1, ele começou a “entender” os dados, o negócio e percebeu que havia feito pressuposições, e que essas agora mostravam-se incorretas.

Cuidado Com o Que Deseja…

… por que você pode conseguir.

A maior marca de um projeto de BI de sucesso é o seu aparente fracasso.

Por quê? Porque um projeto de sucesso gera novas perguntas, que geram novas demandas de dados, que faz parecer que o projeto está sempre no início! Mas não! Ele deu tão certo que o cliente avançou e aprendeu – gerou Inteligência do Negócio a partir dos dados.

É nesse caminho que ia nossa história: assim que o cliente começou a usar os dados de uma entrega de sucesso, a compreensão do problema mudou. É uma consequência natural de se aprender mais: novos conhecimentos desafiam nossas antigas visões e percepções. Ainda que isso aconteça em projetos de outros tipos de sistemas, em soluções de Inteligência de Negócios essa dinâmica gera consequências complicadas.

Por exemplo, aonde vai nossa história? Como ela termina? Assim.

O Scrum Master sacou o problema e decidiu convocar um fim abrupto para a Sprint 3. O cliente sentou novamente com a equipe e refizeram o backlog. A Sprint 4 começou e seguiu sem problemas. A demonstração ao final conseguiu recuperar o moral da equipe – estavam de novo na crista da onda, entregando valor para o cliente! Yeah! Touchdown!

Começaram a Sprint 4, que agora ia incluir novas dimensões e estrelas para aumentar a comunidade de usuários. O PO agora eram duas pessoas: o primeiro cliente e um novo usuário do outro departamento. Montaram um backlog para as próximas três sprints e planejaram a Sprint 5. Enquanto isso o novo cliente passou a usar as estrelas que já haviam sido entregues.

E adivinhe o que aconteceu? Isso mesmo: ele percebeu que havia entendido algumas coisas incorretamente. De novo a equipe não conseguia andar na sprint porque o novo cliente não colaborava. Mas desta vez a recusa era hostil!

“Vocês atenderam o outro direitinho! Porque não querem fazer o que eu preciso? Isso que nós combinamos não estava certo! Agora eu percebo isso, e não adianta continuar, eu não vou usar o que vocês estão fazendo!”

Conclusão

Preciso continuar a história? A Sprint 5 foi abortada – de novo – e a sprint 6 e 7 replanejadas. A Sprint 6 saiu redondinha, mas o sucesso deixou uma sensação de desconforto ao invés de alívio. A Sprint 7 foi abortada, virou 8, que deu certo etc. etc. etc.

Estou montando esse cenário na melhor das situações, com equipe funcional e capaz, Scrum Master habilidoso, clientes inteligentes etc. Imagine uma empresa que desenvolva em Waterfall, com feudos departamentais disputando acesso e posse dos dados, usuários mal-preparados ou obtusos…

E esse é um problema ainda mais insidioso porque eu nunca vi ninguém percebê-lo. Por um tempo achei que eu estava viajando! A história acima tem um ritmo acelerado, e talvez a velocidade normal de um projeto seja um impecilho para identificar essa situação. Projetos de BI têm a bagunça da redefinição de requisitos como normal, como consequência da indecisão do cliente. Ainda que haja um nível de indecisão, não acredito que seja esse o responsável por fazer o projeto parecer retroceder periodicamente.

Se você não se identificou com a história, pense um pouco e tente se lembrar: algum de seus clientes parece estar sempre aguardando a próxima versão? Tem algum cliente que sempre volta pedindo alguma mudança? Um novo relatório, uma mudança na dimensão, outra agregação para a mesma métrica? Será que ele não está mudando os requisitos por que está aprendendo?

Da próxima vez que alguém reclamar que o projeto de BI está patinando, erga as orelhas: o projeto pode estar sendo vítima do próprio sucesso!

Até a próxima!

---

P.S.: eu não sei como lidar com isso. Eu ainda não consegui pegar um caso destes acontecendo claramente, e mesmo que tivesse pego, não sei se saberia o que fazer. Intuitivamente eu diria que precisamos deixar o cliente com o sistema a sós por algum tempo – uma semana? um mês? – antes de planeja a próxima etapa de desenvolvimento, mas duvido que algum cliente toparia isso…

Pentaho Day 2015: Eu Vou!

Semana passada eu tive a honra de ser convidado pela organização do Pentaho Day 2015 para apresentar uma palestra no evento. Este ano a coordenação está sob liderança de Márcio Vieira, da Ambiente Livre, e o evento será em Curitiba, dias 15 e 16 de maio.

Ontem eu recebi a confirmação que minha proposta foi aceita:

http://www.pentahobrasil.com.br/eventos/pentahoday2015/blog/fabio-de-salles-pentaho-day/

O tema é Introdução à Inteligência de Negócios – Nadando na Sopa de Letrinhas de BI.

Você pode se inscrever através do Eventbrite – basta clicar aqui.

Nos vemos lá! :-)

Todos os Caminhos Levam a um DW

No final de 2014 o artigo Monetizing Big Data: A Q&A with Wells Fargo’s Data Chief expunha a opinião de que DWs não são uma condição necessária para projetos de BI de sucesso. Concordo com ele em certos pontos, mas não de maneira geral. Eu não cheguei realmente a detectar uma tendência que defenda isso, mas vejo essa mesma opinião em fóruns e na propaganda de algumas ferramentas de visualização de dados.

O Prof. Goodnight, CEO do SAS, tem um excelente artigo no qual ele retruca a declaração acima. Leia ambos, são muito bons.

Assim como o Prof. Goodnight, eu também não acredito que DWs tenham chegado ao fim do seu ciclo de vida. Vou contar uma história, e no final eu volto para amarrar as pontas. Divirtam-se!

No Início Era o Excel

Para escrever meu livro Pentaho na Prática eu criei uma base de dados de treinamento chamada Beltrano S/A. Essa base reflete o sistema transacional da empresa fictícia chamada (adivinhe!!) Beltrano S/A, que é uma empresa de treinamentos.

Agora imagine que o Sr. Beltrano da Silva decidiu investir no crescimento da empresa, e se prepara para abrir filiais. Ele usa alguns sistemas transacionais para cuidar dos negócio da empresa, e começa a fazer perguntas. Cada pergunta que ele faz percorre um caminho dentro da empresa – ora pelo Financeiro, ora por Vendas, ora por Operações – mas sempre acaba caindo no mesmo lugar: a Informática, que é a responsável por manter os sistemas funcionando.

Porque lá, se eles não têm nada a ver com o negócio em si, mas apenas com as bases e os dados? É porque os “outros” empregados da Beltrano não sabem mexer nessas bases, ou simplesmente nem sabem que elas existem.

O Sr. Gerente da Informática recebe cada um desses pedidos e devolve arquivos com linhas e linhas de dados. Por exemplo, o Sr. Beltrano pediu ao Sr. Gerente de Vendas a lista dos 10 cursos mais rentáveis por região de São Paulo, e por Bairro. O Sr. de Vendas pediu ajuda ao Sr. da Informática, que fez uma consulta na base e trouxe a resposta para o ano passado, mês a mês, em um arquivo CSV. O Sr. de Vendas montou “um Excel” com esses dados, imprimiu e entregou na mão do Sr. Beltrano.

Invariavelmente e, para supremo desgosto do Sr. de Vendas, imediatamente, o Sr. Beltrano olha os papéis na mão do subordinado de relance e responde: “Jóia, e quebrando por X?” X pode ser qualquer coisa – cidade, bairro, curso, instrutor, estado etc. etc. etc.

Água Mole em Pedra Dura

Você conhece o final dessa história: de tanto vai e volta alguém decide que precisam achar uma forma melhor de fazer isso. Descobrem que o assunto responde pelo nome de “BI” e vão ao mercado buscar o que precisam.

Vem uma consultoria e diz que precisam de um projeto super-duper de DW. Caro demais.

Vem outra e diz que precisam de Data Mining, que depende de construir um DW antes. Caro demais ao quadrado!!

Outra empresa oferece as ferramentas de BI, poderosas, complexas e caras, mas nada de serviço. Caro demais e trabalhoso demais.

Finalmente uma das empresas mostra um produto interessante: caro, mas acessível, permite manusear facilmente os dados de qualquer base. “Precisa de DW, como o projeto de Data Mining?” Nããão, diz o fornecedor, é self-service (!), basta conectá-lo à base de dados e mandar ver! É fácil e simples!

Fechado! Na semana seguinte vem o CD. O Sr. da Informática instala a cópia no computador do Sr. Beltrano e configura para ler as bases.

O Paraíso na Terra…

Nos primeiros dias o Sr. Beltrano até se diverte, mas ele tem mais o que fazer e repassa o serviço para um dos membros da TI, o Sr. Analista. Esse novo usuário conhece as bases e sabe como extrair o que o dono precisa.

Funcionou! Um relatório, um gráfico, um painel, outro gráfico… Ficando mais complicado… Pegando mais dados…

Pá! O pessoal de vendas começa a reclamar que o sistema está lento. O pessoal do Financeiro começa a reclamar que o sistema está lento. A menina da portaria reclama que o sistema está lento! Sem dinheiro para mais computadores, o Sr. da Informática tem a idéia salvadora: gravar uma cópia dos bancos na máquina do Sr. Analista.

… Não Existe

De novo, funcionou no começo. O problema passou a ser outro: os dados ficavam defasados, porque a base inteira era muito grande para copiar, e não dava para sincronizar minuto a minuto.

Tudo bem, disse o Sr. Beltrano, não precisa minuto a minuto. Uma vez por dia basta.

Beleza: durante a noite, um processo automático copiava a base, que estava sem atividade àquela hora, do servidor para o computador do Sr. Analista.

Funcionou? Sim, claro.

O Que Foi Agora?!

O Sr. Beltrano não deixava o Sr. Analista em paz, e chegou o dia em que pediu um relatório comparando aqueles números com os do mês passado.

Fácil! A base da Beltrano já tem histórico: ela guarda todos os dados e pedidos e coisas que aconteceram na vida da Beltrano. Claro que, no começo, a base era diferente e por isso os dados de um ano atrás estavam em tabelas antigas, que não era mais atualizadas. Tudo: o pedido era só para um mês.

Funcionou, no começo.

A base guardava tudo que ela processava, mas a complexidade do modelo de dados, aliado à complexidade das perguntas de negócio fazia com que os cruzamentos – as consultas SQL escritas pelo Sr. Analista – crescessem em complexidade. A certa altura o Sr. Analista levava até dois dias escrevendo e testando e debugando as consultas.

O Sr. Beltrano disse ao Sr. Analista, suavemente, que precisa de um serviço mais rápido De qualquer *%$%@!$ de jeito!

Você Está de Brincadeira!

A idéia salvadora veio de Vendas: e se o Sr. Analista deixasse os dados pré-arranjados? Ele tem poder total sobre a cópia do banco dele, mesmo.

Boa idéia, pensou o Sr. Analista, e montou consultas que pré-combinavam os dados em novas tabelas, mais simples, sem relacionamentos com nenhuma outra e fáceis de se consultar.

Funcionou? Sim, claro, no começo… KKKKK

O sistema antigo estava chegando a seu limite e por isso o Sr. Beltrano comprou um ERP. Resultado? Ele ficou sem relatórios do novo sistema por quase um mês, até o Sr. Analista aprender o suficiente para repetir as mesmas consultas no novo sistema, mas ainda assim não era a mesma coisa. As tabelas eram diferentes, os dados guardados eram diferentes, organizados de maneira diferente.

O fato é que todo o trabalho do Sr. Analista foi congelado. O Sr. Analista voltou para a TI e contrataram um novo profissional, de BI, para ajudar o Sr. Beltrano. Mais um ou dois meses, e o Sr. Beltrano, agora com uma nova versão daquela ferramenta – lembram-se? – estava de volta ao jogo.

QUEREM ME ENLOUQUECER?!!

(Risos)

Bom, lembram do Sr. Analista? Que voltou para TI? Então, souberam disso. Fora da asa do Sr. Beltrano, o Sr. Analista virou presa fácil da empresa inteira: pediam relatórios para ele o tempo todo! Financeiro, Vendas, Operações, a moça da recepção, todo mundo conseguia pedir alguma coisa para ele, e o Sr. da Informática deixava.

E isso funcionava? Não, é óbvio!!! (kkkk)

O backlog do Sr. Analista crescia, as reclamações sobre o Sr. da Informática cresciam (ele era acusado de não deixar o Sr. Analista atender quem precisava de ajuda) e as reuniões de diretoria estavam virando um pesadelo de conciliação!

Vejam, o Sr. BI, auxiliar direto do Sr. Beltrano, montava gráficos e relatórios e tudo mais – e o Sr. Analista fazia exatamente a mesma coisa, mas para o restante da empresa inteira. Cada qual em cima de suas bases, com seus próprios critérios, a seu tempo.

Os números viviam a se explicar. Era quase um Inquérito Policial-Matemático.

Highlander na Parada

Os cérebros da empresa concluíram que a raiz do problema era o fato de cada um usar uma base diferente e critérios diferentes.

Reorganizaram a empresa: montaram o setor de BI, que cuidaria de uma base de dados única. O Sr. BI cuidaria dos relatórios e análises, e o Sr. Analista manteria e extenderia a base.

Ah, é! A esta altura, a base de dados corporativa era uma mixórdia de tabelas, scripts, comandos SQL, componentes de replicação blá blá blá. Os tempos de consulta estavam ficando maiores, e tabelas de apoio eram criadas quando necessário.

Os Portões do Inferno se Abrem

Enquanto na teoria o Departamento de TI rumava para o manso recanto da base corporativa e dos empregados dedicados, felizes e satisfeitos, na prática a tensão crescia: o backlog de demandas do Sr. BI (que agora acumulava o do Sr. Beltrano e o do restante da empresa) transbordava. As reclamações de prevaricação, justas e nem tão justas, abundavam. Volta e meia voava um dedo na cara de alguém. Horas extras foram jogadas na equação, mas resolveu pouco, porque o time de BI estava no limite da exaustão.

A solução é óbvia! Contrataram um ajudante para cada um, descartaram o antigo software do Sr. Beltrano, compraram um novo, com portal web e recursos de Business Analytics Self-Service Turbo Pro 2.0 etc. blá blá blá…

Aqueles Que Desconhecem a História…

No final, o cenário na Beltrano era apocalíptico:

• O ritmo de produção de análises e relatórios era lento…
• … por que todas as demandas da empresa passavam por dois empregados;
• Na tentativa de aliviar esse gargalo, dando autonomia aos usuários, mais software foi comprado…
• … e a demanda em cima do departamento de BI aumentou: além de atender os usuários do backlog, tinham novos produtos para cuidar.
• O processo de ingestão de dados na base corporativa não era automatizado…
• … o que ajudava a aumentar a carga em cima do departamento de BI.
• Os usuários continuavam tão insatisfeitos quanto antes…
• … e a sensação era de que “o BI” só atrapalhava.

… Estão Condenados a Repeti-la

Aos poucos alguns usuários mais espertos começaram a descobrir como acessar os dados da empresa, e conseguiam exportá-los para um Excel. Ali eles podiam trabalhar em paz, longe da zoeira que era “o BI”, e resolver suas necessidades.

Estava tudo indo bem, mas aos poucos o trabalho para manter aquelas poucas planilhas foi aumentando, as poucas planilhas viraram muitas planilhas, foram ficando mais complexas… O diretor de Vendas, que era mais desesperado, usou a verba do departamento para comprar um daqueles produtos self-service, se ligando direto nos dados.

E a roda seguia girando…

Data Warehouse São Obsoletos?

É claro que essa história é só uma invenção da minha cabeça. Mas, guardadas as devidas proporções, eu vi isso acontecer na empresa em que trabalho, e em outras empresas, através de relatos de amigos e conhecidos. Gente se queimando com chefe, chefe se queimando com diretor, e assim sucessivamente, no meio de uma bagunça de ferramentas e conceitos, com cada solução criando novos problemas mas nem sempre resolvendo os antigos.

Olhando só o que aconteceu com os dados da Beltrano S/A, o que vemos na história?

1. No começo é consulta direta (e usa-se Excel para análise dos dados);
2. Os dados passam a ser replicados integralmente (explorados com uma ferramenta mais adequada;)
3. A cópia em tempo real é pesada demais e um compromisso é atingido: a replicação passa a ser diária;
4. A cópia não basta: a complexidade dos dados força à sua recombinação a priori, antes da exploração – os dados começam a ser transformados durante a carga;
5. A demanda sobe, e o peso dos dados é aliviado com estruturas de apoio, como tabelas pré-agregadas e/ou normalizadas.

Neste ponto a ferramenta de consulta precisa estar à disposição da comunidade de não-técnicos que consomem aqueles dados. Isso causa um efeito em cascata de demanda, sofisticação crescente, dados de outras fontes começam a ser requeridos e por aí vamos.

Conclusão

Quem é do ramo sabe o que aconteceu nessa historinha: a Beltrano re-inventou a roda da bicicleta, um raio de cada vez. Eles partiram da idéia simplória de que os dados podem ser consumidos em seu estado bruto, para chegar na necessidade de centralização e organização dos dados. Caso contrário as contradições e falhas dos dados vão aparecer nos números construídos por cada usuário. No limite não haverão dois totais de venda do mês iguais na empresa inteira.

Um Armazém de Dados não é um projeto estéril, um capricho do povo de TI. É um “ser” que reflete a empresa e seu conhecimento, que muda e cresce continuamente. Um DW constrói e guarda a memória que a empresa, na figura de seus empregados, consulta para estabelecer relações, para responder perguntas, para tirar as dúvidas no momento de escolher a direção do próximo passo.

Por isso eu não acredito que DWs sejam obsoletos. Cada nova moda tecnológica traz promessas valiosas, mas somos nós, seres humanos, que realizamos essas promessas usando essas tecnologias. Por si só, elas são estéreis. Não existe mágica, só trabalho duro e recompensas ao final do dia.

A Opinião dos Fornecedores

Alguns fornecedores perceberam a armadilha em que se colocariam se defendessem a não-adoção de DWs. Por exemplo, este post do Tibco Spotfire de 2011 explica que, apesar de custar dinheiro, muito dinheiro, um DW é importante e dá boas explicações do porquê. Já este outro artigo, de uma empresa alemã de consultoria, oferece alguns comentários interessantes sobre DW, sua importância e a realidade típica de projetos de DW. Leia ambos, valem a pena.

Até a próxima!