Vou começar pela parte que consultoria costuma não dizer: implantar TOGAF numa PME é desperdício. O ADM completo — oito fases, repositório de arquitetura, comitê de governança, ciclo formal de conformidade — foi desenhado para organizações com centenas de sistemas e dezenas de times que não se falam. Numa empresa de 20 pessoas, isso é cerimônia que consome o tempo que deveria ir para o problema.
Mas descartar o framework inteiro também sai caro, porque ele codifica quatro coisas que empresa pequena erra com frequência e que custam anos para desfazer. Este artigo separa o que sobrevive da redução de escala.
1. O que não vale a pena
- O ciclo formal das oito fases. Entre a fase de visão e a de implementação se passam meses. A PME decide em semanas, e deve mesmo.
- O repositório de arquitetura completo. Manter catálogo, matriz e diagrama de tudo exige alguém dedicado. Sem essa pessoa, o repositório fica desatualizado em três meses e passa a mentir — pior que não existir.
- O comitê de governança. Com 20 pessoas, quem decide já está na sala.
- O vocabulário. "Capability increment", "architecture landscape". Se o termo não muda a decisão, ele só cria dependência de quem fala a língua.
2. O que sobrevive — e por quê
Baseline antes de target
A regra mais barata e a mais ignorada: descrever o que existe hoje antes de decidir o que vem depois. A maioria das decisões ruins de TI em PME nasce de comprar a solução antes de mapear o que já está contratado — e o resultado é ferramenta nova resolvendo o que uma licença ociosa já resolvia.
Na prática: uma página listando sistemas em uso, para que servem, quanto custam e quem depende deles. Não é diagrama, é inventário. Leva uma tarde e muda a conversa.
Análise de lacuna, e não de catálogo
A pergunta certa não é "qual a melhor ferramenta de X", e sim "qual a distância entre onde estamos e onde precisamos estar, e qual o menor passo que fecha essa distância". Isso troca a comparação de funcionalidades — que o fornecedor sempre vence — por uma medida do seu problema.
Decisão registrada, com alternativa descartada
Este é o item de maior retorno. Toda decisão estrutural vira um registro curto que inclui o que foi descartado e por quê. Dois anos depois, quando alguém perguntar "por que estamos nisso?", a resposta existe — e a empresa para de refazer o mesmo debate a cada troca de pessoa.
# ADR 0007 — Fila entre WhatsApp e ERP Data: 2026-09-12 Status: aceita # proposta | aceita | substituída por ADR-NNNN Reversibilidade: alta # alta = desfaz em dias | baixa = meses, ou nunca ## Contexto ERP processa 5 pedidos/s. Pico de campanha chega a 40/s. Medição de 12/09: 79% dos pedidos recusados no pico. ## Decisão Inserir fila entre o canal e o ERP. Confirmação ao cliente passa a sair na entrada da fila, não na gravação do pedido. ## Alternativas descartadas - Aumentar o ERP: fornecedor cobra por faixa; custo anual > 4x o da fila. - Limitar campanha: reduz receita para resolver problema técnico. ## Consequências - Nenhum pedido perdido; espera pode chegar a 7 min no pico. - Passa a existir um componente a operar: exige monitorar profundidade e DLQ. - Consumidor precisa ser idempotente (entrega ao menos uma vez). ## Revisar quando Pico sustentado passar de 60/s, ou espera máxima passar de 15 min.
Quatro coisas fazem esse modelo funcionar onde documento de arquitetura costuma morrer: cabe numa tela, cita medição em vez de opinião, nomeia o que foi descartado, e tem gatilho de revisão. Sem o gatilho, o registro vira arqueologia.
Gate com três saídas
O ADM prevê conformidade em cada fase. A versão reduzida é o gate que usamos em todo projeto: aprovado, falha corrigível ou bloqueio — nunca "segue assim mesmo". Não exige comitê. Exige que exista um momento nomeado em que alguém olha e decide, e que "avançar por presunção" não seja uma das opções.
3. O critério que decide quanto rigor aplicar
Nem toda decisão merece registro. O filtro que usamos é a reversibilidade:
- Porta de duas mãos — dá para voltar em dias, com custo baixo. Escolha de biblioteca, layout de tela, ferramenta de monitoramento. Decida rápido, não registre, siga.
- Porta de uma mão — voltar custa meses ou não é viável. Modelo de dados, formato de identificador, ERP, provedor de pagamento, quem é dono do cadastro do cliente. Essas merecem inventário, lacuna, ADR e gate.
Aplicar rigor de porta de uma mão em decisão de duas mãos é exatamente o que faz TOGAF parecer burocracia. O inverso — decidir o irreversível no improviso — é o que produz os projetos que levam três anos para serem desfeitos.
Nota de honestidade: nada aqui torna a empresa "aderente ao TOGAF", e não é esse o objetivo. É um recorte deliberado, escolhido por caber numa operação pequena. Quem precisar de aderência formal — por exigência contratual ou de auditoria — precisa do framework completo e de quem o sustente.
4. O resumo
De TOGAF, uma PME precisa de quatro coisas: saber o que já tem antes de comprar, medir a lacuna em vez de comparar funcionalidades, registrar decisão irreversível com a alternativa descartada, e ter um gate que pode bloquear. O resto do framework pressupõe uma escala que você não tem — e pagar por ela é o mesmo erro de comprar o sistema antes do inventário.
É esse recorte que sustenta os quatro princípios descritos em como o trabalho é organizado.
Tem uma decisão de porta de uma mão em cima da mesa?
Diagnóstico sem custo: mapeamos o que já existe, medimos a lacuna e devolvemos o ADR pronto — inclusive quando a recomendação é não comprar nada.