10.4 Sustentação de sistemas grandes e de vida longa

Visão geral e motivação

A maior parte do que se escreve sobre engenharia de software trata de construir coisas novas. Mas a maior parte do software importante do mundo é velha, grande e ainda está rodando: sistemas de impostos, pagamentos de benefícios, controle de tráfego aéreo, bancos centrais, controle industrial e a infraestrutura da vida diária. Esses sistemas rotineiramente rodam por dez, vinte ou trinta anos. Isso é muito mais que a permanência de quem os construiu e muitas vezes mais que a vida das empresas e das linguagens que os produziram. Sustentar tais sistemas significa mantê-los confiáveis, seguros, compreendidos e capazes de mudar, ao longo de décadas e de gerações de equipe. É uma das disciplinas mais difíceis e menos glamourosas do campo, e uma em que grandes empresas e governos carregam o fardo mais pesado.

Por que isso importa mais para as grandes organizações? Continuidade de obrigação. Uma startup pode reescrever ou abandonar o seu software. Um governo nacional não pode parar de pagar pensões enquanto refatora. Empresas e agências são donas de sistemas cuja falha tem consequências medidas em meios de subsistência, segurança ou confiança pública. E são donas de muitos ao mesmo tempo, com equipes que entram e saem ao longo de décadas. As ameaças centrais não são exóticas. São a lenta erosão das pessoas que entendem o sistema (fator ônibus, quão poucas pessoas precisariam sair para o conhecimento de um sistema se perder), o acúmulo de conhecimento sem documentação em poucas cabeças, o apodrecimento da pilha tecnológica rumo ao fim de vida e a paralisia que se instala quando um sistema fica crítico demais para tocar e mal compreendido demais para mudar com segurança.

Este capítulo trata da curadoria (stewardship): o trabalho deliberado e sem glamour de ajudar um sistema a sobreviver com elegância aos seus autores. Cobre a continuidade da propriedade e a mitigação do fator ônibus, a descontinuação e o encerramento planejados, a transferência de conhecimento, os desafios peculiares de sistemas de décadas e o constante exercício de equilíbrio entre inovar e preservar a estabilidade de que cidadãos e clientes dependem.

Princípios fundamentais

Todo sistema crítico precisa de um dono, sempre. A propriedade é uma atribuição contínua, não a lembrança de quem o escreveu.
O conhecimento que vive numa só cabeça é um risco, não um ativo. Institucionalizem o entendimento antes de a pessoa sair.
O enfadonho é uma funcionalidade. Para sistemas críticos de vida longa, a estabilidade e a previsibilidade muitas vezes valem mais que a novidade.
Planejem o fim no começo. Todo sistema será aposentado ou substituído. Projetem e documentem para esse dia.
A mudança é como vocês ficam seguros. Um sistema assustador demais para tocar já está falhando. A capacidade de mudar é um traço de sobrevivência.
A continuidade sobrevive aos indivíduos. Projetem equipes, documentação e processos para que nenhuma saída isolada seja uma crise.
A confiança é o produto real. Para sistemas voltados ao cidadão e ao cliente, a confiabilidade e a equidade sustentadas ao longo do tempo são a missão.

Recomendações

Estabeleça a curadoria e a continuidade da propriedade

Atribuam propriedade explícita e atual para todo sistema que importa. Sejam donos no nível da equipe e não do indivíduo, para que a propriedade sobreviva a saídas. Mantenham um catálogo de serviços que registre, para cada sistema, quem é o dono, o que ele faz, do que depende e quão crítico é. Revisem a propriedade regularmente e nunca deixem um sistema ficar órfão. Um sistema crítico sem dono é uma emergência esperando para acontecer. Quando as equipes se reorganizam, transfiram a propriedade deliberadamente, com uma passagem de bastão e não por suposição. Para os sistemas críticos de vida mais longa, garantam que a propriedade inclua não só a operação mas a capacidade de entender e mudar o sistema, para que a curadoria não decaia em mera babá.

Mitigue o fator ônibus e o risco de pessoa-chave

