Resposta direta
Comparar arquitetura de integração começa por quatro perguntas: onde mora a regra de negócio, quem responde pelo dado quando ele diverge, o que acontece quando um sistema sai do ar e quanto custa desfazer a escolha. As opções raramente se separam por desempenho. Separam-se por reversibilidade e por concentração de responsabilidade. Uma arquitetura centraliza a decisão e facilita auditoria, mas cria dependência de um ponto. Uma arquitetura distribuída reduz o ponto único, mas espalha a regra e torna a conferência mais difícil. A comparação só é honesta quando os dois lados são descritos com o mesmo nível de detalhe operacional.
- Objetivo
- Comparar alternativas
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Compara as arquiteturas pelo comportamento em falha, pela responsabilidade sobre o dado e pelo custo de desfazer, e não pelo desenho.
Onde os desenhos realmente divergem
Na prática, três arranjos aparecem: cada par de sistemas conversa direto, tudo passa por um ponto central, ou os sistemas compartilham uma base comum. A diferença visível é o desenho. A diferença que pesa é operacional: quantos lugares precisam ser alterados quando uma regra muda, quantos contratos de dados existem para manter e em quantos pontos uma falha interrompe o fluxo.
Também muda quem percebe o erro primeiro. Em ligações diretas, o erro aparece no sistema que recebeu. Em ponto central, aparece na fila. Em base compartilhada, aparece tarde, quando alguém confere um relatório. Esse tempo até a percepção costuma importar mais do que a velocidade de transmissão.
Responsabilidade e custo de mudança
Toda arquitetura distribui responsabilidade. Se a regra de cálculo mora no sistema de origem, a integração apenas transporta. Se mora no ponto central, a origem perde autoridade sobre o próprio dado. Se mora na base compartilhada, ninguém responde sozinho. Definir isso antes evita discussão depois, quando o número divergir e não houver dono claro.
O segundo critério é o custo de desfazer. Arranjos com menos acoplamento são mais fáceis de trocar, mas exigem mais disciplina de contrato. Arranjos concentrados são rápidos de montar e caros de desmontar. A pergunta útil não é qual é o melhor, e sim qual erro a empresa tolera melhor: manter uma regra duplicada ou depender de um ponto que, se parar, para o fluxo inteiro.
O que a comparação não decide
Comparar arquitetura não resolve qualidade de dado na origem. Se o cadastro entra errado, nenhum desenho de integração corrige. Também não resolve conflito de prioridade entre áreas: a arquitetura define o caminho, não quem manda no processo.
Há situações em que a decisão é prematura. Quando o volume é baixo e o processo muda a cada mês, uma ligação direta simples e uma conferência manual periódica podem bastar. Montar arranjo elaborado antes de estabilizar a regra costuma gerar retrabalho. A comparação pressupõe que a regra já está clara o bastante para ser transportada sem interpretação.
Recurso prático
Roteiro para comparar duas arquiteturas lado a lado
- Listar cada fluxo de dado por origem, destino, frequência e quem consome o resultado. Sem essa lista, a comparação fica no abstrato.
- Para cada fluxo, marcar onde a regra de negócio é aplicada e qual sistema responde pelo valor final.
- Descrever o comportamento de cada opção em três situações: origem indisponível, dado divergente e mudança de regra. Anotar quem é acionado em cada caso.
- Estimar o esforço de alterar uma regra e de desfazer a integração, em horas de trabalho e em número de contratos de dados afetados.
- Registrar a decisão com data e premissa usada. Revisar quando o volume ou a regra mudar.
O erro mais comum é comparar as opções pelo desenho e não pelo comportamento em falha: duas arquiteturas parecem equivalentes no diagrama e se separam quando um sistema cai ou um número diverge.
Sobre o que está escrito aqui
Conceitos relacionados: acoplamento entre sistemas · contrato de dados · ponto único de falha · responsabilidade sobre o dado · custo de mudança. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Números que não batem: por que a divergência… — planilhas divergentes
- Sincronização entre sistemas: o que decidir a… — sistemas desconectados
Páginas relacionadas
O mesmo problema em outro objetivo
- Arquitetura sem mapa: como reconstruir o caminho do dado — Diagnosticar
- Dono de cada dado: mapa antes de integrar mais um sistema — Organizar um processo
- Arquitetura: como medir o que ela entrega na operação — Explicar medição
- Fonte da verdade: qual sistema responde por cada dado — Orientar implementação
- Contratar arquitetura: o que fica definido e por quem — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Exportação como integração permanente: o que formalizar — O que uma exportação precisa ter para virar integração permanente: contrato de dados, responsável, conferência de fechamento e critério de falha.
- Integração sem documentação: o que comparar antes de mexer — Compara quatro caminhos para uma integração sem documentação e indica o que observar em cada um: dependências, teste, responsável e custo de erro.
- Data e hora sem fuso: o que exigir no contrato — O que declarar, testar e escrever no contrato ao receber dados com data e hora sem fuso, e onde essa exigência não resolve.
- APIs sem dono: como definir responsabilidade e contrato — O que registrar para cada API em uso: operação dependente, área responsável, contrato de dados e versão, além do combinado para descontinuar.
- Integração por API: o que definir antes de ir para produção — O que precisa estar definido antes de uma API entrar em produção: contrato de dados, comportamento em falha, reprocessamento e responsável pela integração.