Quem é responsável pelos dados da companhia?

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 (BI), 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 por meio 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 Brasil.