Governança técnica sem critério explícito produz um de dois extremos com custo alto. Aprovação em cascata: cada decisão técnica sobe até alguém sem contexto suficiente para decidir bem. Ou autonomia total: cada time escolhe tecnologia, padrões e abordagem sem coordenação. Nos dois casos, o custo de integração e manutenção cresce sem sinal visível até o stack se tornar o gargalo de qualquer iniciativa.
Subcapability 02 de 05 · Arquitetura Corporativa
Governança Técnica
Architecture Decision Records e fitness functions como código que habilitam autonomia técnica dentro de critério explícito, substituindo o comitê de aprovação por coerência sistêmica verificável.
O que está em jogo
O time de cada squad toma decisões técnicas de forma independente. Em seis meses, a integração entre áreas virou projeto de dois trimestres porque cada time escolheu abordagens incompatíveis. O arquiteto é convidado para resolver o problema depois que o custo já foi pago. Governança técnica que chega depois do dano tem o custo dobrado: o trabalho de remediar e o trabalho que precisou parar para isso.
O que é, na prática
Como atuamos
Architecture Decision Records ativos
Implementamos ADRs como prática viva, não como documento arquivado: cada decisão estrutural documentada com contexto, alternativas avaliadas e raciocínio, acessível no repositório e consultada antes de novas decisões.
Fitness functions no pipeline
Automatizamos a validação de conformidade arquitetural no pipeline de entrega, para que violações de padrão de acoplamento, camadas ou dependência sejam detectadas no momento em que surgem, não em auditoria trimestral.
Policy as Code com critério de infraestrutura
Codificamos políticas de infraestrutura com Open Policy Agent, tornando guardrails verificáveis automaticamente em cada deploy e eliminando a dependência de revisão manual em cada mudança de configuração.
Critério de decisão por tipo de escolha
Definimos o que cada time decide sozinho, o que exige alinhamento entre times e o que envolve revisão de arquitetura, para que cada decisão siga o processo certo sem sobrecarregar o arquiteto com o que não precisa de sua aprovação.
Ciclo de revisão de padrões com cadência definida
Estabelecemos revisão periódica dos padrões arquiteturais com frequência adequada ao ritmo de mudança da organização, para que as ADRs reflitam o estado atual e não se tornem documentos históricos que ninguém consulta.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Tempo entre proposta e decisão arquitetural
Critério explícito sobre o que requer revisão e o que pode avançar com autonomia reduz o tempo de espera por aprovação arquitetural. O que levava semanas de agendamento e reunião passa a seguir processo com prazo definido.
Incidentes causados por decisões técnicas inconsistentes entre times
Fitness functions que detectam violação de padrão no pipeline evitam que inconsistências entre times cheguem a produção. Cada violação detectada no commit tem custo menor que a mesma violação descoberta em incidente.
Custo de integração entre sistemas de times distintos
Times que operam com critério compartilhado sobre interfaces, padrões de comunicação e contratos de serviço produzem sistemas que integram mais rápido e com menos retrabalho do que times que descobrem incompatibilidade durante a integração.
Velocidade de onboarding de novo arquiteto ou tech lead
ADRs que documentam o raciocínio por trás de cada decisão reduzem o tempo que um novo membro leva para entender por que o sistema foi construído da forma que foi, substituindo transferência oral por registro consultável.
Perguntas frequentes
Architecture Decision Records são o mesmo que documentação técnica?
ADRs documentam a decisão e o raciocínio por trás dela, não a implementação. A diferença é que documentação técnica explica como algo funciona. ADR explica por que foi feito assim, quais alternativas foram consideradas e em que contexto a decisão faz sentido. Quando o contexto muda, o ADR que documenta a decisão original é o ponto de partida para reavaliar.
Como evitar que o processo de ADR vire burocracia que ninguém usa?
Limitando o escopo a decisões realmente estruturais, aquelas com custo alto de reverter, e mantendo o formato curto. Uma boa ADR cabe em uma página. O critério de quando escrever um ADR é simples: se a decisão vai custar mais de um sprint reverter, merece registro. Se cabe em um comentário de PR, não precisa de ADR.
Fitness functions funcionam com qualquer linguagem e stack?
Fitness functions são independentes de linguagem. São verificações automatizadas que validam propriedades do sistema: acoplamento, cobertura de testes por camada, conformidade com padrões de nomenclatura, tempo de build. Cada propriedade arquitetural que pode ser medida pode virar uma fitness function. A implementação depende do stack, mas o conceito é universal.
Como implementar governança em organizações com múltiplos times autônomos?
Separando o que é padrão da empresa, o que é padrão por domínio e o que é autonomia do time. Padrões de empresa valem para todos e são poucos. Padrões por domínio valem para times que compartilham contexto técnico. Autonomia do time cobre o que é detalhe de implementação. Governança eficaz define claramente os três níveis.
Quando faz sentido ter um Architecture Review Board?
Quando há decisões recorrentes com impacto sistêmico e nenhum processo formal de revisão. O ARB resolve o problema de coordenação, mas só enquanto não há ADRs e fitness functions que documentem e validem os critérios automaticamente. À medida que os critérios se tornam explícitos e verificáveis, o ARB pode ter cadência menor e foco em decisões genuinamente novas.
Outras subcapabilities desta capability
Anti-Overlap de Sistemas
Racionalização de portfólio pelo framework TIME que expõe ao CFO onde licença, manutenção e integração duplicada consomem orçamento sem entregar valor incremental.
Mapa de Capacidades de Negócio
Mapa estável de capacidades de negócio pelo padrão TOGAF que sobrevive a reorgs, ancora decisão de investimento em impacto financeiro e expõe onde o gap técnico limita resultado.
Technology Radar
Technology Radar com quatro anéis que torna adoção tecnológica processo deliberado com evidência operacional e protege o board de decisão por hype de fornecedor.
Modernização de Legado
Estratégia 6Rs com Strangler Fig que substitui reescrita total arriscada por modernização incremental onde cada etapa entrega retorno verificável e protege receita durante a transição.
Quer clareza sobre onde investir primeiro?
Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.