Governança de arquitetura: decisões que precisam continuar fazendo sentido

Sistemas dificilmente se tornam difíceis de manter por causa de uma única decisão ruim.

O problema costuma aparecer no acúmulo.

Uma integração criada para resolver algo urgente. Uma exceção que deveria ser temporária. Um novo serviço contratado porque atendia bem a uma necessidade específica. Outro módulo implementando autenticação de um jeito diferente. Dados que começam a aparecer em mais lugares do que deveriam.

Quando olhamos cada decisão isoladamente, muitas delas fazem sentido. O problema aparece algum tempo depois, quando o conjunto começa a perder coerência.

É nesse ponto que eu situo a governança de arquitetura.

Para mim, governar arquitetura é estabelecer princípios, padrões, limites técnicos e critérios que permitam a evolução de uma solução sem exigir que todas as decisões sejam rediscutidas desde o início.

Arquitetura também é sobre decidir

Quando penso em arquitetura, a tecnologia vem depois do problema e do contexto.

Duas empresas podem ter necessidades parecidas e chegar a arquiteturas diferentes porque possuem equipes, riscos, orçamento, sistemas existentes e capacidade operacional diferentes.

Por isso, uma tecnologia ser tecnicamente boa não significa que seja adequada para qualquer cenário.

A decisão precisa considerar o que aquela escolha resolve, quais dependências cria, quanto custa manter, quem consegue operá-la e o que acontece quando a solução precisar mudar.

Sem esses critérios, discussões de arquitetura acabam facilmente virando preferência pessoal.

Um profissional prefere determinada tecnologia. Outro teve uma experiência ruim com ela. Alguém viu uma solução parecida funcionando em outra empresa. Outro quer adotar algo novo porque parece mais moderno.

Todos podem ter argumentos válidos, mas falta uma referência comum para tomar a decisão.

A governança cria essa referência.

Princípios reduzem decisões repetidas

Algumas decisões não precisam ser tomadas novamente em cada projeto.

Uma organização pode definir, por exemplo, que dados sensíveis devem permanecer em determinados ambientes, que toda integração precisa ter mecanismos claros de autenticação ou que novas dependências externas precisam ser avaliadas antes de entrar em partes críticas do sistema.

Esses princípios não dizem exatamente como implementar cada solução.

Eles definem o espaço dentro do qual as equipes podem decidir.

Isso evita que cada novo projeto comece uma discussão do zero e também ajuda a preservar decisões importantes quando as pessoas que participaram da construção inicial já não estão mais envolvidas.

Um princípio arquitetural útil precisa ajudar alguém a decidir.

Frases genéricas como “priorizar segurança”, “buscar escalabilidade” ou “utilizar boas práticas” dizem pouco quando chega a hora de escolher entre duas alternativas reais.

É mais útil definir o que precisa ser protegido, quais riscos são aceitáveis e quais consequências exigem revisão.

Padrões existem para diminuir variação desnecessária

Variação tem custo.

Se cada aplicação utiliza uma forma diferente de autenticação, cada integração segue um modelo próprio e cada equipe registra erros de maneira diferente, a organização precisa entender e manter várias soluções para problemas semelhantes.

Nem toda diferença é ruim. Algumas existem porque o problema exige.

A questão é identificar onde a liberdade técnica agrega valor e onde ela apenas cria complexidade.

Um padrão faz sentido quando evita decisões repetitivas, facilita manutenção ou reduz risco.

Ele também precisa poder ser questionado. Uma regra criada para um cenário que já não existe pode se transformar em mais um problema arquitetural.

Governança exige revisão das próprias decisões.

Limites técnicos precisam estar claros

Toda arquitetura possui limites, mesmo quando eles nunca foram formalizados.

A diferença é que, sem essa definição, as pessoas descobrem esses limites depois que alguma coisa já deu errado.

Um limite pode determinar onde determinados dados podem circular, quais componentes podem acessar uma informação, quando uma dependência externa pode ser introduzida ou até que ponto uma equipe pode alterar uma solução compartilhada.

Também pode existir um limite econômico.

Uma solução tecnicamente interessante pode aumentar custos de infraestrutura, licenciamento ou operação de uma forma que não faça sentido para o negócio.

Outro limite pode estar na própria equipe.

Adotar uma tecnologia que ninguém consegue manter sem depender permanentemente de terceiros também é uma decisão arquitetural e precisa ser tratada como tal.

