Agile modeling data warehouse development

Most of the traditional software and database development approaches tend to be serial, not evolutionary and certainly not agile, especially on data-oriented aspects. Most of the more commonly used methodologies are strict, meaning they’re composed by several stages each with very specific associated tasks. A clear example is the Rational Unified Process (RUP), divided into Business Modeling, Requirements, Analysis & Design, Implementation, Testing and Deployment. But what happens when the needs of a well design and structured plan, meet the reality of a small starting company that aims to build an entire user experience solution. Here resource control and time productivity is vital, requirements are in constant change, and so is the product itself. In order to succeed in this environment a highly collaborative and evolutionary development approach is mandatory. The implications of constant changing requirements imply an iterative development process. Project focus is on Data Warehouse development and business modeling. This area is usually a tricky one. Business knowledge is part of the enterprise, how they work, their goals, what is relevant for analyses are internal business processes. Throughout this document it will be explained why Agile Modeling development was chosen. How an iterative and evolutionary methodology, allowed for reasonable planning and documentation while permitting development flexibility, from idea to product. More importantly how it was applied on the development of a Retail Focused Data Warehouse. A productized Data Warehouse built on the knowledge of not one but several client needs. One that aims not just to store usual business areas but create an innovative sets of business metrics by joining them with store environment analysis, converting Business Intelligence into Actionable Business Intelligence.

Tradicionalmente as metodologias associadas ao desenvolvimento de software e base de Dados tendem a ser sequenciais, não evolutivas e definitivamente não ágeis. As metodologias mais comuns tendem a ser rígidas, geralmente compostas por diversas fases ou níveis, onde para cada um destes existe um conjunto muito específico de tarefas a executar de acordo com uma ordem própria. Um exemplo claro é o Rational Unified Process (RUP), dividido em Modelação de Negócio, Requisitos, Análise e Desenho, Implementação, Testes e Disponibilização. Mas como reagir quando as necessidades de um plano bem estruturado e desenhado se deparam com a realidade de uma empresa start-up com múltiplos projectos que pretende desenvolver um sistema de informação baseado em experiência de loja. Uma empresa com recursos limitados em que o retorno sobre a produtividade necessita de ser explorado ao máximo, algo que obriga a contínua procura de melhoria e subsequentemente a constante alteração de foco e requisitos. Neste ambiente a necessidade de um desenvolvimento altamente colaborativo e progressivo é obrigatório. A constante alteração de foco implica a necessidade de um desenvolvimento iterativo, capaz de rapidamente reagir às alterações. Neste contexto o foco do projecto recai sobre o desenvolvimento de um armazém de dados e modelação de processo de negócio. Esta área específica é particularmente complexa, pois o conhecimento é intrínseco ao negócio. Como se trabalha? Quais os objectivos? O que é relevante para análise? Tudo isto é parte integrante da empresa e como tal conhecimento difícil de transmitir. Ao longo do documento é pretendido explicar a razão pela escolha de uma metodologia Agile para o desenvolvimento. Como uma metodologia iterativa e gradual, permitiu desenvolvimento flexível com suficiente planeamento e documentação. Mais importante como foi aplicada de forma a desenvolver um Armazém de Dados com foco em Retalhe. Um capaz de responder as necessidades de vários clientes. Construído através do conhecimento de não um, mas múltiplos clientes através da análise dos seus requisitos. Este pretende armazenar não só a informação tradicionalmente associada a um Armazém de Dados de retalhe, mas sim juntar as áreas de um armazém de dados tradicional com informação recolhida do ambiente de loja. Desta forma criando um novo conjunto de métricas de negócio com o objectivo de melhorar o ambiente de loja de forma dinâmica.