Meçam e reduzam ativamente a concentração de conhecimento. Se só uma pessoa consegue implantar, depurar ou mudar um sistema, isso é um ponto único de falha tão real quanto qualquer hardware. Reduzam-no por meio de programação em par e rodízio, revisão de código obrigatória, sobreaviso compartilhado e uma regra deliberada de que nenhuma tarefa crítica tem exatamente uma pessoa capaz. Treinem em várias frentes para que pelo menos duas (de preferência três) pessoas possam desempenhar cada função essencial. Tratem a saída de uma pessoa-chave como um evento previsível para o qual vocês se preparam continuamente, não como um choque que absorvem. A documentação ajuda. Mas o conhecimento de trabalho espalhado por uma equipe através da prática efetiva é muito mais durável que documentos que ninguém exercitou.

Institucionalize a transferência de conhecimento

Capturem o conhecimento que de outro modo sairia com as pessoas. Concentrem-se primeiro no conhecimento que é difícil de reconstruir: por que as decisões foram tomadas, que alternativas foram rejeitadas e por quê, onde estão as arestas cortantes e as gambiarras críticas em que o resto do sistema se apoia em silêncio e como o sistema se comporta sob estresse. Usem registros de decisão de arquitetura para preservar o raciocínio por trás das escolhas e não apenas as escolhas. Mantenham runbooks e documentação operacional perto do sistema e exercitem-nos regularmente para que permaneçam verdadeiros. Construam caminhos de integração que levem os novos curadores a uma competência genuína. Tratem as saídas como eventos de transferência de conhecimento, com tempo real de passagem. Lembrem que o conhecimento tácito, o tato para um sistema, se transfere principalmente fazendo ao lado de alguém que o tem, então sobreponham curadores que saem e que chegam onde puderem.

Gerencie a descontinuação, o encerramento e o fim de vida

Planejem os finais deliberadamente. Quando vocês decidem aposentar ou substituir um sistema, tratem o encerramento como um projeto por si só: identifiquem todo consumidor e toda dependência, ofereçam um caminho de migração e um prazo realista, comuniquem com clareza e repetidamente e apoiem os consumidores durante a transição. Evitem a armadilha de rodar o sistema antigo e o novo em paralelo para sempre porque ninguém fará o trabalho difícil de desligar o antigo. Atribuam responsabilização explícita pela conclusão do desmonte. Preservem dados, registros e a capacidade de responder a perguntas sobre o sistema aposentado muito depois de ele parar de rodar, especialmente onde se aplicam regras legais de retenção. Um encerramento mal feito deixa sistemas zumbis sem manutenção mas ainda usados: o pior dos mundos.

Sustente sistemas por décadas

Para sistemas que precisam rodar por vinte ou trinta anos, planejem sobreviver a tudo: a equipe original, os fornecedores, o ecossistema da linguagem e o hardware. Prefiram padrões abertos e interfaces documentadas a caixas-pretas proprietárias, para que os futuros mantenedores tenham uma chance. Modularizem, para que as peças possam ser substituídas uma de cada vez em vez de por uma reescrita de tudo ou nada arriscada demais para ser tentada. Mantenham o sistema continuamente mantido. Um sistema mantido atual em passos pequenos permanece sustentável. Um sistema congelado “porque funciona” se torna silenciosamente impossível de manter à medida que sua pilha sai do suporte. Mantenham também as habilidades para operá-lo: para tecnologia genuinamente antiga, treinem deliberadamente sucessores em vez de esperar que o último especialista nunca se aposente.

Equilibre inovação com estabilidade e confiança

Distingam as partes do seu patrimônio em que a novidade cria valor das partes em que a estabilidade é o valor. Os sistemas centrais de que cidadãos e clientes dependem diariamente costumam recompensar a confiabilidade, a compatibilidade retroativa e a mudança cautelosa mais que reescritas empolgantes. Invistam a inovação nas bordas (novos canais, novas funcionalidades, novas interfaces) enquanto mantêm o núcleo durável estável e bem compreendido. Mudem o núcleo, sim, mas em incrementos pequenos, reversíveis e bem testados e não em saltos heroicos. O objetivo é um sistema ao mesmo tempo confiável e capaz de evoluir: nunca tão congelado que apodreça, nunca tão agitado que se torne pouco confiável.

