Resposta direta
Reconstruir a arquitetura começa por um dado, não pelos sistemas. Toma-se um campo crítico, como valor do pedido ou código do cliente, e segue-se o que acontece com ele desde a origem até o último ponto em que é usado. Em cada trecho, quatro registros: onde nasce, o que altera o valor, onde é consumido e quem responde por ele. O produto não é um diagrama de fornecedores, e sim a lista de trechos sem responsável, sem teste ou sem registro. É essa lista que indica onde intervir primeiro.
- Objetivo
- Diagnosticar
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a arquitetura pelo caminho de um campo crítico, e não pela lista de sistemas ou de integrações existentes.
O inventário de sistemas não descreve a arquitetura
A lista de sistemas contratados, com módulos e contratos, descreve o que foi comprado, não o que acontece com o dado. Dois sistemas podem estar conectados e, ainda assim, o valor de um campo mudar no meio do percurso sem que ninguém saiba em qual ponto.
O inventário costuma registrar a integração como um par de sistemas. Na prática, um único campo passa por vários pontos: cadastro, pedido, faturamento, relatório. Cada ponto tem regra própria. É nessas regras, e não nos nomes dos fornecedores, que a arquitetura se define.
O que registrar em cada trecho do caminho
O registro de um trecho tem cinco campos: onde o dado nasce, o que altera o valor, onde é consumido, quem responde pela regra e como isso é verificado. Sem a forma de verificação, o registro é declaração de intenção, não mapa.
A verificação é uma consulta ou um teste que qualquer pessoa da equipe consegue repetir sozinha. Quando o responsável sai, o registro continua útil porque a verificação não depende de quem o escreveu. O mapa cresce por campo crítico, não por sistema.
O que o levantamento não resolve
O levantamento não corrige o dado nem conserta a integração. Ele mostra onde a responsabilidade não está definida e onde a verificação não existe. Corrigir é etapa separada, com custo, prazo e risco próprios, e pode exigir decisão que o mapa não sustenta.
Ele também não cobre fluxos que a empresa ainda não conhece e perde validade quando sistemas ou regras mudam. Se ninguém consegue nomear o responsável por um trecho, o registro não substitui essa decisão. O documento vira lista de intenções.
Recurso prático
Cobertura do caminho do dado por campo crítico
CMC = campos críticos com origem, transformação, destino e responsável definidos dividido pelo total de campos críticos
- Total de campos críticos
- campos
- campos cujo erro ou ausência interrompe faturamento, atendimento ou obrigação de registro
- Campos com caminho completo
- campos
- campos cujos origem, transformação, destino e responsável estão registrados de forma verificável
- Campos sem verificação
- campos
- campos com caminho descrito, mas sem consulta ou teste que outra pessoa consiga repetir
O erro mais comum é considerar o trecho definido porque existe integração ativa entre dois sistemas. Integração em produção não equivale a caminho registrado: sem a transformação do valor e o responsável nomeados, o campo continua sem dono.
Sobre o que está escrito aqui
Conceitos relacionados: campo crítico · origem e destino do dado · transformação intermediária · responsável pela regra · inventário de integrações. 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
- Exportações manuais: quando ainda fazem sentido — exportações manuais
- Migração de dados: o que conferir antes e depois — migração sem conferência
Páginas relacionadas
O mesmo problema em outro objetivo
- Dono de cada dado: mapa antes de integrar mais um sistema — Organizar um processo
- 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
- Alterações no cadastro: o que medir no histórico — Define indicadores para o registro de alteração no cadastro: cobertura de campos críticos, autor, data, valor anterior e os limites desse histórico.
- Duas fontes para o mesmo indicador: como escolher a base — Definição de qual das duas fontes passa a valer para um indicador, o que a escolha exige em registro e o que ocorre com a base que perde a disputa.
- Integração que passa em homologação: o que isso não prova — Mostra como comparar o que o teste de integração exercitou em ambiente controlado com o que a operação real apresenta, e onde a cobertura fica fina.
- Dependência de uma pessoa para extrair dado: como avaliar — O que fazer quando a extração de dados depende de uma pessoa: o que documentar, o que exigir do fornecedor e o que a contratação não resolve.
- Dado sem origem: o que registrar a partir de agora — Processo para lidar com dado cuja origem não foi registrada: onde buscar o que existe, quem responde por cada campo e o que anotar a cada mudança.