Resposta direta
Contratar arquitetura é comprar decisão, não desenho. O contrato precisa nomear quem decide o quê, qual entregável encerra cada etapa e qual critério permite aceitar ou recusar. Sem isso, a proposta mais detalhada vence por aparência. Na prática, vale exigir o registro das alternativas descartadas, o motivo de cada escolha e o custo de manutenção associado. Arquitetura sem responsável definido vira documento que ninguém usa depois da entrega. O que se avalia é a clareza das decisões e a possibilidade de outra equipe dar continuidade ao trabalho sem refazer o caminho.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a contratação de arquitetura como compra de decisão documentada, não como escolha de fornecedor ou de ferramenta.
O que está sendo comprado
Arquitetura é um conjunto de decisões sobre como os sistemas se dividem, trocam dados e evoluem. Contratar esse trabalho é comprar decisão registrada, com o motivo de cada escolha. O desenho é consequência disso.
Quando o escopo fala apenas em entregar documentos, o resultado costuma ser um material que descreve o estado atual sem dizer o que muda. A diferença entre descrição e decisão aparece na primeira alteração de escopo depois da entrega.
Comparação entre propostas
A comparação fica possível quando as propostas respondem às mesmas perguntas: quais decisões estão em jogo, quem responde por cada uma, o que fica fora do escopo e qual critério encerra a etapa. Extensão de documento não indica qualidade.
Vale pedir o registro das alternativas descartadas. É nele que aparece se a equipe avaliou caminhos diferentes ou apenas formalizou o que já estava decidido antes da contratação.
O que a arquitetura não resolve
Arquitetura não corrige cadastro duplicado, não cria dono de dado onde não existe e não substitui operação disciplinada. Se a base de referência é disputada por áreas, nenhum desenho sobrevive à primeira divergência.
Também não garante redução de custo nem prazo de entrega. O que ela pode oferecer é previsibilidade de mudança: fica mais claro o que cada alteração afeta e quem precisa concordar. Sem essa leitura, a contratação vira compra de documento.
Recurso prático
Sequência de contratação de um trabalho de arquitetura
- Descrever a decisão que precisa ser tomada, o que depende dela e quem responde por ela.
- Pedir as alternativas consideradas, com o motivo do descarte de cada uma.
- Definir o entregável que encerra cada etapa e o critério de aceite correspondente.
- Registrar o custo de manutenção previsto e quem assume a continuidade depois da entrega.
- Comparar as propostas pelo mesmo conjunto de decisões, não pela extensão do documento.
O erro mais comum é aceitar o documento de arquitetura sem saber quem decide depois que o fornecedor sai. Sem responsável nomeado, cada mudança reabre a mesma discussão e o trabalho precisa ser refeito.
Conceitos usados nesta página
- Critério de aceite — Critério de aceite é a condição objetiva que define quando uma entrega, tarefa ou automação é considerada concluída — verificável por quem recebe, não por quem produziu.
Sobre o que está escrito aqui
Conceitos relacionados: decisão de arquitetura · critério de aceite · registro de alternativas descartadas · responsável pela decisão · custo de manutençã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
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
- Validação na entrada: onde o dado errado nasce — dado errado na origem
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 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
Outras leituras em Integrações, sistemas e qualidade de dados
- Sistemas desconectados: como comparar as saídas possíveis — Critérios práticos para comparar a troca por sistema único, o desenvolvimento de integrações ou a manutenção de rotinas manuais estruturadas.
- Campo com formatos diferentes: o que exigir no contrato — O que acordar ao contratar tratamento para campo preenchido de formas diferentes: regra única, responsável definido e critério de aceite verificável.
- Migração contratada: o que a proposta não cobre — O que precisa estar definido em escopo, aceite e responsabilidade para contratar uma migração de dados, e o que a proposta costuma deixar em aberto.
- Relatório sem validação cruzada: o que cobrar na contratação — O que exigir no escopo de um relatório para que os números sejam conferidos contra outra fonte, com critério de aceite e responsável definidos.
- Integração sem documentação: como avaliar antes de contratar — O que verificar em uma integração sem documentação antes de contratar: evidências que substituem o histórico, escopo do contrato e limites da avaliação.