Compromissos: prós e contras

Abordagem	Prós	Contras
Manter o sistema antigo	Preserva o conhecimento institucional. Pouca ruptura. Confiabilidade comprovada	Pilha envelhecida. Habilidades escassas. Risco crescente se sem manutenção
Reescrita de uma vez (big-bang)	Pilha nova. Descarta o cruft acumulado	Taxa de fracasso altíssima. Perde o conhecimento de casos de borda duramente conquistado
Modernização incremental	Redução contínua de risco. Continua rodando	Lenta. Exige financiamento e disciplina sustentados
Transferência baseada em documentação	Registro explícito e pesquisável	Decai se sem manutenção. Perde o conhecimento tácito
Transferência baseada em pessoas (par/rodízio)	Conhecimento de trabalho durável. Equipes resilientes	Custa produtividade atual. Exige agendamento deliberado
Congelar o núcleo crítico	Estabilidade máxima no curto prazo	A pilha envelhece até se tornar impossível de manter. Fica assustador demais para tocar

O compromisso definidor é estabilidade versus evolução, e as soluções ingênuas falham ambas. Congelem um sistema crítico para protegê-lo e vocês garantem que ele eventualmente se torne impossível de manter e inseguro. Reescrevam-no por inteiro para modernizar e vocês convidam a alta taxa de fracasso pela qual as substituições big-bang são notórias e descartam décadas de conhecimento de casos de borda codificado de que ninguém lembra. O caminho durável é a mudança contínua e incremental: manter o sistema vivo e em movimento em passos pequenos, de modo que nunca saia do suporte e nunca precise de um salto aterrorizante. A transferência de conhecimento é um compromisso parecido, entre a facilidade dos documentos e a durabilidade da experiência vivida. A resposta é ambos: o conhecimento vivido e mantido pela equipe como espinha dorsal e os documentos como referência.

Perguntas para discutir com sua equipe

