Arquitetura de Integração (Integration Architecture)

Para aqueles mais familiarizados com Arquitetura Empresarial/Corporativa (Enterprise Architecture-EA), ou seja, com organizações que já executam algum(ns) modelo(s) de negócio(s), a arquitetura empresarial é elo entre a arquitetura do negócio e a arquitetura da tecnologia (marcadamente de TICs)(para mais detalhes, ver livro deste editor).

De acordo com muitos frameworks de EA, o domínio da EA é feito pelos subdomínios de Negócio, Dados, Aplicações e Tecnologia. O que nunca é explicitamente mencionado é que estes subdomínios não podem existir isolados, i.e., eles precisam ser perfeitamentealinhados para serem de valor.

A Arquitetura de Integração tem a responsabilidade de zelar para que a EA seja implementada de uma maneira efetiva, eficiente e equânime, não somente no interior dos vários sistemas e aplicações, mas ao longo dos vários sistemas e aplicações. Idealmente, isto significa que uma estrutura de EA experimentada está devidamente assentada, e que todos os subdomínios estão igual e adequadamente endereçados, bem como estão alinhados.

Mas para se chegar a esse grau de maturidade (ou seja, de uma arquitetura integração harmônica) leva-se um determinado tempo. E esse tempo não é somente determinado pela competência do arquiteto (ou time) de integração, mas também pela compreensão de que a arquitetura de integração evolui com o tempo.

Em seu livro “Integration Architecture: beyond technology”, Piet Knijnenburg observa que quase todas as empresas (de médio a grande porte) irão provavelmente ter uma coleção de sistemas e aplicações empresariais que necessitam se comunicar e cooperar para dar suporte os processos primários e secundários de negócio de uma organização. No entanto, as formas de lidar com essas coleções de sistemas e aplicações empresariais têm variado com o tempo.

Segundo o autor, uma primeira transição que se constata na história recente, é que partimos de um momento da automação empresarial onde evoluímos da TI corporativa que registrava processos de negócios (executados por pessoas), para uma TI corporativa que dava suporte aos processos de negócio (gerenciados por pessoas). Nesta transição convivemos com três arquiteturas de sistemas que demandaram diferentes enfoques de integração.

Nas últimas décadas do século passado, as organizações conviveram com a chamada “arquitetura de três camadas”, que advogava a apresentação fisicamente separada da lógica do negócio das funções de gestão dos dados. A Figura 1 à frente representa a visão de então, que distinguia a integração dos dados da integração das aplicações.

Neste modelo, a integração dos dados dizia respeito a sincronizar dados entre diferentes datastores e alvos. Envolvia reconciliação, manipulação, de-duplicação, limpeza, padronização e outras operações intensivas em dados. Integração de dados não dizia respeito ao suporte de processos de negócio, pelo menos não implicitamente e não diretamente. Como tal, a tarefa de integração de dados era rodada no “modo batch”.

Ainda neste modelo, a integração de aplicações era sobre o intercâmbio de dados entre aplicações, e não em data stores. Opera-se (quase) em tempo real, seguindo o passo dos processos de negócios que elas dão suporte. Como tal, forma um nível de abstração acima das aplicações subjacentes e processos de negócios. Enquanto a distinção entre integração de dados e de aplicações constituiu uma melhoria, ela não dissolveu as barreiras entre sistemas em silos, ou seja, os cruzou. A próxima etapa, que incorporou o conceito de três camadas na integração de soluções, tornou essas barreiras menos aparentes.

Logo, na Figura 2 à frente, a integração dos dados é colocada na camada de dados e a integração de aplicações é colocada na camada da lógica do negócio. No entanto, neste modelo ainda se representa a troca de dados em dois níveis, o nível da lógica do negócio e o nível de datastore, e ainda não representa o que se tenta atingir: o suporte integrado aos processos de negócio ao longo do nível da lógica do negócio. Contudo, o modelo claramente faz a distinção entre integração ao nível dos dados e integração ao nível das aplicações.

Foi o conceito de Service Oriented Architecture- SOA (Arquitetura Orientada a Serviço) que introduziu uma camada de integração no topo da camada da lógica do negócio (Figura 3 à frente), a qual contém todos os serviços e funções de negócio. Este conceito nos permitiu remover verdadeiramente as barreiras entre os sistemas em silos, pelo menos para os clientes da camada de integração. Os serviços e funções nesta camada de integração acessam a lógica de negócio subjacente ao longo das várias aplicações, sistemas e plataformas.

Estamos no meio hoje de uma segunda transição em termos de arquitetura de integração: uma em que partimos de uma execução de processos de negócios por aplicações gerenciadas por pessoas (ou seja, uma TI corporativa que dá suporte aos processos de negócio), para uma TI corporativa que participa dos processos de negócios (ou seja, fase em que há uma assimilação da TI corporativa na gestão operacional dos negócios).

E aqui se pode observar, como apontado por Knijnenburg, a razão pela qual muitas integrações de sistemas legados para as modernas redes de aplicações têm falhado: ou seja, está se tentando fundir legados que são voltados para o registro de dados em uma rede de aplicações, que está voltada para atender ou executar processos de negócio.

Em resumo, uma boa compreensão do significado da arquitetura de integração é um bom caminho para evitar possíveis falhas nos negócios! A próxima transição, já em curso, exige novos conceitos e novas as compreensões, mas isso fica para uma nova oportunidade!

Se sua empresa, organização ou instituição deseja saber mais sobre arquitetura de integração, não hesite em nos contatar!