O sistema legado transporta mais do que código antigo
Um sistema maduro contém frequentemente anos de práticas empresariais negociadas. Algumas regras estão explícitas no código; outras residem nos horários do processamento por lotes, nas convenções das bases de dados, em listas de verificação operacionais, nos procedimentos dos fornecedores e no julgamento de pessoas experientes. Estes elementos podem parecer acidentais de uma perspetiva tecnológica e, ainda assim, ser essenciais para a continuidade.
A modernização falha quando o sistema atual é documentado apenas como um conjunto de componentes a substituir. Uma perspetiva mais útil mapeia as capacidades que viabiliza, as decisões que suporta, os dados críticos sob a sua responsabilidade, as dependências a jusante que alimenta, os controlos que assegura e as exceções geridas pelas pessoas em seu redor. Essa perspetiva revela o que pode mudar e o que tem de permanecer ligado.
Criar um registo de continuidade antes de uma lista de substituições
Um registo de continuidade enumera os factos e comportamentos que cada transição tem de preservar: identidade estável, definições empresariais, autoridade de aprovação, compromissos temporais, regras de reconciliação, evidências de auditoria, expectativas de recuperação e limites dos serviços. Cada elemento deve ter um responsável e uma forma de ser testado. O registo não é um pretexto para reproduzir todos os comportamentos históricos; é uma base para decidir deliberadamente o que manter, alterar ou retirar.
Isto muda a fase de descoberta. Em vez de perguntarem apenas de que funcionalidades os utilizadores precisam, as equipas perguntam porque existe uma regra, que consequência terá a sua alteração e quem tem autoridade para aceitar essa consequência. Um comportamento obsoleto pode ser eliminado com confiança depois de examinados o seu propósito e as suas dependências. Um comportamento importante pode ser redesenhado, em vez de se perder por acidente.
Conceber em conjunto o alvo e as transições
Uma arquitetura-alvo mostra as responsabilidades futuras e os limites pretendidos, mas não mostra, por si só, como a organização pode operar amanhã. As arquiteturas de transição descrevem os estados intermédios que têm de suportar trabalho real enquanto os dados, as interfaces e os utilizadores são transferidos. Incluem responsabilidades temporárias, coexistência, reconciliação, controlos adicionais e critérios explícitos de desativação.
Conceber as transições em conjunto com o alvo permite testar se este é alcançável. Se não existir uma forma credível de transferir uma identidade crítica, executar regras antigas e novas em paralelo ou verificar os resultados em ambos os regimes de responsabilidade, o alvo poderá precisar de limites diferentes. A transição é uma arquitetura por direito próprio, não um andaime de projeto que possa ficar por documentar.
Dividir a migração por capacidade empresarial e evidência
As camadas técnicas raramente são a unidade de migração mais segura. Mover primeiro todos os dados, depois todos os serviços e só então todos os canais pode criar longos períodos em que ninguém é responsável por um resultado empresarial completo. Uma fatia de capacidade acompanha um percurso significativo através de regras, dados, interfaces e operações. Pode ser pequena, mas pode ser aceite como um todo.
Selecione os incrementos segundo as dependências e consequências, e não apenas pela facilidade. O trabalho inicial deve testar os pressupostos de maior risco, evitando um impacto inaceitável. Cada incremento precisa de critérios de sucesso, reconciliação e recuperação. Estar concluído significa que a organização consegue operar e explicar o novo percurso, e não apenas que o código foi implementado.
Tratar a coexistência como um modelo operacional
A operação em paralelo introduz questões que um diagrama de migração omite frequentemente. Que sistema tem autoridade sobre cada facto? Podem ambos aceitar alterações? Como se correlaciona a identidade? Quando os resultados diferem, quem decide? Com que rapidez deve ocorrer a reconciliação? Que evidências comprovam a equivalência do novo comportamento onde essa equivalência é importante?
Estas são decisões operacionais. Precisam de responsáveis, procedimentos operacionais documentados, monitorização e escalonamento. A escrita dupla ou a replicação de dados podem fazer parte do mecanismo, mas nenhuma delas estabelece a autoridade empresarial. Uma decisão clara sobre a fonte de verdade e um percurso controlado para as exceções são mais importantes do que a sofisticação da tecnologia de sincronização.
A recuperação deve abranger o estado empresarial, não apenas a implementação
Repor uma versão anterior da aplicação não anula automaticamente encomendas aceites, notificações enviadas, decisões registadas ou dados transformados enquanto a nova versão esteve ativa. O planeamento da recuperação tem de identificar efeitos irreversíveis, ações de compensação e o ponto a partir do qual deixa de ser responsável regressar ao estado anterior.
Para cada transição, defina o que pode ser novamente tentado, reproduzido, reconciliado, compensado ou restaurado. Teste o processo de decisão, além do mecanismo. Os responsáveis devem saber quem pode interromper o avanço, que evidência desencadeia essa escolha e como continuam as operações enquanto se procura compreender o problema.
Utilizar critérios de decisão, e não um roteiro baseado apenas no calendário
Um roteiro de modernização deve mostrar as evidências necessárias para avançar entre estados: cobertura conhecida das regras, reconciliação dos dados dentro de uma tolerância aprovada, recuperação testada, responsabilidade pelo suporte aceite ou remoção de uma dependência crítica.
Os registos de decisão preservam o motivo pelo qual foram escolhidos um alvo, uma sequência ou um compromisso temporário. Também indicam quando um pressuposto deve ser revisto, tornando a governação mais simples e útil: concentram a atenção na incerteza relevante, em vez de exigir que todos os detalhes passem pelo mesmo fórum.