Quais dos seus sistemas críticos não têm hoje uma equipe dona nomeada e atual? A propriedade é uma atribuição contínua, não a lembrança de quem escreveu o código, e um sistema crítico sem dono é uma emergência esperando para acontecer, notada só quando quebra. Percorram o seu catálogo de serviços (ou construam um) e confiram que todo sistema registra quem é o dono, do que depende e quão crítico é. Levem evidências: escolham três sistemas importantes e tentem nomear a equipe responsável e a última vez que a propriedade foi revisada. Onde um sistema está órfão, ou onde uma reorganização o largou em silêncio, atribuam a propriedade deliberadamente, com uma passagem de bastão real e não por suposição. Garantam que a propriedade inclua a capacidade de entender e mudar o sistema, para que a curadoria não decaia em mera babá.
Quando vocês substituem um sistema, quem responde por de fato desligar o antigo? A execução paralela eterna é uma falha comum e custosa: os sistemas antigo e novo rodam lado a lado indefinidamente porque ninguém é dono do desligamento, deixando vocês mantendo dois sistemas e obtendo a segurança de nenhum. Tratem todo encerramento como um projeto gerenciado, com responsabilização nomeada pela conclusão do desmonte, uma lista mapeada de consumidores, um caminho de migração e um prazo realista. Levem evidências: quantas execuções paralelas “temporárias” ou sistemas meio aposentados ainda consomem manutenção no seu patrimônio hoje? Preservem dados e registros para cumprir as regras legais de retenção muito depois de o sistema parar de rodar, mas não deixem a retenção virar desculpa para nunca terminar. Um encerramento mal feito deixa sistemas zumbis sem manutenção mas ainda usados, o pior dos mundos.
Que habilidades para os seus sistemas de vida longa o mercado de trabalho deixará de fornecer, e qual é o seu plano de sucessão? Os sistemas que rodam por vinte ou trinta anos sobrevivem aos seus ecossistemas de linguagem, aos seus fornecedores e às carreiras das pessoas que entendem a pilha antiga, e o mercado não entregará substitutos de forma confiável. Reduzam o fator ônibus deliberadamente para que nenhuma função crítica tenha exatamente uma pessoa capaz e treinem em várias frentes para que pelo menos duas, de preferência três, pessoas possam desempenhar cada tarefa essencial. Levem evidências: para cada sistema crítico envelhecido, contem quantas pessoas conseguem mudá-lo com segurança e quão perto da aposentadoria estão as mais conhecedoras. A resposta deve conduzir o treinamento deliberado de sucessores e uma sobreposição real entre curadores que saem e que chegam, porque o conhecimento tácito (o tato para um sistema) se transfere principalmente fazendo ao lado de alguém que o tem. Os documentos são a referência. O conhecimento vivido e mantido pela equipe é a espinha dorsal.
Quando vocês mudaram pela última vez o seu sistema de vida longa mais crítico, e alguém ainda se atreve? Um sistema que ninguém toca há um ano não é estável, está derivando para a armadilha do “assustador demais para tocar”, em que toda mudança é temida e por isso a pilha sai do suporte em silêncio. Para uma grande organização isso importa porque a paralisia se compõe: quanto mais longo o congelamento, mais o conhecimento se esvai e mais arriscada fica a mudança inevitável que acabará vindo. Levem evidências: para cada sistema crítico, a data da última mudança deliberada, o tamanho da menor mudança que alguém tentaria hoje e se uma correção rotineira de dependência ou de segurança poderia ser entregue esta semana sem heroísmo. A consideração contrária é real, porque a mudança também introduz risco, de modo que o objetivo não é agitação, e sim uma cadência constante de passos pequenos, reversíveis e bem testados. Em patrimônios corporativos e governamentais, em que um núcleo congelado pode ficar sob um serviço ao cidadão por uma década, tratem o “nunca mudamos” como um sinal vermelho e não como um alívio e financiem a manutenção contínua que mantém viva a opção de mudar.
Quanto do seu patrimônio roda sobre uma tecnologia em fim de vida ou perto dele, e quem acompanha esse relógio? Runtimes envelhecidos, bancos de dados sem suporte e frameworks sem manutenção são o modo de falha lento que se transforma numa crise súbita no dia em que uma correção de segurança deixa de chegar. Para uma grande equipe o perigo é que ninguém é dono do horizonte: as equipes individuais corrigem o que quebra, mas ninguém mantém uma visão de portfólio de quais pilhas perdem o suporte do fornecedor e quando. Levem evidências: um inventário das tecnologias centrais de cada sistema crítico, suas datas publicadas de fim de vida ou de fim de suporte e a diferença atual entre o que vocês rodam e o que ainda tem suporte. A tensão é entre o custo da atualização contínua e o risco do adiamento, e o adiamento costuma ganhar até perder de modo catastrófico. Em contextos corporativos e governamentais, em que os ciclos de contratação e de acreditação podem levar um ano ou mais, uma data de fim de vida que parece distante muitas vezes já está dentro do seu prazo de execução, então o trabalho de sucessão e de atualização precisa começar bem antes de o relógio acabar.
Onde no seu patrimônio a estabilidade é o valor e a novidade um passivo, e como vocês mantêm essa fronteira honesta? Nem todo sistema recompensa o mesmo tratamento: os sistemas centrais de que cidadãos e clientes dependem diariamente costumam recompensar a confiabilidade e a mudança cautelosa, enquanto as bordas recompensam a experimentação, e confundir os dois desperdiça dinheiro ou convida a interrupções. Para uma grande organização o risco é que a ambição e os incentivos de carreira empurrem reescritas empolgantes justamente para o núcleo durável que deveria permanecer enfadonho. Levem evidências: um mapa do seu patrimônio marcando onde a confiabilidade é a missão e onde a novidade cria valor, mais mudanças recentes que cruzaram essa linha em qualquer direção e o que custaram. A consideração contrária é que até um núcleo estável precisa evoluir, de modo que “estável” não pode virar desculpa para congelar. Em contextos corporativos e governamentais, liguem essa fronteira a níveis explícitos de criticidade e a uma autoridade nomeada que possa vetar uma reescrita arriscada de um sistema que o público não pode se dar ao luxo de ver falhar, para que o julgamento não derive com quem estiver mais alto neste trimestre.

