Agile BI?

Em agosto de 2005 eu lancei um mini-curso sobre como fazer levantamento de requisitos para projetos de Business Intelligence. O que diferenciava aquele curso da prática tradicional era ser voltado para projetos ágeis. Você pode ver aquele post clicando aqui, conhecer o curso aqui e assistir ao vídeo promocional seguindo este link.

O assunto é interessante por demais da conta. Nestes dois últimos anos eu tenho me dedicado a estudar como melhorar a implementação de projetos de BI e DW usando técnicas ágeis. Tenho visitado palestras, lido artigos pela web, conversado com inúmeros profissionais. O resultado desse envolvimento todo apareceu na minha palestra do Pentaho Day 2017, BI E.V.A., que teve uma boa recepção junto à comunidade Pentaho.

Hoje eu recebi um e-mail da TDWI, um respeitado instituto de Data Warehousing. O assunto? É óbvio, né?

Agile BI.

E-mail do TDWI convidando para um curso de Agile BI.

Claro que eu tinha que ver do que se tratava. Eis o conteúdo prometido:

  • Agile modeling values and principles
  • Techniques for determining the right level of up-front design
  • How to avoid overbuilding solutions by designing for what is needed
  • Domain modeling
  • Data model patterns
  • Data smells and the impact of technical debt
  • Continuous integration
  • Safe refactoring techniques for making incremental design changes
  • How to determine the right level of design documentation that is needed
  • Effective collaborative modeling practices for cross-functional teams
  • How to minimize the amount of unnecessary rework through reference and conceptual designs
  • How to establish iteration zero as an agile practice that gives teams the runway to start delivering

Hmm… Interessante. Uma das coisas que eu comento no BI E.V.A. é que há muito sendo discutido sobre como se transformar o processo de modelagem de dados, em especial Modelagem Dimensional, em um processo “ágil”. No fundo, o que muito da literatura tem pregado é como incorporar Scrum ao processo tradicional.

Eu já fiz isso, e não adianta.

Pense um pouco: o cerne de ser ágil é prover melhoria contínua. Mas o cerne de um processo de modelagem dimensional é entender a necessidade do cliente. Não é muito evidente, mas o fato é que essas motivações são incompatíveis. Ainda não tenho um argumento finalizado e por enquanto eu recomendo a leitura das notas da apresentação BI E.V.A. – é o melhor que eu consigo no estágio atual.

Ainda não é uma Conclusão

Voltando ao curso do TDWI, o que é que eles oferecem? Uma outra abordagem ao processo de modelagem de dados? Não.

Um outro modelo de dados? Não.

Uma outra forma de tratar os levantamentos de requisito? Não. (Meu curso faz isso.)

Eles propõe “modelar apenas o suficiente para galvanizar o cliente e desenvolvedores ao redor de uma compreensão compartilhada do domínio do problema, arquitetura e modelo de dados”.

Ou seja: adotemos ágil e, na hora de construir o modelo de dados, vamos fazer apenas o mínimo para começar. Do que se depreende que desenvolvimento incremental, aqui, deve ser “uma dimensão por história”, “uma estrela por épico” ou coisa do tipo!

Foi exatamente o que eu tentei. Deu resultado, mas ainda não me permitiu os fantásticos ganhos de produtividade que Scrum normalmente proporciona. Leia “Scrum: a arte de fazer o dobro do trabalho na metade do tempo” para saber do que é que eu estou falando. ;-)

Ganhos fantásticos!

O que eu acabei descobrindo é que o que atrapalha o desenvolvimento ágil – incremental – é a dificuldade de expressar a necessidade do cliente de modo que permita correções e ajustes, o que acabou me levando a rever o problema por outro ângulo.

Então este é o estado do BI Ágil, hoje?

Claro, existe mais sendo feito por aí. Quem leu o Building a Scalable Data Warehouse with Data Vault 2.0, por exemplo, viu uma outra abordagem. Mas ainda não nasceu algo que verdadeiramente habilite a construção de projetos de BI e DW calcados nos fundamentos ágeis – melhoria contínua, incremental, articulada.

A busca continua! :-)

Anúncios

