Arquitetura corporativa deve governar a complexidade antes que ela se acumule

A função mais importante da arquitetura corporativa moderna não é aprovar desenhos, mas impedir que a complexidade sociotécnica se acumule mais rápido do que a organização consegue aprender. Na apresentação de Simon Rohrer sobre arquitetura em empresas modernas, esse ponto aparece com clareza: em organizações grandes, digitais e cheias de sistemas antigos, novos, internos, distribuídos e de fornecedores, a arquitetura não está separada da estrutura de times. Uma condiciona a outra. A lei de Conway, nesse contexto, deixa de ser uma observação abstrata e vira um problema prático de gestão.

O exemplo simples do “hello world” mostra o mecanismo. Uma funcionalidade aparentemente trivial pode atravessar um time de interface, outro de API, outro de serviço, outro de banco de dados e ainda depender de coordenação externa. Cada equipe pode estar ocupada e até tecnicamente correta, mas o fluxo total fica lento, caro e frágil. Rohrer usa esse caso para defender que empoderar times, isoladamente, não basta quando o desenho organizacional força dependências demais. Às vezes é preciso refatorar ao mesmo tempo a arquitetura e a organização, aproximando um time da capacidade de entregar valor de ponta a ponta.

Daí a crítica aos antigos comitês de revisão arquitetural. Eles funcionavam melhor em ciclos longos, com fases separadas de análise, desenho, construção e teste. Quando decisões relevantes acontecem continuamente, no produto em funcionamento, o comitê vira uma peça fora de lugar. A alternativa proposta é uma governança contínua, conversacional e parcialmente automatizada: aprovar novos serviços, discutir integrações, tratar exceções, usar políticas como código e observar o sistema real com ferramentas de produção. A decisão arquitetural deixa de ser um carimbo sobre um diagrama e passa a ser uma intervenção frequente sobre o que aumenta ou reduz acoplamento.

Há uma ressalva importante: isso não elimina política nem conflito. Rohrer reconhece que mudar fronteiras de times ameaça estruturas de poder, papéis estabelecidos e incentivos locais. Também admite que nem tudo pode ser resolvido por evolução incremental; sistemas muito acoplados podem exigir mudanças maiores, com caso de negócio próprio. A consequência é concreta: uma arquitetura corporativa útil precisa medir sinais como quantos times são necessários para entregar uma funcionalidade típica e quantas dependências síncronas atravessam o sistema. Sem esse tipo de atenção contínua, a empresa pode até acelerar equipes individuais, mas continuará lenta onde o trabalho realmente cruza fronteiras.

Assistir ao episódio original

Referências encontradas

Livros

• Sooner Safer Happier: Antipatterns And Patterns For Business Agility (English Edition), de Jonathan Smart — Ver livro na Amazon
• Building Evolutionary Architectures: Support Constant Change, de Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage — Ver livro na Amazon
• Wild West To Agile: Adventures In Software Development Evolution And Revolution (English Edition), de Jim Highsmith — Ver livro na Amazon
• Programacao Extrema (Xp) Explicada, de Kent Beck — Ver livro na Amazon

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.