Perspectiva por setor

Startup. Com um punhado de engenheiros e pouco fôlego, o seu risco de sustentação se concentra em uma ou duas pessoas que escreveram os sistemas que vocês não podem se dar ao luxo de perder, como cobrança ou autenticação. Gastem quase nada em processo, mas façam agora as coisas baratas e de alto valor: emparelhem uma segunda pessoa em cada sistema crítico, escrevam um registro de decisão de arquitetura de uma página para as partes surpreendentes e mantenham um runbook que vocês de fato usam. Resistam à vontade de reescrever algo só porque é velho, porque no seu tamanho uma reescrita fracassada de um sistema central pode acabar com a empresa.

Pequena empresa. Vocês não têm equipe dedicada de manutenção e têm orçamento apertado, então favoreçam comprar e hospedar em vez de construir qualquer coisa que vocês mesmos teriam de sustentar. Prefiram fornecedores e padrões abertos que deixem vocês sair e mantenham um registro simples de qual sistema externo roda qual função crítica e para quem ligar quando quebrar. Onde vocês são donos de código sob medida, garantam que pelo menos duas pessoas (ou um contratado de confiança mais um funcionário) o entendam, para que uma única saída ou um contrato de suporte vencido não deixe vocês encalhados.

Grande empresa. O seu desafio é a escala de portfólio: muitos sistemas de vida longa, muitas equipes e pessoal que roda ao longo de décadas. Padronizem a propriedade em nível de equipe num catálogo de serviços, meçam o fator ônibus em todo o patrimônio e financiem a modernização incremental contínua em vez de apostar em reescritas big-bang. Governem os horizontes de fim de vida centralmente para que nenhuma pilha crítica saia do suporte em silêncio e rodem todo encerramento como um projeto auditado, com responsabilização nomeada pela conclusão do desmonte.

Governo. A continuidade de obrigação é absoluta: vocês não podem parar de pagar benefícios nem de operar o controle de tráfego aéreo enquanto refatoram, e as falhas são públicas e consequentes. As regras de contratação empurram para os padrões abertos, a portabilidade de dados e as interfaces documentadas, para que futuros mantenedores e futuros fornecedores tenham uma chance. Financiem o treinamento deliberado de sucessão para as tecnologias mais antigas que o mercado de trabalho já não fornece, preservem os registros dos sistemas aposentados para cumprir a retenção legal e tratem a confiabilidade sustentada dos serviços ao cidadão como a missão pela qual se responde e não como sobrecarga.

Exemplos

Startup. Uma startup de cinco pessoas já tem um sistema que não pode se dar ao luxo de perder: o serviço de cobrança que um fundador escreveu no primeiro mês e que agora roda toda cobrança de cliente. Só esse fundador o entende, então a equipe trata o fator ônibus como um risco real e não como um elogio. Emparelham um segundo engenheiro por um ciclo completo de cobrança, escrevem um breve registro de decisão de arquitetura explicando por que a estranha lógica de novas tentativas existe e mantêm um runbook ao lado do código que de fato exercitam durante um incidente. Resistem a reescrevê-lo só porque é velho e sem glamour e em vez disso o melhoram em passos pequenos e reversíveis, de modo que o serviço que mantém a empresa viva seja entendido por mais de uma cabeça.

Grande empresa. Uma grande seguradora roda um sistema de administração de apólices escrito há décadas e ainda central para o seu negócio. Em vez de tentar uma reescrita arriscada de tudo, modularizou o sistema por trás de interfaces bem definidas e agora substitui um componente de cada vez, cada mudança pequena e reversível. Toda função crítica tem pelo menos três pessoas que podem desempenhá-la. O sobreaviso é compartilhado. Registros de decisão de arquitetura capturam por que o sistema funciona do jeito que funciona. Um curso interno curado leva os novos engenheiros à competência na pilha legada, e os especialistas que saem se sobrepõem aos sucessores para que o conhecimento tácito se transfira fazendo.

