5o ENCONTRO DE USUÁRIOS DE BI

Transcrição

1 5o ENCONTRO DE USUÁRIOS DE BI Contextualizando Para o quinto Encontro de Usuários de BI, o tema escolhido foi a importância de adotar uma Arquitetura de Referência em projetos de BI. Durante os encontros em São Paulo e no Rio de Janeiro contamos com a presença de mais de 50 representantes de diversas empresas, todas com iniciahvas na área de Business Intelligence e/ou Data Warehousing. Os encontros Hveram o formato de workshop, iniciando com um debate sobre a importância de se uhlizar uma arquitetura de referência e os riscos de não uhlizála. Em seguida os grupos passaram a discuhr os principais módulos da arquitetura de referência ideal, suas funções, caracteríshcas, como se relacionam e como atendem as necessidades da comunidade de negócios. A seguir apresentamos os principais pontos discuhdos durante os encontros. O que é uma Arquitetura de Referência Logo no início das discussões surgiu uma dúvida importante. Afinal, o que vem a ser uma arquitetura de referência? Seria um modelo de dados predefinido a ser seguido pela organização? Se não, o que seria? A conclusão do grupo foi de que uma arquitetura de referência é uma visão macro do ambiente, composta por camadas que possuem funções específicas e que juntas são capazes de atender as necessidades de negócio para as quais o ambiente de BI é desenvolvido. Foi ressaltada pelo grupo a importância de que a arquitetura de referência tenha como prioridade atender a comunidade de negócios e não as necessidades e limitações da área de TI, como infelizmente ocorre em muitas organizações. Por priorizar o atendimento das necessidades de negócio, uma arquitetura de referência tem mais foco nas funcionalidades do que nas questões técnicas. As definições técnicas são decorrentes das necessidades funcionais e não o contrário. Page 1

2 Um paralelo interessante feito durante as discussões foi comparando a arquitetura de referência com a estratégia da empresa. Ambas devem ser bastante discuhdas antes de serem adotadas, mas uma vez definidas devem se manter estáveis por um período relahvamente longo, sofrendo pequenos ajustes em função das mudanças do ambiente corporahvo. A Importância de Adotar uma Arquitetura de Referência em Projetos de BI Todos concordaram que é mandatório adotar uma arquitetura de referência para ambientes de BI. Entre os mohvos para sua adoção foram listados os seguintes: A necessidade de decompor a complexidade de um ambiente de BI a parhr da definição de módulos menores e com funcionalidades específicas, mais fáceis de serem administrados. A necessidade de padronizar a forma como o desenvolvimento é feito e de facilitar a introdução de novos profissionais no processo de desenvolvimento. A busca de redução de retrabalhos causados por decisões técnicas tomadas sem o devido planejamento. A busca de maior facilidade na manutenção do ambiente. Como consequência, projetos de ambientes de BI que não seguem uma arquitetura de referência bem definida esgotam rapidamente sua capacidade de atender a comunidade usuária com o aumento exponencial da complexidade de seus processos e da dificuldade em aprimorálos e mantêlos. O contraste entre ambientes com ou sem uma arquitetura de referência sólida é resumida nas declarações de dois parhcipantes do grupo: vim de um lugar onde 5nhamos uma arquitetura bem definida. Hoje estou em um lugar que não tem arquitetura definida e não estou com a vida nada fácil. No começo não Dvemos sucesso devido à pouca importância dada à arquitetura e a primeira tentadva de criar um Ambiente de BI fracassou Page 2

3 As Principais Camadas de uma Arquitetura de Referência Durante as discussões foram idenhficadas três principais camadas para uma arquitetura de referência robusta. Foram elas: Camada de Integração de Dados Responsável pelo processo de aquisição e preparação dos dados provenientes dos diversos sistemas onde residem, sejam eles internos ou externos. Camada de Armazenamento Responsável pelo armazenamento dos dados obhdos pela Camada de Integração de forma a permihr análises que envolvam diversos assuntos e sob diversos pontos de vista. Camada de Apresentação Responsável por apresentar os dados conhdos na Camada de Armazenamento de forma amigável para os usuários de negócios. Enquanto a camada de integração de dados é de responsabilidade quase exclusiva da área de TI, as camadas de Armazenamento e de Apresentação são de responsabilidade no mínimo comparhlhada entre TI e as áreas de negócio. No caso da camada de armazenamento, a definição do que deve ser armazenado e da forma como este armazenamento deve ser feito, interessa diretamente aos usuários. Já no caso da camada de apresentação, o ideal é que os usuários possam ser os responsáveis pela criação de seus próprios relatórios e dashboards, sendo apenas apoiados pela área de TI. Em um dos grupos foi feita a analogia da Arquitetura de Referência como sendo uma ponte que faz a ligação entre os sistemas e os usuários de negócio. Atributos de uma Arquitetura de Referência de Sucesso Iniciando pela camada de apresentação, os grupos discuhram os atributos comuns a arquiteturas de referência de sucesso para ambientes de BI. Na camada de apresentação foi consenso de que a mesma deve permihr a maior flexibilidade possível aos usuários e que, de preferência, os usuários deveriam ser responsáveis pela confecção de seus relatórios e dashboards. Page 3

