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:

Ágil e BI na Amazon: livros sobre... DW?
Ágil e BI na Amazon: livros sobre… DW?

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!

Ágil e BI, segundo o Google: ferramentas?!...
Ágil e BI, segundo o Google: ferramentas?!…

(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! ;-)


  1. 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. 
Anúncios

9 comentários sobre “A Culpa é do Cubo!

  1. Meu caro e saudoso amigo. Que bom que vc escreveu sobre isso!!! Pois eu acho muito natural descobrir as coisas, resolver problemas olhando os dados brutos para tirar minhas conclusões e chegar ao fatos de fato!!! Desculpe-me pelo trocadilho infame, mas não resisti.
    Concordo com você, pois na minha opinião e pela pouca experiência com meus consumidores de informação, sempre achei que não adiantava eu entregar um Cubo bem feitinho e bem modelado, cheio de painéis, pois eles não conseguiam tirar muita inteligência e fazer um bom uso.
    Quando aparece um problema para analisar ou resolver, ou ter uma visão do que está acontecendo com um processo, eu faço meu BI em cima dos dados crus que coleto na base de dados e depois de fazer todos os cruzamentos de dados e conseguir obter a resposta e fazer uma análise do cenário, aí sim, penso que esse resultado e essa análise poderá ser insumo para um Cubo, ou seja, um Cubo já mastigadinho, quase um Cubo mágico, onde o usuário final vai brincar e ter visões do problemas ou solução, e por diferentes faces.
    Não sei se deu para entender, mas estou adorando seus estudos sobre Ágile BI, pois esse tema também me interessa muito, e concordo, deve ser independente de ferramenta. Ferramenta é só um assessório. nada como vasculhar nos dados, e tirar conclusões e padrões.
    Precisamos marcar um café, um Happy Hour, para divagar mais sobre essas questões.

    1. Um não, vamos marcar para tomar DOIS cafés! Hehehe… Saudades, minha amiga! Estava mesmo pensando em vocês por esses dias. Como anda tudo por aí? Vamos conversar, sim – apenas marque e eu aparecerei!

      Eu sempre fui de querer fazer tudo certo, quadradinho, e por muito tempo insisti no fluxo Data Mart -> Análise, encarando o tempo gasto nisso como um custo para obter bons resultados. Hoje eu acredito que estava errado: estou começando a entender que o gargalo na análise de dados não é a construção do ferramental (e a qualidade desse), mas a cabeça do usuário. O que levanta essa restrição é facilitar o entendimento do negócio e dos dados pelo usuário. Construir um modelo melhor ou mais inteligente não produz esse efeito. O que gera esse efeito é justamente colocar o usuário o mais rapidamente possível em contato com os dados, o que justifica o sucesso do movimento “Data Discovery”. O que vem depois é que faz a diferença: usar essa compreensão para melhorar tudo. Ou seja, ciclos rápidos de descoberta e melhoria. Ágil. Você tinha a resposta o tempo todo. :-D

      Hmm… Data, Agile. É… Boa idéia… Você é ótima!!!! Já achei isso na Web: livros, posts e até um site chamado Agile Data! :-) Me aguarde aqui!

      Um grande abraço para você e outro pro Sílvio! Mande um alô a ele por mim, please! ;-)

  2. Grande fábio, realmente esse é um assunto instigante. Atualmente o que eu faço é fazer uma consulta num tabelão giganteee com os dados para o cliente analisar no própio excel e a partir daí instigar o usuário a ter novas visões,idéias, necessidades, e com isso diminuir o impacto de retrabalho no desenvolvimento do ciclo tradicional, quase que totalmente cascata urgh!, do “cubo” requisitos>modelagem>etl>cubo>dashboards. Enfim, aquele velho ciclo engessado, mas que “funciona”.

    Partilho da sua opinião a minha, acredito que no futuro o BI tradicional vai morrer, principalmente com esses banco de dados nosql analiticos novos (vertica, greeplum, ect), hadoop, tecnologias de big data, clusterização ,etc. Acredito que o futuro esses dados vão estar espalhados dentro de diversos arquivos e nosso poder de processamento de cargas e consultar vai ser tão absurdo que não iremos nos preocupar em construir cubos, modelos, etc. A unica preocupação será garimpar esses dados para gerar valor ao negócio.

  3. Graaande Jairo! Tudo em riba? Pois é, com certeza o processo clássico não funciona mais. Me parece que ainda há um certo grau de bagunça (e uma boa quantidade de hype) no nosso futuro. Pense comigo: o que impede alguém de “garimpar” os dados hoje para gerar valor? Concorda que nada nos impede? Podemos ter limitações no volume de dados acumulado e na performance das análises, mas em princípio, tudo que se promete fazer com novos “datastores”, já pode ser feito, tanto que o é há decadas. Vai daí que a forma na qual o dado está armazenada, em si, é irrelevante, não achas? ;-)

  4. Achei muito sentido para minhas pesquisas aqui nesse artigo. Obrigado!

    Eu sou Scrum Master de uma equipe de Softwares com o desafio recente de viabilizar o início de um BI para a instituição de ensino em que trabalho. O meu primeiro ponto de pesquisa foram os processos necessários para a construção do BI.

    Como escalonar meu projeto? Qual a equipe e competências adequadas? Como fazer as perguntas certas para montar meus painéis? Como conseguir entregar valor incremental?

    Não achei também nenhuma resposta amigável pra isso. As ferramentas sempre vem antes. As empresas que contatei pra me ajudar não querem nem entender o problema. Querem simplesmente vender seu Software e sua metologia.

    Ainda não achei as respostas para as minhas perguntas também, mas foi legal ver que tem alguém com a visão ágil trabalhando com BI – um assunto ainda tão obscuro pra mim.

    Valeu camarada. Ainda estou viajando nos seus posts. :)

  5. Grande Fábio! Por gentileza dedique um post a essa apresentação para aqueles meros mortais que não poderão ir ao evento ;(…. e também não custa nada divulgar quando achar a solução abaixo:

    “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.”

    Compartilhe conosco para futuros debates e possíveis evoluções rsrs.
    Abraços

    1. Já está no forno, Jairo!! :-) Faz algumas semanas que eu não posto nada justamente amadurecendo a apresentação – e para não estragar as surpresas (eu vou abrir com videoclip! Vai ser uma farra!) Na semana seguinte à apresentação soltarei os slides aqui, com qualquer novidade que eu tiver bolado depois do evento.

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