Resposta direta
A comparação começa pelo que a integração sustenta, não pelo que ela faz. Antes de escolher entre documentar, reescrever, substituir ou manter com controles, é preciso saber quem depende dela, o que quebra quando falha e se existe ambiente para testar. O caminho mais barato raramente é o mais seguro. Documentar o que existe reduz incerteza, mas não corrige desenho ruim. Reescrever dá clareza, mas cria risco novo. Substituir resolve a origem, mas pode custar mais do que o problema. Manter com controles é defensável quando o volume é baixo e o erro é visível.
- Objetivo
- Comparar alternativas
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Compara os quatro caminhos pelo custo de teste, pelo responsável e pela reversibilidade, em vez de tratar documentação como sinônimo de controle.
O que a integração sustenta hoje
Antes de discutir solução, vale levantar o que depende da integração: quais rotinas param, quais relatórios ficam sem base, quem confere o resultado no dia seguinte. Esse levantamento costuma revelar que a integração é maior do que o trecho de código que a implementa.
Também importa separar o que é regra de negócio do que é improviso acumulado. Parte do comportamento atual existe por um motivo que ninguém registrou; outra parte existe porque era o caminho possível na época. As duas coisas exigem tratamento diferente.
Quatro caminhos e o que cada um cobra
Documentar, reescrever, substituir e manter com controles não são etapas de uma mesma evolução. São escolhas com custo e risco distintos. A comparação fica útil quando cada alternativa é descrita pelo que exige em teste, por quem responde por ela e pelo que acontece se der errado.
O critério decisivo costuma ser a reversibilidade. Um caminho que permite voltar atrás em pouco tempo tolera mais incerteza. Um caminho sem volta precisa de evidência maior antes de começar, mesmo que pareça mais limpo no papel.
O que a comparação não resolve
Comparar alternativas não cria dono. Se ninguém responde pela integração, qualquer caminho escolhido volta ao mesmo ponto: falha sem responsável e correção por urgência. A decisão precisa vir junto com a definição de quem acompanha, quem aprova mudança e quem confere o dado.
Também há situações em que nenhuma das quatro opções cabe no momento: sistema prestes a ser descontinuado, contrato travado ou operação sem ambiente de teste. Nesses casos, o realista é reduzir exposição com controles provisórios e registrar o que ficou pendente, sem apresentar isso como solução.
Recurso prático
Quatro caminhos para uma integração sem documentação
| Caminho | O que exige | Quando deixa de fazer sentido |
|---|---|---|
| Documentar o que existe | Leitura do código e dos logs, conversa com quem opera, registro do contrato de dados real | Quando o desenho impõe erro recorrente e o registro só descreve o problema |
| Reescrever a integração | Especificação do comportamento atual, ambiente de teste, comparação de saídas antes da troca | Quando não há como reproduzir o comportamento atual nem medir diferença |
| Substituir o sistema de origem | Avaliação dos dados a migrar, dependências externas e prazo de convivência entre os dois | Quando o custo de migração supera o risco que a integração atual impõe |
| Manter com controles | Monitoramento de falha, conciliação periódica e dono nomeado para responder | Quando o erro passa despercebido por quem usa o dado |
O erro mais comum é escolher reescrever por desconforto com o código antigo, sem medir quanto custa reproduzir o comportamento atual. Sem essa comparação, a reescrita troca um problema conhecido por um desconhecido.
Sobre o que está escrito aqui
Conceitos relacionados: mapa de dependências · contrato de dados · teste de regressão · responsável pela integração · janela de substituição. 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
- Planilhas divergentes: o que exigir na contra… — planilhas divergentes
- Cadastros duplicados: como desenhar o fluxo d… — cadastros duplicados
Páginas relacionadas
O mesmo problema em outro objetivo
- Integração sem documentação: como reconstruir o que ela faz — Diagnosticar
- Integração sem documentação: como reconstruir o registro — Organizar um processo
- Integração sem documentação: como medir o que ficou — Explicar medição
- Integração sem documentação: por onde reconstruir o contrato — Orientar implementação
- Integração sem documentação: como avaliar antes de contratar — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- 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.
- 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.
- 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.
- Arquitetura de integração: o que comparar antes de decidir — A página compara arquiteturas de integração por onde mora a regra, quem responde pelo dado, reversibilidade e custo de mudança ao longo do tempo.
- 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.