Mudanças fazem parte do processo evolutivo, sobretudo no âmbito competitivo do ambiente de negócios atual, onde emergem cada vez mais rapidamente novas estratégias e, por conseguinte, novos requisitos, sobretudo com foco em inovação, tratamento de ameaças e oportunidades oriundas de fatores externos em constante mudança.

Dado que a abordagem de projetos de BI através de métodos tradicionais eleva a incapacidade dos processos de desenvolvimento de responder a mudanças, vamos dar ênfase neste artigo aos aspectos da arquitetura de solução e ao desenho físico do modelo de banco de dados, com o objetivo de reduzir e controlar os débitos técnicos.

Neste tema mais de um autor se apoia em Martin Fowler, um dos criadores do manifesto ágil. Em seu blog Evolutionary Database Design, publicado pela primeira vez em 2003, Fowler ressalta que a atividade de desenho não é tratada, dentro de um framework ágil, como sendo uma etapa do desenvolvimento anterior a construção. Ela é tida como sendo um processo contínuo, o qual é inter-relacionado à construção, testes e entrega do software.

A partir desta definição, o processo de construção do esquema de bases de dados deve então ocorrer ao longo das iterações, onde mudanças neste esquema são feitas gradativamente, de uma maneira controlada, através da utilização de uma série de técnicas críticas que dão suporte a este modo de desenvolvimento:

  • Uso de histórias de usuários na especificação de requisitos
  • Modelagem de dados evolutiva
  • Configuração de ambientes de desenvolvimento (Sandboxes)
  • Administração dos artefatos de Banco de Dados
  • Refatoração de banco de dados
  • Testes

O autor Scott Ambler em sua obra “Agile Modeling:Effective Practices for extreme programming and the Unified Process. New York, NY, Estados Unidos: John Wiley & Sons, Inc., 2003” , não define a modelagem ágil como sendo uma metodologia substituta as existentes,  mas sim, uma série de complementos e suplementos as metodologias existentes,  tratando-se mais de uma abordagem colaborativa,  incremental e evolutiva guiada por valores e princípios ágeis.  Com isso, a modelagem ágil tem como principais objetivos:

  • Definir um meio de colocar em prática valores, princípios e técnicas ágeis a fim de se obter uma modelagem enxuta (sem trabalho desnecessário) e eficiente;
  • Adequar à construção de modelos em metodologias ágeis que se baseiam em iterações e incrementos funcionais.

A modelagem ágil de Scott Ambler se apoia nos seguintes princípios:

  • Entrega adiantada e contínua de software de valor é o principal objetivo

Portanto qualquer atividade que não contribua diretamente com este objetivo deve ser questionada e evitada, caso não possa ser justificada de maneira adequada.

Na visão de Scott Ambler:

Os modelos não são produtos a serem entregues, são artefatos que suportam o desenvolvimento, o que pode ser estendido a qualquer documentação, logo, não servem com indicadores de progresso em um projeto.

  • Viabilizar a próxima iteração deve ser um objetivo secundário

A solução de BI/DW deve ser desenvolvida com os olhos para o futuro, contudo não deve tentar cobrir todas as possibilidades deste futuro, mas sim focar em uma solução robusta e extensível.

  • Leveza no desenvolvimento

Neste caso, deve-se modelar e documentar apenas o suficiente para que o desenvolvimento possa ocorrer. Qualquer documentação que é mantida dentro do projeto deve sofrer manutenção com o tempo, pois ocorrem mudanças no ambiente, o qual estes artefatos representam.

Neste ponto, Ambler ressalta que:

Deve ser mantido um equilíbrio entre a perda de agilidade e a vantagem de dispor de um modelo que representa a informação  de uma maneira mais abstrata.

  • Mudanças são bem vindas

O autor Ken Collier (Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing.  Boston, MA, Estados Unidos:  Addison-Wesley Professional,  2011, p.151)   destaca,

Mudanças são inevitáveis! Antecipe-as e modele para isso.  Não espere que o seu desenho esteja completamente certo da primeira vez e nem por todo o tempo.

  • Modelagem Incremental

Uma abordagem incremental permite que o processo de desenvolvimento seja adaptável a mudanças, viabilizando o tratamento de grandes mudanças através de uma série de pequenas modificações nas funcionalidades de uma solução.  No que tange a modelagem, Ambler ressalta que:

É primordial que ao modelar não se tente representar todo o problema de uma só vez, ou se ater a todos os detalhes inicialmente, criando um modelo que englobe todos esses aspectos.

Ao invés disso, o autor sugere o desenvolvimento de um modelo pequeno e detalhado que possa evoluir com o tempo.

  • Crie múltiplos modelos quando necessário

Para Ken Collier, o modelador deve estar preparado para prover múltiplos modelos em paralelo, caso seja necessário, a fim de atender e comunicar um determinado público, ou cobrir uma técnica de modelagem específica necessária tecnicamente ou para uma melhor comunicação.

  • Simplicidade

Neste ponto, Ambler se apoia na visão de simplicidade de Beck, onde ele afirma que:

Na maioria das vezes, a solução mais simples funciona da melhor maneira, devido a ela ser simples, é de fácil implementação.

Portanto, a modelagem não deve sobrecarregar o sistema com esquemas de complexidade elevada.  Esse princípio se traduz na prática de modelar da maneira mais simples os requisitos existentes e refatorar o sistema no futuro para acomodar os requisitos que evoluíram.

  • Certifique-se da qualidade do trabalho executado

Ken Collier (p.151) destaca:

Modelos de alta qualidade são elegantes e ricos de informações úteis,  não sendo aceitável que sejam incompletos,  inconsistentes ou desleixados.

  • Modelar com propósito

Aqui o foco está em privilegiar software funcionado a documentações compreensíveis.  Ou seja, na modelagem deve ser respondida a questão se é para modelar para entender ou modelar para comunicar algo.

  • Maximize o investimento junto aos Stakeholders

Envolva os stakeholders o máximo possível em todo o processo de modelagem, isto trará transparência e maior eficiência em atingir as necessidades dos mesmos.

  • Obtenha feedback rapidamente

Compartilhe o modelo o mais cedo e frequentemente quanto possível.  Ao ter uma versão estável, publique formalmente e peça feedback.

 

Refatoração Aplicada ao BI/DW:

Iniciemos por definir a refatoração, primeiro através de Fowler, que descreve a técnica como sendo:

Uma maneira disciplinada de reestruturar o código em pequenos passos de cada vez.

Portanto, a prática de refatoração suporta a abordagem evolutiva de desenvolvimento, evoluindo o código fonte de uma aplicação através da implementação de pequenas mudanças nele,  feitas no decorrer das iterações do projeto.

Para Ken Collier, a refatoração serve a dois propósitos básicos:  Evoluir de modo seguro design e modelos da solução; e eliminar o “Débito Técnico” sem danificar funcionalidades e componentes que estavam funcionando previamente.  Isso demonstra maior preocupação com desenvolvimento iterativo, do que com o trabalho em andamento apresentar efeitos adversos no que já foi construído.

Já para Scott Ambler Pramodkumar J. Sadalage, em sua obra “Refactoring Databases :Evolutionary Database Design. Boston, MA, Estados Unidos:  Addison-Wesley Professional, 2006.” ,  determinam que o principal aspecto da refatoração diz respeito ao fato do código manter o comportamento semântico após as modificações,  de modo que,  não são adicionadas ou removidas funcionalidades,  objetivando apenas a melhoria do design do código já existente.

Contudo, a refatoração de banco de dados é um processo mais complexo se comparado a de código-fonte, já que a semântica dos dados existentes deve-se manter inalterada.  Isso se torna um fator crítico quando somada a possibilidade de uma base de dados poder possuir um elevado grau de acoplamento com outras aplicações que a utilizam, sendo que qualquer mudança nessa base se refletiria no funcionamento destas aplicações.

Com isso, segundo Ambler e Sadalage, uma refatoração de banco de dados deve preservar o funcionamento de qualquer aplicação que utilizem a base, sendo muitas vezes necessário um período de transição, onde os esquemas atualizados e antigos de banco de dados funcionem em paralelo, e, onde a mudança de acesso é feita gradativamente.

