Resposta direta
A arquitetura começa antes do desenho técnico. Cada campo de dado precisa de dois registros: qual sistema é a fonte e qual área responde por corrigi-lo. Sem isso, a integração apenas transporta a divergência de um ponto para outro. O trabalho é montar uma tabela de posse por campo, revisar com as áreas envolvidas e só então definir o que conecta o quê. A tabela fica desatualizada se ninguém a mantiver, por isso convém tratá-la como documento vivo, com responsável nomeado e revisão periódica. O critério não é chegar à arquitetura ideal, e sim ter uma referência que duas áreas possam consultar e chegar à mesma resposta.
- Objetivo
- Organizar um processo
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a posse de cada campo como decisão anterior à integração, em vez de usar a conexão entre sistemas como ponto de partida.
A ordem que costuma funcionar
Começar pela lista de campos, não pelo diagrama de sistemas. Para cada campo, apontar o sistema que o origina e a área que responde por ele. Campos sem fonte clara indicam onde a integração vai gerar conflito.
Depois dessa lista, agrupar por origem e desenhar as conexões. Conexões entre dois sistemas que não têm fonte definida para o mesmo campo tendem a criar cópias divergentes. A ordem importa: definir posse primeiro reduz retrabalho no desenho.
Quando dois sistemas discordam
Discordância é esperada. O que falta é regra de precedência: qual fonte prevalece quando os valores divergem, e quem arbitra a correção. Sem regra, cada área corrige o dado no sistema que tem à mão, e a divergência se multiplica.
A regra precisa estar escrita e acessível. Também convém registrar quando a divergência ocorreu e qual decisão foi tomada, para que o histórico mostre o padrão e não a exceção de cada dia.
O que o mapa não resolve
O mapa de posse não corrige dados errados já gravados, nem uniformiza regras de negócio que divergem entre áreas. Ele define quem responde, não o valor correto. Conflito sobre o que é um cliente ativo, por exemplo, é decisão de negócio, não de arquitetura.
Também não dispensa medição. Se não se acompanha com que frequência os campos divergem, o mapa vira documento parado. E não substitui a decisão sobre o que deixar fora da integração: nem todo dado precisa circular.
Recurso prático
Roteiro para montar a tabela de posse de dados
- Listar os campos que circulam entre sistemas, começando pelos que alimentam relatório ou decisão.
- Para cada campo, anotar o sistema de origem e a área que responde por ele.
- Marcar os campos sem fonte definida ou com mais de um sistema reivindicando a origem.
- Escrever a regra de precedência para os campos em conflito e nomear quem arbitra a correção.
- Definir a periodicidade de revisão e o responsável por manter a tabela atualizada.
O ponto mais ignorado é o campo que nasce em dois sistemas ao mesmo tempo. Costuma ser tratado como exceção, mas é o que gera mais retrabalho quando a integração entra em produção.
Sobre o que está escrito aqui
Conceitos relacionados: fonte de verdade · posse do dado · campo de dado · regra de precedência · responsável pela correçã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
- Migração de dados: o que conferir antes e depois — migração sem conferência
- APIs e integração: o que perguntar antes de c… — sistema sem integração
Páginas relacionadas
O mesmo problema em outro objetivo
- Arquitetura sem mapa: como reconstruir o caminho do dado — Diagnosticar
- Arquitetura de integração: o que comparar antes de decidir — Comparar alternativas
- 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
- Cliente duplicado entre áreas: quem decide o cadastro certo — Processo para definir responsável, identificador único e regra de precedência no cadastro do mesmo cliente entre áreas.
- Duas fontes para o mesmo indicador: qual prevalece — Regras para usar duas fontes no mesmo indicador: qual é a oficial, como conciliar diferenças e o que fazer quando elas divergem.
- Exportações manuais: como medir o custo na operação — Métricas e registros para dimensionar tempo gasto, frequência de extração e retrabalho causados pelo trânsito manual de dados entre sistemas.
- Fonte única por indicador: como medir se ela existe — O que medir para saber se cada indicador tem fonte única: origem do dado, quem responde pela correção e como a divergência reaparece.
- Planilha de apoio sem versão controlada: o que exigir — O que definir sobre dono, histórico e versão vigente antes de contratar uma solução que substitua a planilha de apoio sem controle de versão.