4 Alguns parhcipantes alertaram para a necessidade de que haja governança sobre o acesso aos dados e queshonaram se o controle de acesso deveria estar na camada de apresentação ou na camada de armazenamento. A conclusão do grupo é de que o controle de acesso pode ser feito tanto na camada de armazenamento quanto na camada de apresentação, dependendo da tecnologia uhlizada. Em vários casos, o controle de acesso pode ser comparhlhado pelas duas camadas. Também houve uma discussão sobre a viabilidade ou não de incluir ferramentas como Excel na arquitetura de referência. Apesar de algumas divergências, o consenso foi de que sim, desde que os dados uhlizados pelo Excel sejam provenientes do ambiente de BI corporahvo. Com relação a forma como os dados deveriam ser disponibilizados na camada de apresentação, a conclusão foi de que não existe um modelo que atenda a todas as necessidades e que cada ferramenta de acesso exige uma abordagem específica. No caso da Camada de Armazenamento foi mais dibcil obter o consenso. Alguns parhcipantes defenderam a existência de duas camadas, uma com modelo de dados na terceira forma normal, mais detalhada, e outra com modelo dimensional (star schema ou snow flakes), mais consolidada. Outros defenderam uma única ou duas camadas, sempre com modelagem dimensional. O representante da TDW declarou que a metodologia da empresa privilegia a abordagem em duas camadas. A primeira, com modelo na terceira forma normal, é responsável por armazenar todos os assuntos de forma integrada, no nível mais detalhado e com séries históricas completas. A segunda camada é responsável por disponibilizar conjuntos de dados mais uhlizados nas análises de dia a dia. Nela são criadas várias estruturas de dados com visões parciais, normalmente envolvendo um ou mais assuntos de forma mais consolidada e com séries históricas mais curtas, os chamados Data Marts. Esses datamarts podem ser modelados na forma de estrelas (star schemas), flocos de neve (snow flakes) ou mesmo tabelas totalmente desnormalizadas onde fatos e dimensões são apresentadas em uma única tabela. Ainda na Camada de Armazenamento houve uma discussão em torno dos conceitos de ODS e de Data Lake. Realizado em Abril de 2015 Rio de Janeiro / São Paulo TDW BI ConsulHng Page 4

5 Alguns argumentaram que o ODS deveria ser uma cópia dos sistemas transacionais com atualização ao longo do dia para atender a demandas operacionais e servir de área de trabalho para a carga da camada de armazenamento do ambiente de BI. Novamente o representante da TDW declarou que a metodologia da empresa considera que o ODS tem a função específica de atender a demandas de análise que exijam uma latência menor com aplicações de call center ou de acompanhamento de vendas ao longo do dia, mas que sua modelagem não deve ser uma simples cópia dos sistemas transacionais. Com relação ao Data Lake todos concordaram que ele deve ser considerado como uma extensão da Camada de Armazenamento onde dados que ainda não passaram pelo processo de integração possam ser disponibilizados aos usuários finais para análises exploratórias. Atributos da Organização para a existência de um Ambiente de BI de Sucesso Durante as discussões sobre os atributos de sucesso de uma arquitetura de referência surgiram pontos que se enquadram melhor como atributos da organização. Entre eles destacamos: 1. A existência de uma organização específica responsável pelo fomento e manutenção do ambiente de BI e de sua Arquitetura de Referência. 2. O envolvimento das áreas de negócio nos processos de planejamento, desenho, construção e operacionalização das iniciahvas de BI. 3. A disciplina na adoção da Arquitetura de Referência. 4. A existência de um Patrocinador forte para o Ambiente de BI, que entenda o potencial e os desafios deste Hpo de programa. 5. O reconhecimento por parte de TI que sua função principal é atender as necessidades das áreas de negócio. 6. Disponibilidade de recursos de infraestrutura e de pessoal suficientes para atender as expectahvas da organização. A conclusão dos grupos de discussão foi de que nada adianta inveshr na definição de uma Arquitetura de Referência se não houver um forte compromisso da organização com a adoção da mesma. Em outras palavras, uma Arquitetura de Referência robusta e bem planejada é NECESSÁRIA mas não é SUFICIENTE. Realizado em Abril de 2015 Rio de Janeiro / São Paulo TDW BI ConsulHng Page 5