Integração não é detalhe técnico. É parte do problema de negócio.
Quando sistemas precisam operar como uma única cadeia, contratos, estados, falhas e reconciliação passam a fazer parte da experiência e do resultado do negócio.
Em muitos projetos, integração aparece no final da conversa.
Primeiro se discute a tela. Depois o fluxo. Em seguida as funcionalidades. E, quase como um detalhe de implementação, surge a frase: “depois integramos com o ERP”.
Em operações complexas, essa ordem costuma criar problemas.
Integração não é apenas uma questão de conectar sistemas. Ela determina como dados, decisões e estados operacionais atravessam a empresa.
Uma API funcionando não significa que a operação está integrada
É possível ter uma chamada tecnicamente bem-sucedida e ainda assim construir um processo frágil.
O sistema de origem enviou. O destino recebeu. Mas qual sistema é dono daquele dado? O que acontece quando existe conflito? Quem pode reenviar? Como uma correção volta para a origem? Como saber se os dois lados continuam consistentes?
É coordenação de estados, regras, responsabilidades e tratamento de exceções entre sistemas.
O primeiro desenho deve ser de responsabilidade
Antes de escolher protocolo, middleware ou ferramenta, é necessário definir qual sistema é fonte de verdade para cada informação e qual evento desencadeia cada transição.
Sem isso, integrações tendem a criar cópias concorrentes de uma mesma realidade.
Falha é parte do desenho
Redes falham. Sistemas ficam indisponíveis. APIs respondem lentamente. Filas acumulam mensagens. Dados chegam incompletos.
A arquitetura precisa assumir que isso acontecerá.
Integração afeta diretamente a experiência do usuário
Uma tela pode indicar “pedido concluído” enquanto o ERP ainda não registrou nada. Um cliente pode receber uma cobrança que já havia sido cancelada. Uma área pode tomar decisão com informação desatualizada.
Esses problemas parecem de integração, mas para quem usa o sistema são problemas do produto e da operação.
O contrato entre sistemas precisa ser tratado como produto
APIs, eventos, formatos, códigos de erro e versões precisam de governança. Mudanças em um sistema não podem quebrar silenciosamente outro.
Quanto mais crítica a operação, mais importante é tratar integrações como componentes versionados, monitorados e testados.
Uma integração bem desenhada torna sistemas diferentes previsíveis uns para os outros.
Arquitetura de integração também é uma decisão de negócio
Escolher entre integração síncrona, mensageria, processamento em lote ou eventos envolve requisitos de tempo, criticidade, consistência, custo e experiência.
Não existe uma arquitetura universalmente melhor. Existe a arquitetura adequada ao risco e ao comportamento esperado do processo.
Integração é onde a arquitetura encontra a operação.
Quando ela falha, o impacto não fica restrito à tecnologia. Ele aparece em prazo, atendimento, faturamento, decisão e confiança.