(E)AI x SOA

Eu bem que gostaria de ter estado de férias todo esse tempo pra justificar minha falta de posts. Mas isso não é verdade. Estou de volta desde janeiro!

Durante as férias tive o prazer de ler sobre a Teoria das Cordas durante visita à Salvador – BA e Medellín – CO. Não, não escreverei nada sobre o tema. Pode se tranquilizar. Então vamos lá…

SOA não é mais novidade, não é mais utópico. A bem da verdade resolve uma série de questões que eu me indagava há tempos. Pra mim soa mesmo como uma evolução natural de TI, ou talvez como meio de trasformar em realidade a visão de TI como diferencial competitivo.

Mas antes de SOA alguns arriscaram EAI, principalmente o A e o I sem o E. O resultado da falta do E gera, e gerou, cenários onde há uma preocupação em prover conexões entre sistemas e não funções de negócio. Algumas das consequencias são:

• Esforço repetido de integração
• Conexões point-point apenas mudaram de lugar
• Alto acoplamento entre aplicações, legados e soluções proprietárias
• Reuso baixo ou nulo
• Lógica de negócio replicada
• Lógica de acesso replicada entre integrações
• Número excessivo de serviços de integração
• Alto custo de manutenção
• Difícil justificativa nos investimentos de TI

Nestes cenários a falta de foco no negócio e sim em integrar aplicações leva a um entrave na evolução de TI para um modelo SOA.

Case: Obtendo informações de um cliente

Para ilustrar melhor a situação, considere um case onde duas aplicações necessitam obter dados  de Cliente. Ao longo do tempo, é natural que haja mais de uma fonte de dados de cliente. É comum também que aplicações distintas operem sobre tipos de clientes diferentes, pessoa física e pessoa jurídica, clientes com contratos diferentes, são exemplos. Num cenário (E)AI, seriam construídas duas integrações para atender cada uma das requisições das aplicações.

A primeira integração que atende a aplicação que opera com clientes, digamos, pessoa física, necessita integrar uma base de dados de uma aplicação que cadastra apenas endereços, acessar uma aplicação legada provinda da aquisição de uma companhia menor, conexão com o SAP e acessar o CRM via Webservices para obter dados mais atualizados de clientes.

Já a segunda integração para pessoas física, demanda acesso apenas ao SAP e por limitações no webservice do CRM, um acesso direto à base deste sistema. O ambiente deve ficar como no diagrama a seguir.

A falta de padronização no acesso e talvez alguma lógica de checkagem  ou  limpeza dos dados do cliente traz um grande risco para a empresa que está sempre exposta a novas conexões, novo ciclo de integração,  testes, etc.

Pensemos agora em SOA. Relembre que SOA prima por serviços como meio de entregar funções corporativas. Relembre também do post “ESB? Até que ponto?”  e vai ver que falei sobre a divisão, ou melhor, categorização de serviços por camada. Que nada mais é o que Erl[01] chama de Services Layer. Uma abordagem SOA incorreta poderia levar ao mesmo engano do cenário anterior, com lógica de acesso, tratamento, validação espalhada por vários serviços. Mas uma visão em camadas vai ajudar a especializar cada serviço de acordo com o tipo tarefa que ele executa.

Não só isso, observe bem que um serviço não só precisa ser especializado no que faz, mas também deve ser o único a executar aquela tarefa, ou funcionalidade específica[02]. Uma das atividades que o negócio precisa executar para atender a algum processo de negócio ou mesmo atender uma linha de negócio (LOB – Line-of-Business) é: Obter Informações de Cliente, e este será o nosso serviço.

Num cenário SOA, notamos a presença de um Serviço de Dados (Data Service) que concentra todo o conhecimento na obtenção e provisionamento de informações de cliente. Vejamos o diagrama.

Note que até modifiquei o diagrama para colocar todos os legados e aplicações existentes à direita. Os serviços de conectividade, muitas vezes chamados de adapters, são conhecedores da interface específica das aplicações que proveem dados de cliente, mas expõe para outras aplicações e serviços SOA uma interface padronizada pelo time de arquitetura SOA.

O serviço de dados agora é a “fonte de ouro”  da entidade cliente. Toda lógica de extração, segurança, auditoria, data redaction e transformação dos dados provindos de diversas fontes fica a cargo deste serviço. Isso vai permitir que outras aplicações e serviços tirem proveito desta fonte existente. As vantagens são:

• Foco em funcionalidade, não conexão
• Baixo acoplamento. Clientes do serviço estão acoplados apenas a seu contrato
• Solução orientada ao negócio e não a aplicações existentes
• Alto reuso. Reduzindo o custo de novas aplicações
• Ponto único de manutenção e adição de novas funcionalidades
• Redução no custo de integração. Aplicações fontes de dados de cliente já integradas.
• Redução de risco ao negócio. Depois de construído e testado uma vez, o serviço reusado é mais confiável que a criação de um novo

Estas são vantagens do SOA em si, aplicadas a este case.

O que fazer para chegar lá?

Não é tão fácil, rápido e barato chegar nesse nível que até parece óbvio. É tema para uma consultoria responder.

Existem vários artigos e pesquisas que tratam dos motivos do fracasso na adoção SOA. Você precisa conhecer estes fatores de fracasso, evitá-los e se concentrar em montar uma Arquitetura bem definida, padronização, definir políticas e processos, criar estruturas organizacionais focadas em SOA bem como definir seus papéis e responsabilidades.

Algo que deve ser observado é que um serviço é concebido como um software ou aplicação qualquer, o que demanda engenharia correta.

Além do técnico, ferramental, infraestrutura e ter uma visão clara de onde se quer chegar, é preciso ter um patrocínio forte do negócio. SOA veio transformar o modo com que TI é entregue ao negócio, ou seja, é preciso ter apoio dos executivos para enfrentar as barreiras encontradas como custos iniciais, educação e treinamento, mudanças culturais, consultoria, dentre outros.

Espero ter contribuido com a visão SOA, mas ratifico que o melhor que você pode fazer é estudar, e muito.

Fontes:

[01] SOA Design Patterns by Thomas Erl, Pattern Service Layers, p. 143.

[02] SOA Design Patterns by Thomas Erl, Pattern Logic Centralization, p. 136.