Governo. Uma agência nacional de previdência social opera sistemas de pagamento de benefícios que rodam há mais de trinta anos e não podem parar. Registra a propriedade explícita de equipe num catálogo de serviços. Financia a manutenção contínua em vez de congelar os sistemas. Treina deliberadamente sucessores nas tecnologias mais antigas, porque o mercado de trabalho não os fornecerá. Quando aposenta um subsistema obsoleto, roda o encerramento como um projeto gerenciado: mapeando todo consumidor, oferecendo apoio à migração, preservando registros para cumprir as regras legais de retenção e atribuindo responsabilização pela conclusão efetiva do desmonte, de modo que nenhum sistema zumbi permaneça.

Justificativa de negócio: motivações, ROI e TCO

O retorno de sustentar sistemas de vida longa vem de evitar os dois modos catastróficos de falha que dominam o seu custo total de propriedade. O primeiro é a crise súbita: uma pessoa-chave sai, um componente sem suporte é violado ou um sistema órfão falha sem ninguém que o entenda. O segundo é o megaprojeto fracassado: uma reescrita apressada de tudo que estoura, entrega menos ou colapsa. Ambos são enormemente caros e ambos são em grande parte evitáveis por uma curadoria constante. O custo de uma única falha de reescrita evitada, ou de uma única interrupção prolongada evitada de um serviço crítico ao cidadão, costuma superar anos de investimento sustentado em manutenção.

O custo de adoção é contínuo e sem glamour: financiar manutenção que não produz funcionalidades novas, pagar por tempo de treinamento em várias frentes e de documentação que reduz a produção de curto prazo e investir em modernização incremental que nunca vira manchete. O custo de não adotar é adiado e maior: risco crescente conforme a pilha envelhece, exposição inflada de pessoa-chave e, por fim, uma substituição forçada, de alto risco e alto custo, em condições de emergência. Ao defender o caso junto à liderança, reenquadrem a manutenção de “centro de custo” para “gestão de risco para sistemas que a organização não pode se dar ao luxo de perder”. Apresentem o custo total de propriedade ao longo de toda a vida de várias décadas (incluindo a sustentação e o eventual desmonte) e não apenas da construção. E enfatizem isto: para sistemas voltados ao cidadão e ao cliente, a confiabilidade sustentada não é sobrecarga. É a confiança que é o produto de fato.

Antipadrões e armadilhas

O mantenedor herói. Uma pessoa insubstituível que entende o sistema. A saída dela é um evento existencial.
Congelar e esquecer. Declarar um sistema crítico “pronto”, parar a manutenção e ver a pilha envelhecer até se tornar impossível de manter.
A reescrita condenada. Apostar a organização numa substituição de tudo que descarta conhecimento codificado e costuma estourar ou fracassar.
Sistemas órfãos. Software crítico sem dono atual, notado só quando quebra.
Teatro de documentação. Volumes de documentos desatualizados, não exercitados e em que ninguém confia.
A execução paralela eterna. Sistemas antigo e novo rodando lado a lado indefinidamente porque ninguém responde pelo desligamento.
Perda de conhecimento tácito. Deixar os especialistas saírem sem sobreposição, de modo que o tato para o sistema se evapora.
Assustador demais para tocar. Um sistema tão mal compreendido que qualquer mudança é temida, o que garante que ele decai.

Modelo de maturidade

Nível 1: Iniciar. A sustentação é ad hoc e reativa. Os sistemas dependem de heróis individuais, a propriedade é lembrada em vez de atribuída e o conhecimento vive sem documentação em poucas cabeças. Os sistemas antigos são congelados até quebrar, as pilhas envelhecidas derivam para o fim de vida sem ser notadas e as aposentadorias são anunciadas mas nunca concluídas.

