O comité que todos evitam
Em muitas organizações, rever uma arquitetura antes da produção significa apresentá-la a um comité que se reúne de duas em duas semanas, devolve uma lista de objeções sem prioridade e volta a rever tudo na ronda seguinte. As equipas aprendem a contorná-lo, e o padrão deixa de ser cumprido.
O problema não é rever. É rever sem uma norma escrita e sem distinguir o grave do menor.
Rever face a uma norma, não face a opiniões
Uma homologação útil compara o desenho com um padrão escrito da organização: que zonas devem existir, que serviços são permitidos, como se gerem identidades, segredos, registos, cópias de segurança e custos. Se uma regra não está escrita, não se pode exigir.
Um parecer, não uma lista de «mas»
O resultado da revisão é um parecer em que cada desvio tem:
- A regra que incumpre, citada.
- A sua gravidade:
- Bloqueante: impede a passagem a produção (por exemplo, dados sensíveis expostos à internet).
- Maior: deve ser corrigido num prazo acordado (por exemplo, sem cópias de segurança testadas).
- Menor: corrige-se na iteração seguinte (por exemplo, etiquetagem incompleta).
- Observação: sugestão sem obrigação.
- Uma proposta de correção, não apenas o problema.
Com essa classificação, a decisão é simples: sem bloqueantes, avança-se; com bloqueantes, corrige-se só isso e revê-se só isso.
Como fazer para que não trave
- Norma pública e estável, para que as equipas desenhem a cumpri-la desde o início.
- Revisões a pedido, não por calendário de comité.
- Automatizar o que é verificável: etiquetas, cifragem, exposição de rede e outros pontos validam-se sozinhos com a infraestrutura como código. A revisão humana concentra-se no que exige critério.
- Exceções documentadas, com responsável e data de revisão, em vez de proibições que todos contornam.
Como o aplicamos: Arquitetura Cloud.