Pentaho Day 2017 – BI E.V.A.

Neste exato momento estou assistindo a uma palestra do Pentaho Day 2017, ao qual eu tive a honra de ser convidado como palestrante. Minha palestra foi ontem, dia 11/5/17, e chamava-se BI E.V.A. – Enxuto, Valioso, Ágil. Ela teve uma recepção muito boa, acima do que eu esperava, e estou muito feliz de ter podido proporcionar aos participantes algo que eles tenham gostado.

Neste link você pode baixar um PDF das notas, que traz os slides e todos os comentários que eu “fiz”.

BI E.V.A.

O clipe do começo pode ser assistido neste link, para o Youtube. É o videoclipe Houdini, do Foster The People.

Foster The People – Houdini.

Eu estava salvando minhas (poucas) idéias para o Pentaho Day 2017. Agora que passou, voltarei a postar com mais frequência, focando justamente os temas de valor, agilidade e lean em BI.

É bom estar de volta. :-)

A Culpa é do Cubo!

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. 

Livros

Mais ou menos uma vez por mês eu entro na Amazon, seção de livros, e digito “dw” ou “bi” ou “data mining” ou algum jargão da nossa área. Eu reviso a lista resultante e vou separando (clicando com o control apertado, para abrir em outras abas) todo e qualquer livro que eu ache interessante. Reviso essa seleção mais uma vez e escolho um ou dois para ler.

A última rodada me trouxe quatro livros do balacobaco.

Impossible Data Warehouse Situations

O mais divertido de todos, de longe, foi este:

Impossible Data Warehouse Situations.
Impossible Data Warehouse Situations.

É um livro antigo, do início dos anos 2000, que aborda um rosário de problemas comuns em implementações de DW. Por exemplo:

  • Quando o protótipo vira produção;
  • TI é o assassino;
  • Clientes não sabem o que querem, clássico dos clássicos!
  • A quem o time de DW deve se reportar? (CIO, gerência de departamento etc.)

Ou seja, problemas comuns. Por que, então, o título de situações impossíveis? Bom, justamente por serem comuns é que são impossíveis: impossíveis de se evitar, quase impossíveis de se resolver.

E nenhum destes problemas faz parte de nenhum curso de DW. Pode olhar, pode procurar. O máximo que você vai conseguir achar é um professor mais experiente que passou ou resolveu algumas destas situações, e vai te contar alguma coisa se você perguntar.

Dessa constatação temos o valor que esse livro possui: inestimável. Até porque não é um autor prescrevendo soluções mágicas, mas sim um painel de profissionais gabaritados que dão sua opinião a cada tópico.

Veja esta situação, como exemplo:

  • Should a line of business build its own DM?

Ou, no meu tradicional e macarrônico estilo de tradução, “um departamento deve construir seu próprio DW?” Ela é descrita, contextualizada e daí vários dos colaboradores do livro dão sua opinião. Alguns são bem rasantes, outros são mais acadêmicos, uns são pé-no-chão enquanto que outros, viajantes. Assim você acaba sempre com várias visões e idéias e propostas para o problema – uma riqueza enorme!

A resposta desse exemplo, para mim, vale ouro. Vários foram quadradinhos, “sim, porque o DW é a coleção dos Data Marts” ou “não, porque o DW é uma coisa centralizada”. Bah, isso eu já sei. Mas aí vem a Jill Diché, minha favorita: go togheter with IT. Ou seja, aproxime-se da TI e ofereça para dividir a carga: você colabora com profissionais e ganha, em troca, priorização. Como é você quem vai fazer a sua parte, você recebe antes. Isso deixa o departamento feliz, a TI feliz (porque tem mais mãos para trabalhar) e não aborrece os consumidores que competem com recursos! Gênio!

E o livro está cheio dessas!

Claro que, com essa idade, alguma coisa acaba datada, como essas duas “situações impossíveis” por exemplo:

  • O sistema de origem muda continuamente; ou uma variação
  • O sistema de origem está passando por uma mudança.

As soluções propostas são de gerenciamento, mitigação de riscos e fortalecimento dos padrões e do modelo dimensional. Hoje em dia temos outra opção (já sabe, né? Data Vaul!), mas mesmo assim não é uma mudança tão grande.

