A arquitetura padrão pode solucionar a complexidade da integração ponto a ponto?

John Schimidt

Uma hairball de integrações ponto a ponto não é apenas uma dor de cabeça para a manutenção de TI, é ruim para os negócios. Com uma abordagem padrão, os analistas de negócios podem começar a minimizar o impacto da mudança.

A integração ponto a ponto entre aplicativos não é necessariamente ruim. Se você tiver poucos aplicativos para integrar, a abordagem de ponto a ponto é rápida, simples e econômica. O problema é que as empresas não têm apenas alguns aplicativos. Elas têm centenas, cada um com dezenas de interfaces.

E eles se acumulam à hairball que, cada vez mais, é a perdição para a área deTI e de negócios, elevando os custos de projeto por demandar a reinvenção da roda por parte dos analistas e desenvolvedores cada vez que outra integração ponto a ponto é necessária. Quanto mais confusa a hairball, mais isso se reflete nos custos de manutenção.

Os arquitetos geralmente concordam que a hairball é algo fora do padrão, com muitas características indesejáveis, mas que prevalece na maioria dos ambientes de TI. E, à medida que os orçamentos de TI ficam mais restritos, os CIOs recorrem aos analistas de negócios para reduzir as dificuldades e os custos, e aumentar a agilidade dos negócios e da TI.

Muitas áreas de TI estão dando os primeiros passos para declararem o fim das integrações ponto a ponto em favor do modelo "hub e spoke" para a padronização e a reutilização baseadas em um modelo de dados principais, um padrão de processo para a comunicação entre diferentes formatos de dados.

Melhores práticas recomendadas
Com uma abordagem padrão, cada aplicativo converte seus dados em um formato comum, compreensível a todos os aplicativos. Esse padrão de pares livres minimiza o impacto da mudança. Por outro lado, a abordagem ponto a ponto de conversão de dados do formato de um aplicativo para outro significa que uma mudança em um aplicativo se propaga em outros, introduzindo fragilidade e inflexibilidade.

A abordagem padrão não é nova, nem é a cura para todos os males. Mas, ao compreender as melhores práticas recomendadas, iniciar uma abordagem pequena e disciplinada, o modelo principal é um importante passo para desemaranhar a hairball da integração. Os analistas de negócios precisam compreender as quatro técnicas do modelo principal e determinar quais delas melhor se encaixam em seus projetos.

Modelagem de dados padrão, para aplicativos construídos de forma personalizada, data warehouses ou soluções de MDM, que elimina a necessidade de transformar os dados durante a sua movimentação dentro dos limites do sistema, uma vez que eles têm a mesma definição em qualquer lugar. Por exemplo, o campo de dados "saldo médio da conta" têm a mesma definição em todas as tabelas de data warehouse que as utilizam.

Modelagem de troca padrão, , uma técnica para análise e processo de mapeamento de dados enxuto e ágil, que utiliza um modelo de dados lógico e glossário de negócios personalizado para um setor específico (por exemplo, bancário, telecom, seguros) ou um domínio de negócios (como finanças, RH, manufatura, vendas).

Formatos físicos padrão, para pares extremamente livres, como em um contexto B2B. O objeto principal é uma "mensagem", frequentemente em XML, mas qualquer padrão, incluindo arquivos simples, funcionará. O importante é que a definição da mensagem seja relativamente estável e inclua um contexto específico de processo de negócios.

Objetos de negócios padrão, para passar objetos complexos de forma serial entre aplicativos, como um objeto de fatura entre a entrada de pedido, a realização, a entrega e o faturamento. Uma solução moderna para isso são os Serviços de dados dinâmicos, como os implementados na plataforma de integração da Informatica.

Quer saber mais? Participe da discussão no LinkedIn.

John Schmidt

19 de julho de 2013

Para arquitetos

Ao compreender as práticas recomendadas, iniciar uma abordagem pequena e disciplinada, o modelo principal é um importante passo para desemaranhar a hairball da integração.”