A dura verdade sobre o gerenciamento do ciclo de vida

A TI erra muito no gerenciamento do ciclo de vida.

Procure uma definição de gerenciamento do ciclo de vida e você encontrará algo como: Uma abordagem estratégica para gerenciar o ciclo de vida de um aplicativo ou plataforma desde a concepção até o fim da vida útil — desde o provisionamento, passando pelas operações, até a desativação.

Sob essa definição, o gerenciamento do ciclo de vida não parece fazer nada.

Isso não ajuda a implementar uma nova plataforma ou aplicativo — é para isso que servem suas metodologias de desenvolvimento de aplicativos e gerenciamento de mudanças. Não ajuda nas operações do dia-a-dia — é para isso que serve o ITSM. Isso não ajuda a aposentar um aplicativo ou plataforma, a não ser identificar um evento ou condição que torne a aposentadoria necessária. O evento pode ser externo, como a falência de um fornecedor ou a eliminação progressiva do produto, ou interno, como ninguém mais usa o aplicativo. Mas aposentar o aplicativo ou plataforma? É para isso que servem o arquivamento, o descomissionamento e, mais uma vez, o gerenciamento de mudanças.

A vista daqui? Gerenciar o ciclo de vida de um aplicativo ou plataforma desde a concepção até o fim da vida útil não é algo em que a TI precisa investir tempo e energia.

Gerenciamento de moeda de versão: o gerenciamento do ciclo de vida que a TI precisa

Há, no entanto, uma prática de gerenciamento do ciclo de vida que é essencial – frequentemente ignorada, mas essencial. O gerenciamento do ciclo de vida de que a TI precisa é um conjunto de métodos táticos e confiáveis ​​para manter as plataformas e os aplicativos comerciais atualizados, ou seja, não mais do que uma ou duas versões atrás do que o fornecedor está vendendo atualmente.

Chame isso de “gerenciamento de moeda de versão”.

Para contrastar com o gerenciamento de ciclo de vida usual, imagine para fins de argumento que alguns de seus aplicativos são executados em cima do EnGarde Secure Linux.

EnGarde está muito além do fim da vida útil. Para pegar emprestado dos Munchkins, ele não está meramente morto; ele está realmente, mais sinceramente, morto. Seus servidores podem não ter ouvido as notícias, mas só porque eles continuam funcionando não significa que você está em uma situação satisfatória.

O fato de o EnGarde ser executado em um servidor em fim de vida útil não significa que ele será instalado no novo hardware que você não tem escolha em comprar quando seu servidor em fim de vida se tornar um servidor expirado. Isso não significa que funcionará com uma atualização para uma das plataformas que rodam nela, ou com uma atualização para um aplicativo que depende dela.

O EnGarde, assim como qualquer outra tecnologia obsoleta e sem suporte, continuará funcionando até que não funcione. E quando isso não acontece, a TI tem uma crise em suas mãos.

Eliminar o EnGarde do seu portfólio de plataformas não é gerenciamento de ciclo de vida, porque em nenhum momento do processo houve um ciclo de vida para gerenciar. Quando a EnGarde lançou sua distribuição Linux, ela não havia definido uma data de aposentadoria em seus planos de negócios e produtos. Nem a TI quando a selecionou. Quando a TI incorporou o EnGarde em seu portfólio de plataformas, sua disposição teria sido Reter ou Estender.

Não, do ponto de vista dos arquitetos de TI, a descontinuação da EnGarde foi um evento – um evento infeliz que mudou a pontuação de viabilidade do fornecedor e do produto da EnGarde de qualquer que fosse a última vez que os arquitetos de TI a visitaram para -2 (a pior pontuação possível) e sua disposição para Substituir, se sua funcionalidade ainda for necessária, ou Desativar se nenhum aplicativo ou plataforma for mais executado nele.

Compare isso com uma empresa que confiou no BizTalk 2016 como sua plataforma de integração de aplicativos. Bem antes da aposentadoria do BizTalk 2016, a Microsoft anunciou que seu sucessor, o BizTalk 2020, seria lançado em meados de 2019, e a data de fim de vida do BizTalk 2016 (na verdade, o mês) seria novembro de 2022.

Após esses anúncios, com uma prática de gerenciamento de moeda de versão adequada, os arquitetos de TI teriam mudado a disposição do BizTalk 2016 para atualização e, com isso, adicionado um projeto de atualização do BizTalk ao cronograma e orçamento mestre do projeto da empresa, programado para evitar despesas e riscos de continuar a usar tecnologia sem suporte no portfólio de plataformas.

O gerenciamento de moeda de versão é o gerenciamento do ciclo de vida que a TI precisa. Isso inclui:

– Portfólios de aplicativos e tecnologia que rastreiam a versão em uso para seus componentes, embora sem o gerenciamento efetivo da moeda da versão, “versão em uso” seria “versões em uso”.
– Para cada componente, a atualização da versão anunciada pelo fornecedor e os cronogramas sem suporte.
– Cronogramas e orçamentos de projetos derivados de algoritmos para atualização de componentes para as versões atuais.
– Revisão de alternativas, para garantir que a atualização seja a disposição ideal, em vez de substituir o componente por uma alternativa funcionalmente equivalente, mas superior em geral.
– Princípios e políticas de arquitetura técnica para manter os componentes atualizados, revisados ​​e aprovados na equipe de liderança executiva ou no nível do conselho, para que a TI tenha que travar essa batalha orçamentária apenas uma vez.

Pegadinhas

O gerenciamento de moeda de versão não é particularmente complicado no conceito. Mas há alguns obstáculos para se preparar.

Em primeiro lugar, quando você atualiza uma plataforma, você precisa saber onde os efeitos de ondulação atingirão. É raro que uma atualização seja perfeitamente compatível com a versão anterior.

O que também significa garantir que sua equipe de garantia de qualidade de software esteja mantendo seus testes de regressão automatizados atualizados.

Em segundo lugar, atualizar um aplicativo para sua versão atual às vezes pode exigir a atualização de algumas das plataformas nas quais ele depende. O que significa voltar às pegadinhas de atualização da plataforma.

E terceiro, especialmente para gerenciamento de moeda de versão de camada de aplicativo, o dimensionamento levanta sua cabeça feia.

Ter centenas — e, em alguns portfólios, milhares — de aplicativos em produção e manter o banco de dados dos cronogramas de atualização de versão do fornecedor atualizado no sistema de gerenciamento de arquitetura técnica é um desafio. Diante da magnitude desse desafio, muitos departamentos de TI desistem e chutam pedra pelo caminho até que a obsolescência da versão de um componente resulte em uma crise. Esta é uma decisão terrível, porque quando você chuta pedra na estrada várias vezes você acaba ficando sem estrada.

Não, o gerenciamento de moeda da versão da camada de aplicativo é tão essencial quanto trabalhoso. O que funciona melhor – talvez “menos pior” seja mais preciso – é dividir e conquistar, garantindo que cada aplicativo do portfólio tenha um administrador de produto de TI designado, responsável pela saúde, cuidado e alimentação dos aplicativos atribuídos a eles. Isso inclui manter um banco de dados de planos de versão de fornecedores atualizados.

Entenda, o gerenciamento de moeda de versão não cobrirá seus praticantes em glória. Principalmente, eles serão tratados como todos os portadores de más notícias são tratados.

A boa notícia sobre as más notícias é que levar essas más notícias é melhor do que as más notícias que você levaria se não o fizesse.