Nível 2: Desenvolver. Aparecem práticas básicas, mas variam de equipe para equipe. A propriedade é escrita para os grandes sistemas mais óbvios, existem alguns runbooks e alguma documentação, e algumas funções críticas têm uma segunda pessoa capaz. A manutenção é financiada mas reativa, o treinamento em várias frentes acontece quando alguém lembra e não há um modo compartilhado de fazer nada disso na organização.

Nível 3: Padronizar. As práticas de curadoria são documentadas e impostas em toda a organização. A propriedade em nível de equipe é registrada num catálogo de serviços e sobrevive a reorganizações. A mitigação do fator ônibus por rodízio e treinamento em várias frentes é regra permanente, registros de decisão de arquitetura e runbooks exercitados são esperados, a modernização é incremental por política e todo encerramento roda como um projeto gerenciado, com responsabilização nomeada pela conclusão do desmonte.

Nível 4: Gerenciar. A sustentação é medida e controlada com dados em relação a linhas de base. Vocês acompanham o fator ônibus por sistema crítico, a contagem de pessoas que conseguem mudar cada um com segurança, a idade de toda tecnologia central contra sua data de fim de vida, a fração do patrimônio sob manutenção contínua versus adiada e o número de execuções paralelas empacadas e desmontes meio terminados. Essas métricas carregam limiares que disparam ação: um sistema que cai abaixo do piso de fator ônibus ou cruza um horizonte de fim de suporte recebe remediação financiada, e a saúde da curadoria é reportada à liderança ao lado da entrega.

Nível 5: Orquestrar. A curadoria é continuamente melhorada e integrada em toda a organização. Nenhum sistema crítico é um ponto único de falha humana, a transferência de conhecimento, inclusive do tácito por sobreposição, é rotineira e os sistemas evoluem em passos pequenos e reversíveis para que nenhum saia do suporte. A propriedade, o acompanhamento de fim de vida, a sucessão e o planejamento de encerramento são tecidos no planejamento de portfólio e de risco, o patrimônio é reequilibrado conforme as tecnologias e as obrigações mudam e os sistemas de várias décadas são sustentados preservando a confiança das pessoas que dependem deles.

Ideias para discussão

Como vocês medem o fator ônibus de modo significativo, e que meta é a certa para diferentes níveis de criticidade?
Quando uma modernização incremental é genuinamente inviável, fazendo da reescrita o menor risco?
Como vocês financiam e recompensam o trabalho de manutenção para que a curadoria seja uma carreira respeitada e não um beco sem saída?
Qual é o jeito certo de preservar o conhecimento tácito quando o último especialista está para se aposentar e nenhuma sobreposição é possível?
Por quanto tempo vocês devem reter a capacidade de responder a perguntas sobre um sistema aposentado, e quem paga por isso?
Onde no seu patrimônio a estabilidade é o valor e a novidade um passivo, e como vocês mantêm esse julgamento honesto ao longo do tempo?

Principais conclusões

A maior parte do software importante é velha e de vida longa. Sustentá-la por décadas e gerações de equipe é uma disciplina de primeira classe.
Todo sistema crítico precisa de propriedade atual, em nível de equipe. Sistemas críticos órfãos são emergências latentes.
Reduzam o fator ônibus deliberadamente (nenhuma tarefa crítica deve ter exatamente uma pessoa capaz) e transfiram o conhecimento tácito por sobreposição e não só por documentos.
Mantenham os sistemas de vida longa mantidos de modo contínuo e incremental. Congelá-los e apostar em reescritas de tudo são ambos modos de falha.
Planejem os finais como projetos gerenciados com conclusão responsável, preservando dados e registros para cumprir obrigações.
Para sistemas voltados ao cidadão e ao cliente, a confiabilidade e a equidade sustentadas são a missão, e a manutenção é gestão de risco para o que vocês não podem se dar ao luxo de perder.

Referências e leitura complementar

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring and writings on the Strangler Fig pattern
Betsy Beyer et al., Site Reliability Engineering and The Site Reliability Workbook (Google)
Diomidis Spinellis, Code Reading: The Open Source Perspective
U.S. Government Accountability Office, reports on federal legacy IT modernisation