Arquitetura não existe separada da capacidade de quem vai operar aquilo depois.

Nem toda decisão precisa do mesmo nível de controle

Governança que exige aprovação para qualquer mudança acaba criando um gargalo.

Eu prefiro pensar em diferentes níveis de autonomia.

Existem decisões que a equipe pode tomar livremente porque possuem impacto local e são facilmente reversíveis.

Outras precisam seguir princípios ou padrões já estabelecidos, mas continuam dentro da autonomia de quem está desenvolvendo a solução.

E existem decisões que merecem uma análise mais cuidadosa porque alteram segurança, dados, custos relevantes, dependências críticas ou componentes utilizados por várias partes do sistema.

O objetivo é concentrar atenção onde uma decisão realmente pode gerar consequências maiores.

Isso também evita transformar arquitetura em uma etapa burocrática do desenvolvimento.

Critérios são mais úteis que opiniões

Algumas decisões arquiteturais não possuem uma resposta tecnicamente correta.

Existem alternativas.

Nesse caso, o trabalho está em comparar consequências.

Eu costumo olhar para questões como:

• qual problema estamos resolvendo;
• quais riscos cada alternativa introduz;
• qual complexidade será adicionada;
• quanto esforço haverá para manter a solução;
• quais dependências serão criadas;
• se a equipe consegue operar aquilo;
• quanto custa mudar de direção no futuro;
• quais partes do sistema serão afetadas se a decisão der errado.

Esse tipo de análise muda a discussão.

Em vez de tentar descobrir qual tecnologia é “melhor”, passa-se a discutir qual escolha faz mais sentido para aquele contexto.

Registrar decisões faz parte da arquitetura

Existe outro problema comum: decisões importantes ficam na memória das pessoas.

Algum tempo depois, alguém encontra uma regra aparentemente estranha e decide removê-la.

Talvez ela realmente não seja mais necessária. Talvez tenha sido criada para resolver uma restrição que continua existindo, mas ninguém mais lembra.

O código mostra o que foi feito. Nem sempre mostra por quê.

Por isso, decisões relevantes precisam de algum nível de registro.

Não precisa ser um documento extenso. Muitas vezes, algumas informações são suficientes: qual era o problema, quais opções foram consideradas, por que determinada decisão foi tomada e em quais condições ela deveria ser revista.

Isso reduz a dependência de memória institucional e ajuda a evitar que decisões antigas sejam tratadas como verdades permanentes.

Arquitetura precisa poder mudar

Governança também precisa considerar que decisões envelhecem.

O contexto muda. O sistema cresce. A equipe muda. Uma tecnologia amadurece ou deixa de fazer sentido. Um fornecedor altera preço ou condições. Uma nova exigência de segurança aparece.

Por isso, princípios e padrões precisam orientar a evolução sem congelar a arquitetura.

Uma boa decisão arquitetural hoje pode se tornar inadequada daqui a alguns anos.

O importante é conseguir identificar por que ela existe e quais critérios justificariam sua revisão.

Quando isso está claro, mudar deixa de significar simplesmente substituir tecnologia. Passa a ser uma nova decisão tomada sobre um contexto que também mudou.

Como eu entendo uma boa governança de arquitetura

Para mim, existe um teste relativamente simples.

Uma pessoa que entra hoje em um projeto consegue entender quais decisões pode tomar sozinha, quais regras precisam ser respeitadas, onde estão os limites e por que determinadas escolhas arquiteturais foram feitas?

Se tudo depende de perguntar para quem construiu o sistema, existe conhecimento, mas ele está concentrado nas pessoas.

Se cada nova iniciativa precisa rediscutir autenticação, integração, segurança, armazenamento, infraestrutura e outras decisões já enfrentadas anteriormente, existe pouco reaproveitamento do aprendizado acumulado.

E se ninguém sabe dizer quando uma decisão precisa ser revisada, existe o risco de transformar escolhas antigas em regras permanentes.

Governança de arquitetura serve para criar esse contexto compartilhado.

Ela ajuda a manter coerência entre decisões tomadas em momentos diferentes, por pessoas diferentes, sem retirar das equipes a capacidade de resolver problemas.

No fim, o objetivo é bastante prático: permitir que a arquitetura continue evoluindo sem depender de improvisação, memória ou preferências individuais a cada nova mudança.