O documento discute os desafios de longos projetos de Business Intelligence, como ficar preso à rotina de desenvolvimento. Aponta que erros no ambiente de qualificação, apesar de menos crítico que produção, ainda exigem prontidão para correção. Também observa que projetos grandes tendem a reaproveitar código entre dimensões e fatos, e que problemas mobilizam rapidamente mais pessoas conforme a criticidade do ambiente.

1. PERFIL BUSINESS INTELLIGENCE
marcelokrug@gmail.com SEU PAPER PELA INTERNET Desde Março/2015 – pp24
Quando estamos muito tempo no desenvolvimento de um projeto, de Business Intelligence ou outros em TI, sentimos falta do
momento do erro. É o momento de sairmos da rotina e nos motivamos para resolver os problemas
LONGOS PROJETOS DE BUSINESS INTELLIGENCE: FUGIR DA ROTINA
www.bibrasil.net
Os nossos desafios começam quando passamos a publicar os
desenvolvimentos. Normalmente nos desenvolvimentos,
tudo corre bem. Erros aqui e ali, mas trata-se de ambiente de
desenvolvimento. Com dados de desenvolvimento. E no
ambiente acima deste, já começamos a ver a adrenalina
subir. Com um certo nervosismo para não “estragar” uma
estrutura que está em funcionamento e que pode afetar uma
grande quantidade de projetos também em testes.
Passa-se dia após dia no desenvolvimento em projetos de
Business Intelligence e acabamos por ficar muito focados no
processo de finalização e entrega das tarefas. Com todo o
planejamento, acabamos por quase estar fazendo os
desenvolvimentos de uma forma automatizada. Sabemos o
que tem para fazer, como fazer e tudo mais. Quase uma
estrutura replicável, guardadas as proporções. Pois tenho as
dimensões e fact tables e, não vemos mais a dimensão como
algo extraordinário em relação à outra. Tenho atributos de
controle de versões, por exemplo, e os atributos do conteúdo
específico da dimensão. Uma a uma com esta estrutura.
O mesmo acontece nas fact tables. Os atributos de controle e
depois os relacionamentos que caracterizam o fato. Claro que
os atributos de controle ficam de fora do modelo OLAP. Na
quase totalidade dos casos. Visto que o versionamento fica do
lado do Data warehouse e não da análise dimensional e
relatórios.
Na primeira execução com erro, tentamos correr contra o tempo para logo
normalizar a situação. Em uma situação de erro no processamento de um
cubo por exemplo. Algo pode dar errado e todos os cubos daquela base de
dados OLAP ficarem com o estado de “unprocessed”. Muito chato e muito
comum.
É o estado de prontidão que adotamos e que nos mantém responsabilizados
para as operações de correção. Que mesmo não sendo um ambiente de
Produção final, temos a responsabilidade de o manter sempre ativo. Em
semelhança com o ambiente final.
Muitos desenvolvedores pensam que o ambiente de qualificação é mais
confiável que o ambiente de Produção. Já que o ambiente de produção pode
conter algum workaround específico para o bom funcionamento. E no
ambiente de Qualificação, é suposto que o desenvolvimento esteja
implementado. Conforme pressuposto no projeto e como foi planejado
anteriormente.
Ainda nos longos projetos, muito do desenvolvimento
acaba por ser reaproveitado. Packages ETL para popular
dimensões são copiados para atender às necessidades
da dimensão seguinte. E assim vai até o final. E depois
pode ocorrer ainda com as fact tables. É muito comum
encontrarmos estas situações em projetos. Vamos
encontrar bases OLAP com 20 cubos e 100 dimensões. É
realmente comum uma estrutura assim. De 20 cubos,
cada um deles com cerca de 10 fact tables.
Acabamos armazenando em um repositório de código,
as queries para uma determinada lookup, de Data por
exemplo. Que chamamos pelo menos uma vez,
obrigatoriamente, em cada fact table.
Os problemas, quando surgem movimentam toda a
equipe. Uns com mais experiências que outros e
dependendo do ambiente, o problema acaba por ser
resolvido mais cedo que você imagina. Quando é em
ambiente DEV, você é o principal interessado. E quanto
mais alto a relevância do ambiente, os interessados na
resolução vão aumentando em número rapidamente.
Além do que, para uma publicação sempre deve ter em
conta um plano de contingência e rollback. Na falha e se
houver necessidade real, volta-se ao que havia antes. É
uma das decisões que o líder deve tomar nestas
situações mais críticas.