Este é mais um artigo sobre transformação da arquitetura de software. Recapitulando, esta empresa imaginária tentou tornar-se ágil, mas descobriu que sua arquitetura de software era um fator limitante. Um novo desafio surge agora no horizonte.

A execução em paralelo havia ajudado o time a ganhar confiança na migração do processamento de pedidos. Outros times começavam a experimentar a mesma abordagem, enquanto alguns clientes testavam a nova API. Porém, ao acompanhar as entregas, Clara, a gestora de portfólio responsável pela revolução, percebeu que a quantidade de mudanças no legado continuava maior do que Carlos esperava.

A orientação para implementar novas funcionalidades na nova arquitetura já estava clara. Carlos (o líder de Tecnologia) e Paulo (o líder de Produtos) também haviam combinado que analisariam juntos as exceções. Na prática, entretanto, os pedidos chegavam por canais diferentes, com informações incompletas e quase sempre depois de alguma data ter sido prometida. Em alguns casos, o desenvolvimento já havia começado quando a discussão chegava aos dois.

Um desses pedidos envolvia uma melhoria na tela usada pelos clientes para consultar seus pedidos. O gerente de produto justificava a implementação no legado pela proximidade de uma apresentação comercial. Ao conversar com Paulo, porém, ficou claro que a demonstração poderia usar um protótipo e que a funcionalidade completa só seria necessária mais adiante. A urgência existia, mas não exigia adicionar mais código à arquitetura antiga.

Outro pedido tinha uma justificativa diferente. Um defeito na integração com um cliente estava impedindo o processamento de algumas solicitações. Corrigi-lo no legado exigiria uma mudança pequena, enquanto migrar todo o fluxo levaria várias semanas. Esperar pela nova arquitetura prolongaria um problema que já afetava a operação do cliente.

Carlos concluiu que precisavam organizar melhor aquela decisão. Ele e Paulo reuniriam semanalmente os pedidos de exceção, com a participação de Jorge e das pessoas responsáveis por cada iniciativa. Para propor uma mudança no legado, o time deveria apresentar:

• a necessidade de negócio, incluindo potenciais receitas ou problemas evitados;
• as alternativas consideradas, com seus respectivos impactos técnicos e
• os prazos de desenvolvimento, tanto no legado quanto na nova arquitetura.

Essa análise deveria acontecer antes do início do desenvolvimento.

Paulo fez questão de participar das primeiras conversas. Sem alguém de negócio discutindo a necessidade e o prazo, a tendência seria transformar cada pedido em uma disputa entre quem queria entregar e quem parecia estar impedindo a entrega. Com os dois lados presentes, passaram a avaliar se o benefício imediato justificava o risco e o trabalho de migração que a empresa assumiria depois.

O grupo também definiu categorias previamente autorizadas, como correções de defeitos e de segurança dentro de critérios conhecidos. Pedidos urgentes que não se enquadrassem nessas categorias poderiam ser avaliados assim que surgissem, sem esperar pela reunião semanal. Ninguém precisaria manter um cliente com problemas apenas porque a próxima reunião ainda estava distante.

Nas semanas seguintes, Clara começou a registrar os pedidos e as decisões. Alguns foram aprovados, outros voltaram para a nova arquitetura e alguns precisaram de informações adicionais. O registro revelou que vários times solicitavam alterações no mesmo menu administrativo sempre que lançavam uma funcionalidade. Jorge, o arquiteto mais sênior, identificou que uma pequena mudança para tornar esse menu configurável eliminaria boa parte dessas solicitações.

Carlos percebeu que as exceções também mostravam onde a transformação estava encontrando dificuldades. A repetição de pedidos sobre um mesmo componente poderia justificar antecipar sua migração. A análise deixava de depender apenas da insistência de quem trazia a demanda e passava a produzir informações úteis para o roadmap.

Exceções com Critérios Claros

Estabelecer que Novas Funcionalidades Vão para a Nova Arquitetura, como discutido anteriormente, é uma decisão importante, mas ela também precisa funcionar quando surgem demandas urgentes. Enquanto o legado continuar sendo o caminho mais conhecido e, em alguns casos, mais rápido, haverá pressão para utilizá-lo. Sem critérios claros, cada time pode interpretar sua própria necessidade como uma exceção legítima.

Restringir Mudanças no Legado significa exigir que propostas de alteração na arquitetura antiga sejam aprovadas antes do início da implementação. A organização continua podendo atender necessidades que realmente não podem esperar, mas passa a decidir conscientemente quanto risco e trabalho futuro aceita incorporar ao sistema que pretende substituir.

Essa avaliação deve envolver representantes de tecnologia e de negócio com autoridade para decidir. Quem propõe a mudança precisa explicar tanto sua motivação quanto o que será alterado no sistema. Uma data já anunciada, por si só, não demonstra que a implementação no legado seja necessária. É preciso entender o que acontece se a entrega for adiada e quais alternativas existem.

A decisão considera a importância da demanda, sua urgência, o risco da alteração e a complexidade que ela acrescenta ao legado. Também deve considerar o esforço para implementar na nova arquitetura. O resultado pode ser aprovar a exceção, direcionar o trabalho para a nova solução ou solicitar mais informações. Se houver um conflito que o grupo não consiga resolver, ele deve chegar à liderança com as alternativas e suas consequências explícitas.

Um comitê de mudanças, frequentemente chamado de CAB (Change Advisory Board), pode cumprir esse papel. Esse tipo de estrutura costuma ser associado a processos burocráticos, e o risco de criar mais uma fila é real. Neste contexto, seu escopo precisa permanecer nas exceções ao uso da nova arquitetura. Transformá-lo em uma aprovação obrigatória para toda entrega retiraria a autonomia dos times, sem contribuir para o objetivo do padrão. Um exemplo simples de fluxo para a atuação do CAB é mostrado na Figura abaixo.

O processo pode começar simples e ficar mais restritivo conforme a organização aprende. Em um primeiro momento, os próprios times implementam as mudanças autorizadas. Mais adiante, um time responsável pelo legado pode revisar essas alterações ou assumir sua implementação. A escolha depende do volume de mudanças, do conhecimento necessário e dos riscos envolvidos.

Também é possível definir categorias previamente aprovadas, com limites claros. Correções de defeitos, atualizações de segurança e mudanças que viabilizam a migração podem receber esse tratamento. O enquadramento precisa ser verificável, para que uma nova funcionalidade não seja apresentada como correção apenas para evitar a análise. As demais urgências precisam de um caminho de avaliação rápida antes da implementação.

Os pedidos recusados ou repetidos merecem atenção. Eles podem indicar funcionalidades ausentes na plataforma, dependências que afetam vários times ou componentes cuja migração deveria ganhar prioridade. Às vezes, uma pequena melhoria no legado elimina uma dependência recorrente. Em outras situações, somente a migração resolve o problema.

Essa restrição tem custo: alguns compromissos precisarão ser renegociados, e as pessoas envolvidas gastarão tempo preparando e analisando solicitações. Por isso, as decisões devem ser transparentes, e a liderança precisa explicar por que o esforço adicional faz sentido para a empresa.

Restringir Mudanças no Legado protege a transformação de um problema bastante concreto: continuar criando funcionalidades que precisarão ser migradas depois. Quando a organização permite exceções sem perder de vista esse custo, os times conseguem atender às necessidades imediatas sem abandonar a direção que foi acordada.

Assine a nossa News e siga o Itshow nas redes sociais para ficar por dentro de todas as notícias do setor de TI e Cibersegurança!