O livro fala sobre negócio (mal-entendidos, desinteres, motivação), times (disfuncional, prima-donas, encrenqueiros), clientes (chatos, ruins), chefes (burros, preguiçosos ou bagunçados), técnicas (metodologia, falta de conhecimento, de experiência), padrões (usados errados, sem padrões), ferramentas e qualidade dados, entre outros.

Como eu disse, adorei esse livro. Não consigo deixar de mencionar outros dois favoritos meus, dos padrões:

  • Os empregados usam a terminologia de maneira errada;
  • Tudo é Data Mining.

:-D

Clinical Intelligence

O nome inteiro do livro é enorme:

Clinical Intelligence: The Big Data Analytics Revolution in Healthcare: A Framework for Clinical and Business Intelligence

E ele fala exatamente isso: como usar os conceitos e idéias de BI aplicado ao campo da Saúde. Há algum exagero e um pouco de mal-entendidos, mas nada que prejudique a idéia central.

Por exemplo, ele separa BI e Analytics (item 1.2, paǵina 26), e classifica machine learning, pattern recognition e predictive modeling como motores (engines) e – não bastasse – ainda por cima diferentes. Como se um padrão não fosse um modelo preditivo, e coisas nessa linha. Dá para suspeitar um pouco se ele realmente chegou a entender tudo do que fala, mas – torno a insistir – não compromete o resultado final. Apenas leia com algum resguardo, pois ele não é da área de BI.

Já na parte que realmente interessa, meus caros, ele arrebenta.

E o que realmente interessa é o índice do capítulo 2:

Sumário do capítulo 2.
Sumário do capítulo 2.

(Peço perdão pela baixa qualidade da imagem. Puxei-a do site da Amazon, e ele não estava colaborando muito…)

Vêem? Ele mostra um tipo de análise para cada um dos vários assuntos médicos! Tem desde aspectos administrativos, como casos de uso, scorecards e indicadores diversos, a complexos modelos de atendimento clínico e previsões de custos, passando por modelos de predição de osteopatia e acompanhamento de antibióticos.

Na boa, esse é o livro de cabeceira de QUALQUER gestor de saúde. Quanto mais abrangente a responsabilidade desse gestor, mais importante se torna esse livro. Em outras palavras: leitura obrigatória para secretários e ministros da Saúde, ponto.

É uma leitura que eu passei meio por alto, afinal eu sou um alien para esse campo. Eu me detive apenas nas partes de BI (onde ele faz uma zona com alguns conceitos, acerta outros e se embanana todo com ainda outros) e matemática (em que ele, aparentemente, coleta trabalhos feitos por diversos outros times, uma coisa absolutamente normal, aceitável, afinal, só um ser sobrenatural poderia saber tanto sobre tanta coisa diversa.)

Agile Data Warehouse Design

Este livro tem uma proposta muito bacana: estabelecer uma metodologia para captura de requisitos para DW adequada a projetos ágeis, e ágil em si mesma.

Cara, ficou ruim. Deixe-me tentar de novo:


Este livro tem uma proposta muito bacana: explicar um método ágil de capturar requisitos para DW, requisitos estes adequados a projetos de gestão ágil.


Bem melhor!

Ágil como em ninja, não como em rápido.
Ágil como em ninja, não como em rápido.

E seria um livro excelente não fosse tão… poluído? Pesado? Foi difícil lê-lo do início ao fim, e eu falhei nisso – depois de um tanto saí pulando até onde aguentei. O método é interessante, parece que funciona e não é difícil. Acho que o maior galho dele é justamente ser uma receita de bolo. Ele tenta passar um conhecimento “situacional”, ou seja, de como agir em cada situação, e fica tão cheio de exemplos e detalhes e senões que a coisa toda fica pesada, trabalhosa.

A sensação é que, uma vez assimilado esse conhecimento, a coisa flui. Assimilá-lo é que parece mesmo um trabalho duro. E, já que estou no assunto, ele não resolve os problemas típicos de projetos, nem de projetos de DW, justamente como aqueles colocados no Impossible Situations – esse mesmo, sobre o qual escrevi acima.