Collier ainda ressalta que as práticas de refatoração de banco de dados estabelecidas por Ambler (2003) são aplicadas diretamente ao conceito de DM evolutivo. Visto isso, a prática de refatoração é aplicada as bases de dados a serem estruturadas, para permitir o desenvolvimento adaptativo e incremental dessas soluções.  Collier acrescenta que a refatoração não se aplica apenas ao desenvolvimento, mas também em soluções em produção.

Neste sentido, Ambler e Sadalage deixam mais claro alguns fatores que indicam a possível necessidade de refatoração de esquemas de dados em produção:

  • Resistência a mudanças nos esquemas, por parte da equipe, de um débito técnico corrigível;
  • Duplicidade de dados com possíveis inconsistências;
  • Colunas com vários propósitos diferentes;
  • Colunas “inteligentes” podem apresentar complexas regras de decodificação para gerar valores com significado;
  • Tabelas utilizadas para armazenar tipos diferentes de entidades podem significar vulnerabilidades no modelo de dados;
  • Tabelas com número excessivo de linhas, acarretando em problemas de desempenho;
  • Tabelas com número excessivo de colunas, faltando coesão, tornado a tabela sem propósito definido e armazena dados de diversas entidades.

Especificamente para o ambiente de DW/BI, Ken Collier, acrescenta os seguintes fatores que indicam a possível necessidade de refatoração de esquemas de dados em produção:

  • Objetos de ETL  complexos, com muitos caminhos e complexas transformações, dificultando a sua manutenção e identificação de problemas;
  • Longos módulos de SQL, PL/SQL e similares;
  • Dimensões não conformes gerando sobreposição de informações, inconsistências e redundância;
  • Uso indiscriminado de views materializadas, pois podem ofuscar o modelo do DW/BI, distanciando os usuários do modelo implementado e dificultando sua compreensão;
  • Soluções de BI/DW que acessam apenas diretamente as tabelas, subutilizando views materializadas, apresentam grandes riscos de fragilidades. A recomendação é fazer uso de uma seleção de views materializadas de forma a balancear performance, custos para mantê-las e flexibilidade de acesso as tabelas;
  • Excesso de confiança na documentação da solução de BI, que não são facilmente compreendidas sem o suporte das mesmas.

A figura principal deste artigo apresenta o diagrama do processo de refatoração iterativo proposto por Ambler e Sadalage, descrito a seguir:

1.   Confirmar a necessidade da refatoração

Toda e qualquer refatoração tem de ser justificada por necessidade de negócio e o custo de sua mudança deve ser inferior ao benefício gerado para atendimento a referida necessidade.

2.   Escolher a solução de refatoração mais adequada

Dado que sempre há mais de uma solução possível, deve-se avaliar qual a refatoração mais adequada para cada caso.  Além disso, deve-se garantir que a nova funcionalidade já não exista em alguma outra parte do sistema.

3.   Elaborar a transição do esquema original

Este passo é opcional.  Quando a solução de BI/DW já está em produção a muito tempo, podem haver múltiplas soluções acessando o mesmo esquema, banco, ou camada semântica, o que dificulta a transição das soluções para o novo desenvolvimento alvo da refatoração, sendo necessário um período de transição para o esquema que está sendo alterado, durante o qual deve coexistir ambas as soluções, antiga e refatorada, para que os desenvolvedores tenham tempo para alterar/refatorar todas as soluções.

4.  Testar antes, durante e depois

Um conjunto de testes deve ser elaborado e executado até que a refatoração de banco seja completamente implementada, sendo necessário testar todos os aspectos relacionados à alteração, inclusive os programas externos que tenham acesso ao esquema de dados refatorado, tendo ou não sido alterados.

5.   Alterar o esquema do banco de dados

Trata-se de efetivamente construir a refatoração do esquema de banco de dados.

6.  Migrar dados

Muitas das refatorações de dados requerem algum processo especial de tratamento nos dados já armazenados no banco, eliminar inconsistências ou simplesmente mover dados de um local para outro.

7.   Refatoração de programas externos que acessam o banco de dados

Alterações no esquema do banco de dados podem exigir alterações nos programas que acessam a parte alterada do esquema.

8.   Executar todos os testes de regressivas

Trata-se de proceder com os testes regressivos, garantindo que a refatoração está corretamente implementada, ou identificando até que ponto/parcela da mesma já se encontra correto, sem gerar anomalias às funções e dados pré-existentes.

