Os dados de uma companhia são responsabilidade de quem?

Gerenciar um projeto de integração de dados pela primeira vez não costuma ser tarefa fácil. 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 utilizadas por qualquer aplicação. Infelizmente, esse planejamento geralmente se choca 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 de 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 responsá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.

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.

Num 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 (Enterprise Application Integration), 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 traga-a até 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.

A 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 capazes de acessar diretamente aplicações de BI, ou processos ETL, é possível obter a informação desejada de uma maneira mais eficiente sem se envolver 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 que 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.

. David Fernandez é diretor comercial da InfoBuild Brasil, representante exclusiva da Information Builders no país.