Vale a pena ler? É, pode ser que sim. Se tiver tempo, com certeza. Mas não me parece uma daquelas técnicas que abalam o mundo, como – adivinhe? – Data Vault ou Análise Bayesiana. Mesmo assim, ele agrega.

Até porque eu cheguei numa técnica semelhante, muito mais modesta e de alcance muito menor, mas na mesma linha. ;-)

Variados

E esses eram livros que eu havia lido, mas sobre os quais ainda não falara nada. Além deles, em 2016 eu li alguns outros. Dessa leva de coisas da Amazon falei um pouco no post Férias = Livros!. Não custa relembrar (não custa mesmo, é só um copy-paste aqui, hehe):

Cada um deles é um primor de conteúdo e forma. O de expressões regulares eu deixei até separado, de tanto que eu uso. O de análise bayesiana eu leio e leio e leio e uma hora eu vou dominar!

Já o Building A Scalable DW, bom, pelamordedeus, leia! Ele e o DW Toolkit são a base para um DW Corporativo feliz e saudável! ;-)

Alguma Dica?

E isso fecha o meu ano de leitura. Agora estou procurando as coisas para 2017.

Alguma sugestão? ;-)

A.B.I.M.

Long gone are the years when to have or not a BI Solution (or Decision Support System) was yet an option. A company who choose not to analyze its data today won’t grow beyond a certain point. It has no tomorrow.

To have working BI initiatives is not easy, let alone simple. A sucessfull BI project depends on a lot of factors and to lead one is not a job for the faint of heart. Business Intelligence projects are experience- and knowledge-intensives. Even the customer must control a degree of education to reap the benefits.

A best selling book does not come from anyone armed with a word processor. A new software is not born out of the hands of its final user just because he/she has a point-and-click Java IDE within reach. Business Intelligence Solutions does not either. The whole big world is a complex place with less and less room for amateurs. Go educated or go extinct!

The Agile Manifesto

This was a milestone for the Information Technology Industry. The Agile Manifest broke the shackles tying projects to ever-late schedules in doomed iniatives, and opened up a road of unprecedent success. As a developer and manager I have embraced the A.M. and adopted Scrum as the means to implement AM. I ended using them both to do everything I do, including Teaching and building Business Intelligence projects.

Recently I became aware that, influenced by the A.M., I have brought some of those principles under a BI light, and I am sharing my insights here.

Agile Business Intelligence Manifesto

The highest priority is to help the customer to answer his questions through early and continuous delivery of quality data and tools for its exploration.

Changing requirements are a must because only so data exploration can shape new hypothesys and drive an increase in knowledge.

Deliver working advances on data platforms frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Take part in the customer’s problem: To help the customer answer his questions is to help him formulate them by employing specialized knowledge on tools and techniques.

A customer answering its questions is the primary measure of progress, so he can make new questions.

Conclusion

This list does not stand on itself, but rather extends the Agile Manifesto. It also does not take care of effective delivering the results, which should be achieved by using Scrum and a special, iterative technique for BI projects, soon to be posted here.

Personally I don’t agree that Agile BI is only about tools. It sounds like too little, leaving a lot outside, begining with the very customer.

I didn’t invent the above principles, I more like found them spontaneously sprouted and began guiding my work whilst studying and applying the A.M., Scrum and some other methodologies and strategies to my daily job. The statements I posted above are in fact the Agile Manifest adapted to BI needs as per my point of view. I missed a list like that a lot and as until now nobody made a movent toward them, I did. So, here is my proposal.

What is your opinion?


To my English speaking fellows a note: In Portuguese the generic third person is the male form – he/him/his etc. So when we say “he” as the meaning of “anyone” we also refers to women as well. So, I am not confortable with using “one” or “he/she” when refering to an unknown person, what led me to using “he/him” above in the place of a generic “customer”. Please! I have a lot of intelligent women as friends besides my own wife, and I would never downplay the importance of them! I just wanted to sweep the ethnical differences aside so not to taint the discussion or raise any wrong criticism. Right criticism is welcomed <grin>.