Em 12 de janeiro de 2017 eu estive no evento DBTalk Liderança Ágil, tocado pelo meu ídolo agilista Jorge “Kotick” Audy. Foi uma hora e meia sendo soterrado por avalanche atrás de avalanche de assunto sobre liderança, Ágil, organizações, modelos, psicologia…
Como todo bom evento, semelhante a um boi, nada se perdeu, tudo se aproveitou. Depois de tudo que veio na palestra, ainda tive chance de bater papo com ele e muitas outras figuraças que estavam por ali.
É sério, não percam esse evento, que ocorre frequentemente em Porto Alegre, sede da empresa, e com alguma frequência aqui em São Paulo. É do balacobaco.
Uma dessas conversas foi o espanto geral de que há pouco, em termos de Ágil, sendo feito em Inteligência de Negócios. Na verdade é pior que isso: o pouco que eles viram fui eu que levou – um zé ruela qualquer. Fora o que este vosso humilde servo-zé-ruela fez, eles mesmos confirmaram que nunca viram nada.
E porquê? Por que tão pouco existe sobre BI, com Ágil?
Eu descobri essa resposta há muito tempo, mas só ali a minha “Guernica” 1 BI-Ágil ficou completa, só ali é que a última peça fez clique no lugar.
Por causa do cubo.
Adoro Kimball, tanto que fiquei muito triste ao saber que se aposentou – acabou-se minha chance ter aulas com ele. Mas o enorme sucesso de suas idéias acabou levando a uma absurda prevalência da Modelagem Dimensional em projetos de dados para BI. Como em geral são projetos de DWs ou data marts, acabamos sendo levados a pensar tudo em termos de cubos.
Estão acompanhando? Atrelada a projetos de BI existe uma forte cultura de modelagem de dados à moda do Kimball. Assim, nos acostumamos a “pensar” os dados de projetos de BI como organizados em cubos multidimensionais.
E – na minha humilde opinião – esse é O problema. É esse o motivo para existir tão pouca coisa de Ágil para Inteligência de Negócios.
Não sei se vou conseguir passar, aqui, por escrito, a minha percepção do problema e como intuí a resposta, mas vamos tentar.
O Mundo Não é um Quadrado em 3D
Para começar, há muitas necessidades em BI para as quais um cubo é uma abordagem inadequada, quando não atravancadora.
Um exemplo fácil é Data Mining
Resumidamente, Data Mining ou Garimpagem de Dados na minha tradução favorita, é um processo que parte de uma questão de negócios, como o que fazer para aumentar as vendas em 5%? ou como decidir quanto crédito fornecer a cada cliente, e usa Matemática sobre os dados disponíveis para construir um modelo da realidade. Realidade esta que não se apresenta clara, límpida e cristalina nos bancos de dados da empresa, mas sim como uma massa bagunçada e suja de dados oriundos de inúmeras fontes – sistemas transacionais, pesquisas, bases externas, canais diversos etc.
O resultado do processo de garimpagem é um modelo matemático que descreve a realidade, e a realidade é suja.
Para fornecer um resultado com algum grau de confiabilidade, Data Mining precisa de dados crús.
Por outro lado, dados limpos, como os necessários para análises multidimensionais típica, não refletem a realidade completamente. Erros, vazios, nulos, tudo isso é descartado para levar ao cliente uma estrutura com dados claros, que permitam interpretação sobre o que sabemos, já que não adianta especular sobre o que não foi capturado.
Na melhor das hipóteses, dados sujos são disponibilizados para análise com alguma marcação, como “Não preenchido”, “Inválido” etc. Empresas que sofrem com qualidade de dados fazem isso porque assim conseguem um mínimo de certeza em suas respostas. E alguma informação é melhor que nenhuma, sempre.
Outro exemplo? Claro: painéis.
“Como assim!”, exclamarão vocês, “painéis se dão muito bem com cubos!”
É, não posso negar que se dão bem, vocês quase têm razão.
Quase.
Como é mesmo aquilo que dizemos sobre martelos? “Para um martelo, todo mundo é prego.” Se você quer montar um modelo de dados dimensional, para tudo, vai estar condicionando tudo a uma visão dimensão vs. fatos.
Painéis tendem a aglomerar diferentes visões sobre um dado aspecto da sua organização. Logo, não raro temos em um único painel widgets apontando para diferentes fontes de dados. Diferentes origens.
Diferentes cubos.
Vou escrever ao contrário para ver se fica mais claro:
Preparar dados para um painel usando um único cubo requer a consolidação de diferentes grãos em um único, que sirva para tudo.
Caso isso não seja possível, precisaremos de mais de um cubo.
Logo, uma visão de cubos te obriga a transformar toda sua realidade, em que as relações são mais complexas que as relações de um modelo dimensional, em vários pedaços. Isso acaba destruindo a produtividade porque para cada pedaço você precisa passar por todo processo de desenvolvimento de modelo dimensional!
É isso que redime o setor de Data Discovery, meu eternamente incômodo e aborrecido setor de ferramentas para Data Discovery.
Não tenho nada contra ferramenta nenhuma! Mas tenho contra argumentos frágeis e superficiais! Leia aqui!
O que está no centro de uma ferramenta de Data Discovery não é a capacidade de produzir resultado sem precisar de um DW. Caramba, uma ferramenta de DD não tem nada que uma de BI não tenha! São absolutamente iguais!
O que destaca DD da prática tradicional de BI é que Data Discovery prescinde do processo de modelar um cubo como intermediário para análise! Você nunca pode se livrar de um DW porque o Tempo é a variável mais importante de todas, mas em nenhum lugar está dito que é obrigatório ter um cubo para historiar dados! O que no fundo DD faz é abrir mão de um horizonte de tempo maior em prol de maior velocidade na geração de valor!
Worlds Collide!
Eis aqui o Manifesto Ágil:
Manifesto para o desenvolvimento ágil de software
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
> Indivíduos e interações mais que processos e ferramentas
> Software em funcionamento mais que documentação abrangente
> Colaboração com o cliente mais que negociação de contratos
> Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Esse é precisamente o ponto:
Indivíduos e interações mais que processos e ferramentas
O que é que acontece quando colocamos um cubo à frente de qualquer resultado? Resposta: estamos valorizando o processo e a ferramenta!!
Por que é que temos tão pouco de Ágil em BI?
Que tal analisar o que existe de Ágil para BI listando os livros que tocam no assunto?
Entrei na Amazon.com e coloquei BI e Agile. Deu nisso:
Depois do terceiro resultado tudo ficava mais ou menos confuso – ou tinha pouco/nada a ver com BI ou com Ágil ou com ambos. Fechei a busca, e coloquei Data Warehouse e Agile:
- Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star SchemaNov 24, 2011
- Agile Data Warehousing for the Enterprise: A Guide for Solution Architects and Project LeadersOct 8, 2015
- Better Data Modeling: An Introduction to Agile Data Engineering Using Data Vault 2.0Nov 21, 2015
- Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault (Data Warehouse…May 20, 2012
- The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture)Sep 27, 2012
- Data Architecture: A Primer for the Data Scientist: Big Data, Data Warehouse and Data VaultNov 26, 2014
- Agile Data Warehousing Project Management: Business Intelligence Systems Using ScrumSep 28, 2012
- Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 21, 2016
- Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 19, 2016
- Extreme Scoping: An Agile Approach to Enterprise Data Warehousing and Business IntelligenceAug 15, 2013
- Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XPAug 5, 2008
- Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series)Feb 21, 2013
- Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Mar 21, 2013
Ou seja: muita coisa sobre DW e Ágil, mas pouca sobre BI e Ágil.
Ora, bolas, é a Amazon! Eles vendem, e isso enviesa tudo. Vamos procurar uma coisa mais abrangente, mais neutra: o Google!
(Claro que eu sei que o Google também enviesa os resultados. Na verdade, enviesa tanto que eu precisei remover a renca de anúncios que vinha antes do quadro acima. Mas é mais aberto que a Amazon.com, não resta duvida.)
De novo, foco em ferramentas! Ou quase. Se seguimos o link para a Wikipédia, achamos algo mais próximo de Ágil:
Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs.(…)
Opa, agora sim! “Ágil BI refere-se ao uso da metodologia de desenvolvimento de software ágil para projetos de BI, para reduzir o tempo-até-valor”! Eles até citam a “metodologia” que nasceu para resolver problemas de desenvolvimento de software, mas focam no que é importante: rápida geração de valor para a organização.
Curiosamente, essa mesma definição tem como referência produtos de software para “fazer BI Ágil”, um tal de Consensus e outro, Logix – nunca havia ouvido falar de nenhum dos dois, o que para mim é suficiente para colocar esse artigo em quarentena. Vou lê-lo e estudar essas ferramentas com mais calma e decidir se é mais algum fornecedor querendo surfar hype, ou se me parece válido, sólido.
Vamos refazer nossa pergunta: por que é que temos tão pouco de Ágil em BI?
Resposta: não sei. Mas se eu precisasse chutar algo, diria que é porque todo mundo entende que o tratamento de dados vem no centro de todo projeto de BI, que por sua vez está perpetuamente voltado para o modelo dimensional.
Colocando de outra forma:
IMHO, temos pouco de Ágil para BI porque quem se dedica a este assunto acaba preso na questão de produzir dados e não de solucionar problemas.
E eu acredito que, também IMHO, isso acontece porque o enorme sucesso da Metodologia de Modelagem Dimensional, de Ralph Kimball, criou em nós uma associação automática entre BI e Cubo.
Conclusão?
Dificilmente isto aqui é uma conclusão, pois eu ainda não cheguei nela. O que eu tenho, por enquanto, é a forte sensação de que o problema de produzir dados para projetos de BI está polarizando a aplicação de técnicas ágeis para BI, causando foco excessivo no desenvolvimento de cubos, ou seja, de modelos multidimensionais.
Eu ainda não achei uma evidência forte de que isso bloqueia o desenvolvimento ágil, ou de como esse bloqueio atuaria, se existir. Intuitivamente eu percebo que um modelo dimensional não é algo muito difícil de ser atacado com métodos ágeis, e até por isso mesmo há tanto material sobre esse assunto. Me parece que o fato de termos um modelo dimensional no meio do caminho entre a necessidade de negócio e a solução de BI é que atravanca as coisas, que por sua vez é justamente a causa aparente do sucesso do Data Discovery. E não podemos ignorar a frequência de fracassos de projetos de DW.
Por exemplo, se um DW cresce pela colagem de um cubo em outro através de dimensões comuns ou conformadas – a tal Bus Matrix – então cada nova necessidade acaba criando algum retrabalho ou uma nova expansão do DW. Eu estou começando a achar que o Modelo Dimensional permite muito pouco reaproveitamento. Quase como se, a cada nova funcionalidade de um sistema fosse preciso duplicar um pedaço grande do sistema, e customizar essa nova parte.
Como lidar com um armazém de dados construído para um único propósito – análise multidimensional – em uma empresa que pode possuir n demandas de m tipos para os dados, em que cada demanda requer praticamente um cubo próprio? E pior: como lidar com as necessidades operacionais?
Confuso? Para mim também. :-(
Eu acho que encontrei a solução (sim, tem Data Vault envolvido, claro!), mas ainda não está madura o bastante para sair aqui. Mas assim que estiver, você será o primeiro a saber.
Até a próxima! ;-)
- Guernica é o nome de um famoso quadro sobre um episódio da Guerra Civil Espanhola, pintada por Pablo Picasso. Sua interpretação é muito controversa. Uma das que eu ouvi é que é cheio de partes que representam aspectos do conflito, e tenta capturar a dificuldade que é, para uma mente humana, abarcar uma realidade complexa, cheia de nuances e contradições. Baseado nessa visão eu estou rascunhando um post que tenta mostrar como BI se assemelha mais à Guerra Civil Espanhola, complexa e cheia de partes, que a uma coisa como Física, que é feita de partes interconectadas e articuladas entre si. ↩