Os dados são responsabilidade de quem?
O departamento responsável pelos dados em uma organização sempre atrai a atenção de outros setores. Estes setores querem ter participação nessa estrutura – é importante nunca esquecer o fato de que os dados não foram projetados para atender às exigências destes setores, nem de que estes dados podem apresentar-se de forma completamente diferente. É uma tarefa complicada gerenciar um projeto de integração de dados pela primeira vez. Normalmente, são usadas duas práticas: o desenvolvimento de um planejamento estruturado e um protótipo para teste de usuário, com “partes” do projeto que possam ser “manejáveis”. Num contexto de business intelligence, um planejamento estruturado envolve o desenvolvimento de um datawarehouse ou a definição de dimensões que possam ser utilizados por qualquer aplicação. Infelizmente, esse planejamento geralmente choca-se com o método de protótipos e testes e, embora ambas as práticas (planejamento e protótipo) levem o primeiro projeto à efetiva produção, nenhuma das duas é realmente capaz de solucionar desafios imprevistos. Isso reforça a teoria de que os dados representam um problema alheio: queremos ter acesso ao dado apropriado que possibilite a geração dados e relatórios, para que então possa ser definido o primeiro modelo, deixando a equipe responsável pela extração, transformação e carga dos dados (ETL) acessar informações. Quando o responável, finalmente satisfeito com os resultados disponíveis no datawarehouse, diz querer adicionar um grupo particular de algoritmos, corre-se para obter a informação com o máximo de agilidade, torcendo para que possamos ajustá-la dentro do modelo já existente, ou é utilizado dimensões de conformidade para criação dos relatórios necessários. Em outras palavras, existe um esforço para transformar o projeto inicial de BI em um único e saudável ambiente de BI. Tratamos cada nova questão de BI como uma questão de integração de dados única. O erro é utilizar diferentes ferramentas, técnicas e modelos para integrar a informação, o que leva a desperdício de tempo e comprometimento de qualidade. Além disso, é comum considerar questões de governança uma a uma, originando redundância, confusão e vulnerabilidade nas tecnologias e políticas de segurança para acesso à informação. Nesse cenário, pode-se resumir algumas dificuldades: • Projetos de BI geralmente envolvem um único sistema de registro, enquanto ambientes de BI geralmente requerem fontes de dados múltiplas; • Projetos de BI normalmente apresentam exigências de latência definidas, enquanto ambientes de BI precisam ter capacidade de se ajustar a novas e inconstantes exigências de latência, dependendo da comunidade de usuário; Esses fatores mostram possíveis problemas de flexibilidade relacionados a tipo de sistema, latência e escopo que o mercado de EAI (Enterprise Application Integration) vem enfrentando há anos, fazendo com que os profissionais da área de BI possam hoje se beneficiar dos resultados obtidos de esforços anteriores. Neste contexto de evolução, temos a arquitetura orientada a serviços (SOA), que codifica um mecanismo de ação e reação por meio da reutilização de um serviço arbitrário, ou lógica de negócios reutilizável, por meio de uma interface neutra de plataformas. Os web services são a escolha mais popular de interface. Tão popular que muitas pessoas pensam que SOA e web services são sinônimos. Embora o SOA tenha nascido no mundo da EAI, alguns pontos precisam ser destacados. • Compressão de dados ou funcionalidade em serviços. Cada serviço está acessível através de uma interface, como web services; a interface esconde os detalhes de implementação do serviço. Em outras palavras, o SOA atende a uma demanda comum na gestão das corporações, que diz: “não interessa como você vai obter a informação, apenas obtenha-a para mim”. • Interação por meio de formatos de dados padronizados. Com o SOA, os “consumidores” do serviço normalmente acionam os provedores utilizando um documento padrão (um documento SOAP - Simple Object Access Protocol - no caso de web services). Os provedores de serviço respondem com um outro documento padrão. Estes documentos-padrão podem potencialmente substituir posições difíceis de serem reutilizadas ou arquivos delimitados usados em práticas ETL comuns. • Reutilização da inteligência a partir de processos de negócio estabelecidos. Pode ser mais facilmente entendido pela comparação com visualizações de base de dados. Uma visualização pode incluir campos virtuais e agregações: qualquer informação contida representa seu conhecimento sobre os problemas de negócio enfrentados pelo usuário. O SOA vai além da lógica visualizada e fornece uma maneira de capturar qualquer tipo de lógica dentro das chamadas de serviço. Com estas características SOA, nos aproximamos de uma arquitetura BI com a flexibilidade necessária em relação a tipo de sistema, latência e escopo. Tipos de sistema A interface padrão oculta as diferentes categorias de sistema em qualquer informação ao usuário, incluindo ETL ou sistemas de BI. Isso garante dois importantes resultados: • Grandes alterações podem ocorrer no sistema de registro, ou o sistema de registro pode ser substituído, sem afetar o sistema de BI; • Os desenvolvedores podem incorporar múltiplos sistemas de registro dentro do ambiente, preocupando-se apenas com o modelo de dados ou os requisitos do sistema, em vez de ter que lidar com múltiplas interfaces, modelos de programas e plataformas. Latência Os serviços que criamos podem apresentar diferentes níveis de latência. Se criamos um serviço de alta latência, e depois precisar fornecer a mesma informação em nível de latência mais baixo, pode-se modificar a implementação sem alterar a interface. Ou seja, podemos ajustar problemas de latência sem quebrar outros processos que utilizam estas interfaces. Escopo A interface de serviço permite certa clareza de raciocínio. O serviço é o que é: se queremos que ele “faça mais”, ou se precisamos racionalizá-lo com outros sistemas de registro, precisamos agregá-lo a outros serviços que forneçam informação adicional. A orquestração de serviços é um problema comum de EAI, com soluções que incluem ferramentas de BPM, linguagem de execução de processos web services e frameworks adaptáveis. O SOA baseia-se no seguinte princípio: “diga-me o que fazer, mas não como fazer.” Se os responsáveis pela aplicação podem prover serviços dos quais sejam capaz de acessar diretamente aplicações de BI, ou processos ETL, é possível obter a informação desejada de uma maneira mais eficiente sem envolver-se nas minúcias do esquema de base de dados da aplicação. Por fim, note que quanto mais o SOA amadurece, mais a distinção entre EAI e integração de dados tende a ficar obscura. A não ser uma questão SQL (Structured Query Language) seja submetida como ponto-central de um web service – o que não é uma prática recomendada por uma série de motivos – não é possível saber ou se importar se os campos por onde passam são parâmetros para um procedimento armazenado ou o input para uma chamada API (Application Programming Interface). E é melhor que seja assim, pois com o SOA, os dados também não serão uma responsabilidade sua. *Jake Freivald é diretor de Marketing da iWay Software, representada com exclusividade no Brasil pela InfoBuild.
|