Este é mais um artigo da série que aborda como conduzir uma transformação na arquitetura de sistemas de software. Seguimos os acontecimentos em uma empresa imaginária de serviços financeiros que tentou se tornar ágil, mas descobriu que sua arquitetura de software era um fator limitante. Eles agora alcançam uma nova etapa em sua jornada.

Uma Notícia Animadora

Após alertar a diretoria de que os custos de manter o sistema legado cresceriam acima do previsto, Carlos finalmente recebeu uma boa notícia: parte do orçamento solicitado para iniciar a transformação da arquitetura havia sido aprovada. Animado com a conquista, ele percebeu que precisava comunicar não apenas a decisão, mas também mostrar para onde os times iriam caminhar.

Alguns desenvolvedores mais experientes já haviam participado de experimentos e sugerido ideias, mas faltava uma visão consolidada e única da nova arquitetura. Carlos então chamou Jorge, o arquiteto, e Ana, sua desenvolvedora mais sênior, para organizarem um documento que reunisse decisões de alto nível e indicasse qual direção seguir.

Esse material combinava gráficos e texto, descrevendo como a nova arquitetura atacaria os principais problemas do legado: maior uso de comunicação assíncrona, modularidade, bancos de dados independentes por componente e a adoção de uma nova linguagem de programação. Ficou definido também que não seguiriam cegamente a onda dos microserviços, mas alinhariam os módulos aos domínios centrais da empresa, como logística, pagamentos e estoque.

Na reunião de apresentação, Carlos destacou não só as mudanças técnicas, mas também como as escolhas refletiam contribuições dos próprios times. Muitos desenvolvedores se sentiram valorizados e motivados ao ver suas ideias incorporadas na visão, saindo dali energizados para iniciar a migração rumo à nova arquitetura.

Um Desenho do Futuro

Quando uma empresa decide transformar sua arquitetura, os times e toda a organização precisam saber para onde estão indo. Para isso, Carlos procurou criar uma representação da nova arquitetura mostrando como ela endereçaria os principais problemas do sistema atual. Ele também buscou tornar essa visão clara e inspiradora, para que as equipes soubessem o que esperar e se sentissem motivadas a usá-la.

Essa visão deve ser compacta e de alto nível. Normalmente combina um ou dois diagramas simples com uma descrição em linguagem natural, ou com uma metáfora que ajude a contar a história do “antes e depois”. O documento precisa ser acessível a todos, vivo e colaborativo, algo que as equipes possam consultar, comentar e melhorar com o tempo.

Construa a visão iterativamente e incrementalmente. Evite o risco de “superprojetar” e ficar paralisado na largada, mas também não apresse um rascunho só para parecer ágil. Use o que a organização já aprendeu com o legado, dê passos pequenos e constantes, e avance enquanto pesquisa, experimenta e testa ideias. À medida que amadurece, a visão se torna estável o suficiente para orientar decisões, sem deixar de evoluir.

Convide times para experimentar versões iniciais dessa visão e trazer feedback. Adie escolhas irreversíveis o quanto puder e projete o alvo para ser fácil de mudar, alinhado à noção de arquitetura evolutiva: mudanças guiadas, incrementais, em múltiplas dimensões. Assim você reduz a chance de precisar de outra “revolução” adiante.

A participação ampla aumenta o engajamento, mas há limites práticos. Em organizações grandes, a maioria dos squads validará ideias e alguns poucos, especialmente os que mais sofrem com o legado, mergulharão mais fundo na exploração. Atenção às ancoragens do passado: quem conviveu por anos com o legado pode considerar “aceitáveis” características que você quer evitar. Se preciso, parta de uma referência de arquitetura para escapar do viés do sistema atual.

Com o negócio, seja explícito: você precisa do tempo das equipes para construir a visão. E, ao mesmo tempo, garanta que compromissos com as áreas sejam preservados. O objetivo é evitar que a visão seja percebida como um decreto top-down; ela precisa nascer de uma construção conjunta.

Defina diretrizes claras sem engessar. Uma forma prática é manter um Tech Radar interno, listando tecnologias e práticas plenamente suportadas, parte do “núcleo” da visão (o que “Adotar”). Outras tecnologias entram no grupo “Experimentar”: itens com uso controlado e compromisso de compartilhar aprendizados. Por fim, um grupo “Evitar” destaca o que não deve entrar em novas iniciativas (mesmo que exista no legado). O radar evolui com a visão, mas não deve oscilar demais.

Registre as decisões que moldam a visão. Use ADRs (Architecture Decision Records) versionados junto ao código: título, status, contexto, decisão e consequências. ADRs preservam o porquê das escolhas, facilitam revisões futuras e abrem espaço para melhorias de forma transparente.

Enquadre a visão olhando todo o ciclo de vida: descoberta e especificação (ferramentas e handoffs), experiência do desenvolvedor (DevX: ambientes, testes, versionamento), implantação (automação, rastreabilidade), e operação (observabilidade, segurança, suporte, continuidade/DR). Uma boa visão evita que dores voltem a aparecer por falta de atenção a essas camadas.

Na prática, quando Carlos publicou a Visão da Arquitetura, as conversas deixaram de girar apenas em torno de problemas atuais. Os times passaram a enxergar um rumo concreto: princípios orientadores, limites de contexto, integrações, regras como “não criar novas funcionalidades no legado” e uma trilha de transição por domínios. A visão virou guia de decisão, material de onboarding e referência de priorização.

Benefícios vêm rápido, como alinhamento, motivação e melhor chance de sucesso, mas há armadilhas: demorar demais para ter um “mínimo utilizável”, tentar agradar a todos, ou mudar tão frequentemente que a visão perca credibilidade. Trate-a como artefato vivo: simples, útil e evolutivo. É assim que a organização entende o que mudar, por que mudar e como começar amanhã.

Siga o Itshow no LinkedIn e assine a nossa News para ficar por dentro de todas as notícias do setor de TI e Cibersegurança!