9.   Controlar a versão do trabalho

Para toda a solução é importante que haja um eficiente controle de versões de todos os artefatos envolvidos.

10.Anunciar a conclusão da refatoração

Todas as equipes que utilizam o banco precisam ser comunicadas sobre o término da refatoração e qual foi o seu escopo/resultado.

Para a implementação da refatoração, Ambler (2003, p.182) propõe que seja feito uso de um ambiente de desenvolvimento especifico, para cada equipe de projeto e para cada refatoração, onde, tanto a aplicação quanto o banco de dados devem estar presentes, permitindo tanto desenvolvimentos e testes unitários para cada modificação, quanto testes integrados e regressivos.

A outra técnica ágil a ser adota consiste na própria “refatoração”, que visa tanto suportar o objetivo de “Adequar e Manter Solução”, quanto o de “Reduzir Débito Técnico”, sendo que para o segundo é necessário também estabelecer o objetivo de “Identificar e Monitorar os Débitos Técnicos”.

Uma vez que a questão de débitos técnicos se diferenciam da questão de instabilidade e mutabilidade dos requisitos, faz-se necessário incluir indicadores de desempenho específicos a este fim:

  • Débitos Técnicos por Iteração:  para o qual a equipe deve ter atenção a sua redução ao logo das interações, na medida em que a equipe e a organização ganham experiência com as técnicas e conhecimento das soluções.  Caso ocorra uma elevação, pode ser um indicativo de necessidade de reestruturação da equipe, ou da resolução de gaps de conhecimento técnicos, devido a, por exemplo, uma mudança em alguma tecnologia adotada.
  • Débitos Técnicos Reduzidos / Total e Tempo Decorrido até a Solução do Débito Técnico:  estes indicadores servirão para um possível acordo de nível de serviço operacional, entre a equipe de projeto, equipe de sustentação e o Product/Initiative Owner.  Os mesmos farão com que a equipe tenha interesse em manter os níveis de débitos técnicos baixos e sobre controle.

Com isso, concluímos que para sustentar este crescimento contínuo das soluções através do processo iterativo e incremental, as metodologias ágeis têm fundamentos muito fortes que devem estar presentes no ambiente de trabalho, pois a experiência destes métodos pode ajudar a minimizar os débitos técnicos que podem ocorrer na implementação de sistemas evolutivos.

Neste sentido, destaca-se outro autor, Hughes, ao incorporar em sua abordagem processos voltados a monitoração, identificação, priorização e correção o mais breve possível dos débitos técnicos ao longo das iterações, estabelecendo técnicas e ciclos de procedimentos para a condução de sua correção de acordo com as premissas ágeis, tratando-os de acordo com a sua complexidade e momento dentro de cada iteração. Para ler mais a respeito veja nosso artigo Aplicação de Métodos Ágeis a Projeto de BI/DW.

Além disso, a evolução da solução de BI tem um problema adicional relacionado as dimensões das tabelas e ao crescimento de seu modelo e assim como dos seus dados, tornando as suas evoluções mais difíceis e demoradas.  Neste sentido, as técnicas de bancos de dados evolutivos a refatoração com base em Ambler tem grande importância para todo o ciclo de vida de soluções de BI, onde se faz necessário grande cuidado com os dados do banco diante de evoluções em seu modelo, mesmo em evoluções que necessitam de recuperação de histórico, uma vez que estas podem ser tratadas em separado de maneira estruturada e com o devido período de transição.

Não obstante ao fato anterior, devemos ainda ter atenção às necessidades de adaptação em termos de Brasil.  Deve-se observar que muitas organizações brasileiras ainda consideram a implementação de um projeto de BI como muito complexo, havendo ainda muitas empresas nos dois primeiros níveis de maturidade.  Além disso, a adoção de métodos ágeis e de refatoração de modelo de dados pelas organizações brasileiras também ainda é tímida.

Aqui na Vitarts abraçamos os métodos ágeis e as técnicas de bancos de dados evolutivo e de refatoração como parte de nosso dia a dia, promovendo maior flexibilidade e simplicidade aos projetos de BI e analytics de nossos clientes sem comprometer a robustez e performance da solução.