Modelo TIME (Tolerar, Investir, Migrar, Eliminar) para Portfólios de Aplicativos

A reunião de racionalização de aplicativos começa às 9h. Às 11h, a equipe já classificou doze dos quatrocentos aplicativos em escopo. Três dessas doze classificações já foram contestadas, revisadas e contestadas novamente. O programa em lote COBOL que processa a folha de pagamento claramente não deve ser eliminado, mas será que deve ser tolerado ou investido? O sistema de faturamento legado, que todos concordam ser tecnicamente inadequado, claramente deve ser migrado, mas para qual sistema, e o que acontecerá com os dezessete programas que dependem dele? A reunião está agendada para terminar ao meio-dia. Ao meio-dia, alguém sugere continuar na semana seguinte. No mês seguinte, a iniciativa silenciosamente parou de produzir resultados.

O modelo TIME da Gartner é a estrutura de gerenciamento de portfólio de aplicativos mais utilizada em TI corporativa. Ele classifica cada aplicativo do portfólio em uma das quatro disposições: Tolerar, Investir, Migrar e Eliminar, usando duas dimensões de pontuação: valor de negócio e adequação técnica. A estrutura é logicamente sólida, amplamente aplicável e citada pelo Guia de Racionalização de Aplicativos do Conselho de CIOs do governo federal dos EUA como uma metodologia recomendada. No entanto, ela também falha na prática com mais frequência do que obtém sucesso, por um motivo que seus defensores mencionam, mas raramente desenvolvem: as classificações são tão boas quanto as evidências que as sustentam. Sem evidências estruturais, contagens reais de dependências, medições reais de complexidade e dados reais de valor de negócio derivados de rastreamentos de execução em vez de entrevistas com os responsáveis, as classificações TIME se tornam política organizacional. Discussões sobre a alocação de aplicativos começam nas categorias Migrar e Eliminar, onde o aplicativo favorito de alguém está em jogo, e nunca são resolvidas.

O Modelo: Dois Eixos, Quatro Disposições

O modelo TIME representa cada aplicação em uma matriz 2x2. O eixo horizontal representa a adequação técnica, ou seja, o quão bem a implementação técnica atual da aplicação suporta sua função pretendida: qualidade da arquitetura, facilidade de manutenção, capacidade de integração, nível de segurança e confiabilidade operacional. O eixo vertical representa o valor comercial, ou seja, a importância da função da aplicação para as operações comerciais da organização, geração de receita, conformidade regulatória ou objetivos estratégicos.

	Ajuste de alta tecnologia	Ajuste técnico básico
Alto valor comercial	INVESTIRFinancie-o. A aplicação é estrategicamente importante e tecnicamente sólida. Invista para manter a sua liderança.	MIGRARO negócio precisa disso, a tecnologia é que está errada. Troque a plataforma, não a função.
Baixo valor comercial	TOLERARDeixe como está por enquanto. O aplicativo está funcionando bem, mas não justifica investimentos adicionais.	ELIMINARDescarte-o. Baixo valor, baixa qualidade, não há motivo para mantê-lo.

A simplicidade é intencional. O TIME não foi projetado para gerar planejamento de investimentos detalhado, mas sim para produzir decisões direcionais inequívocas para cada aplicação no portfólio. Uma aplicação que não pode ser claramente classificada é uma aplicação que requer mais informações antes que a classificação seja possível.

Os Modelos Operacionais dos Quatro Quadrantes

Cada disposição TIME não é apenas um rótulo, é um modelo operacional que determina como a organização gerenciará o aplicativo daqui para frente.

Investir: Extração Máxima de Valor

Os aplicativos Invest são as joias da coroa do portfólio: alto valor comercial e excelente adequação técnica. Eles justificam o investimento mais agressivo em novos recursos, otimização de desempenho, expansão de integrações e atualização técnica constante. Um aplicativo Invest que fica para trás em termos de atualização técnica, com um ambiente de execução desatualizado, uma postura de segurança desatualizada ou um acúmulo de dependências, corre o risco de migrar para o ambiente de desenvolvimento antes mesmo que o problema seja percebido.

Compromissos operacionais para a Invest:

• Capacidade de engenharia dedicada ao desenvolvimento de funcionalidades e à manutenção técnica.
• Atualizações de segurança e conformidade de primeira prioridade
• Cobertura do conselho de revisão de arquitetura para cada alteração significativa.
• Monitoramento proativo com metas de SLA no nível 1.

Migrar: Substituir a plataforma, preservar a funcionalidade

Os aplicativos migrados desempenham uma função de negócios que a organização realmente precisa, mas em uma plataforma técnica que já não é adequada, é muito cara para manter, muito frágil para expandir e muito isolada do cenário de integração moderno. O valor para o negócio justifica o investimento na migração; o estado técnico atual torna o investimento contínuo na plataforma existente um retorno ruim.

A disposição "Migrar" responde a uma pergunta específica: vale a pena preservar a função? Se sim, migre. Para qual plataforma migrar e como fazê-lo é uma decisão separada que a classificação TIME não toma; ela apenas estabelece que a plataforma atual não é a solução.

O cenário de migração mais comum em ambientes legados: um programa em lote COBOL que implementa lógica de negócios crítica, cálculos regulatórios complexos, regras de precificação proprietárias e lógica tributária específica de cada jurisdição, em uma plataforma que torna a extensão, os testes e a integração dispendiosos. A lógica é insubstituível; o problema é a plataforma. Migre para uma plataforma moderna que preserve a lógica e, ao mesmo tempo, ofereça as características operacionais que o negócio exige atualmente.

Tolerar: Inação Deliberada com Data de Validade

O quadrante "Tolerar" é o mais incompreendido. Não significa "este aplicativo está bom". Significa "a qualidade técnica deste aplicativo não justifica o investimento para alterá-lo agora, e seu valor comercial não justifica sua eliminação". É uma escolha deliberada de aceitar o status quo por um período definido, não um adiamento indefinido.

A classificação "Tolerar" refere-se a uma suspensão temporária, não a um estado permanente. Cada aplicação no quadrante "Tolerar" deve ter uma data de revisão explícita, normalmente de 12 a 18 meses, e condições definidas que acionariam uma reclassificação antecipada: uma vulnerabilidade de segurança que não pode ser corrigida, a descontinuação de uma dependência que força uma mudança de plataforma, um aumento no valor comercial que torna o investimento na aplicação viável ou uma mudança na função comercial que elimina sua finalidade.

Organizações que tratam o status Tolerar como permanente acumulam exatamente a dívida técnica que o modelo TIME foi projetado para evitar. Um programa COBOL classificado como Tolerar em 2019 e que ainda se encontra no quadrante Tolerar em 2026 recebeu sete anos adicionais de atenção de manutenção adiada, que eventualmente precisará receber, seja emergencialmente quando algo quebrar ou devido a uma migração forçada quando a plataforma não puder mais ser suportada.

Eliminar: A decisão que todos tomam e ninguém executa.

Eliminar é a classificação mais direta e a menos executada. O aplicativo tem baixo valor comercial e baixa adequação técnica; não há justificativa para mantê-lo. Desative-o.

A falha na execução está bem documentada: a opção "Eliminar" é adotada com entusiasmo, mas quase nunca implementada. Uma revisão de portfólio realizada em 2024 em uma grande instituição financeira identificou 87 candidatos à eliminação. Dezoito meses depois, 71 deles ainda estavam em operação. A lacuna entre a classificação e a desativação é onde os programas de racionalização perdem força.

Três obstáculos específicos impedem a execução do Eliminate:

Dependências ocultas. O aplicativo foi classificado como Eliminar com base em seu aparente funcionamento independente. Após a classificação, a análise estrutural revela que doze outros programas geram resultados que o candidato a Eliminar processa, ou que três sistemas externos enviam dados para ele por meio de uma interface de arquivo não documentada. O aplicativo não é independente; ele é a infraestrutura oculta para outros sistemas. A classificação precisa ser revista.

Obstáculos à migração de dados. O aplicativo contém dados que não podem ser destruídos, registros regulatórios com períodos de retenção obrigatórios, dados de clientes que devem ser transferidos para um sistema sucessor e registros históricos de transações que os processos de auditoria consultam anualmente. A migração de dados deve preceder a desativação e é um processo dispendioso.

Obrigações regulatórias. Algumas aplicações não podem ser desativadas mesmo quando seu valor comercial é zero, porque as estruturas regulatórias exigem a funcionalidade que elas oferecem. Uma aplicação de geração de relatórios trimestrais para fins regulatórios possui valor regulatório que não consta em nenhuma avaliação de valor comercial. Até que a obrigação regulatória seja transferida para outro sistema, a aplicação deve permanecer em execução.

O Problema das Evidências: Por que o TIME Falha sem Dados Estruturais

O modo de falha mais significativo nas implementações do TIME é exatamente o que a documentação da Catio identifica: as discussões sobre a classificação começam nas opções Migrar e Eliminar, onde a preferência de alguém por um aplicativo específico está em jogo. Sem evidências objetivas, toda classificação se torna uma negociação. O responsável pelo aplicativo defende Investir. A equipe de TI defende Migrar. A equipe financeira defende Eliminar. A reunião termina com a classificação Tolerar, por ser a posição menos controversa.

A evidência estrutural resolve essas negociações substituindo a opinião pela mensuração.

Para a avaliação da adequação técnica, as evidências que importam são:

Indicador de ajuste técnico	fonte	Move a classificação em direção a
Complexidade ciclomática por programa (média)	Análise de código estático	Baixo = melhor ajuste, Alto = pior ajuste
porcentagem de código morto	Análise de acessibilidade	Código morto alto = ajuste inferior
Fan-in (contagem de dependências de entrada)	Mapeamento de dependências	Alto fluxo de ar aumenta a tolerância em relação à eliminação.
Ampla abrangência de compartilhamento de modelos	Análise de dependência COPY	Compartilhamento elevado = maior acoplamento = menor ajuste
Tempo decorrido desde a última mudança significativa	Registro de gerenciamento de alterações do Git	Um longo período de inatividade pode indicar código morto ou estabilidade.
contagem de vulnerabilidades de segurança	Análise SAST	Contagem alta = ajuste inferior

Para a avaliação do valor de um negócio, as evidências que importam são:

Indicador de Valor Empresarial	fonte	Move a classificação em direção a
Volume de transações por período	Registros de execução JCL, registros do agendador	Alto volume = maior valor
leque a jusante	Mapeamento de dependências	Alto fan-out = maior valor (muitos dependem disso)
Sinalizador de função regulatória	Classificação de dados, registro de conformidade	Presente = valor mínimo de piso, independentemente de outras pontuações.
receita adjacente	Análise do fluxo de dados para sistemas de faturamento/receita	Adjacência direta = valor mais alto
Contagem de usuários ou contagem de chamadas de API	Registros de acesso, tráfego de rede	Contagem alta = valor mais alto

A principal conclusão: para sistemas COBOL legados, a maioria desses indicadores não está disponível em registros do CMDB, entrevistas com proprietários de aplicativos ou análises de tráfego de rede. Eles estão disponíveis por meio da análise estrutural do código-fonte, logs de execução e do agendamento de tarefas JCL, que documenta o que realmente é executado em produção e quando.

Avaliação da adequação técnica para sistemas COBOL e legados

Os critérios padrão de avaliação de adequação técnica, compatibilidade com APIs, prontidão para ambientes nativos da nuvem, suporte a conteinerização e arquitetura de microsserviços são irrelevantes para programas COBOL em lote. Um programa COBOL não pode ser conteinerizado; avaliá-lo com base em critérios nativos da nuvem resulta em uma pontuação de adequação técnica zero para todos os programas legados, o que não fornece informações úteis para a organização.

Para sistemas COBOL e mainframe, a pontuação de adequação técnica requer critérios específicos do COBOL:

Índice de complexidade (peso: 30%): Complexidade ciclomática média entre os parágrafos e seções do programa. Programas com CC média abaixo de 10 apresentam complexidade gerenciável; programas acima de 20 apresentam complexidade estrutural que torna a manutenção dispendiosa e arriscada.

Pontuação de manutenibilidade (peso: 25%): Composta pela porcentagem de código morto, abrangência do compartilhamento de copybooks e taxa de duplicação. Um programa com 40% de código morto, 15 copybooks compartilhados e duplicação de código significativa apresenta baixa manutenibilidade, independentemente de sua correção funcional.

Pontuação de risco de dependência (peso: 20%): Contagem de fan-in ponderada pela criticidade das dependências de entrada. Um programa com 50 dependências de entrada de programas de Nível 1 apresenta alto risco de dependência; alterações nele exigem a coordenação de 50 programas subsequentes.

Pontuação de atualização (peso: 15%): atualização do dialeto COBOL e da versão do compilador, modernidade da sintaxe JCL e interface do banco de dados (SQL embutido, VSAM vs DB2, somente em lote vs lote + CICS). Programas escritos em sintaxe COBOL-85 com SQL embutido no DB2 são mais atuais do que programas escritos em COBOL-74 com acesso a arquivos somente por VSAM.

Pontuação de postura de segurança (peso: 10%): Presença de credenciais embutidas no código, acesso a arquivos desprotegido, ausência de verificação do STATUS DO ARQUIVO e exposição à injeção de SQL na construção dinâmica de SQL.

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

Esta fórmula de pontuação gera uma nota de adequação técnica de 0 a 100, derivada da análise do código estrutural, em vez de uma avaliação qualitativa. Duas aplicações com funções idênticas, mas características estruturais diferentes, produzirão notas de adequação técnica diferentes, e essas notas refletirão com precisão o investimento necessário para manter e ampliar cada uma delas.

O Problema da Deriva Tolerante: Governança para o Quadrante de Sustentação

O quadrante Tolerar acumula dívidas ao longo do tempo em todas as organizações que utilizam o sistema TIME sem uma governança explícita de Tolerância. O mecanismo é simples: uma aplicação entra no quadrante Tolerar porque não vale a pena alterá-la e, em seguida, permanece lá indefinidamente, pois alterá-la nunca é a prioridade mais urgente.

Uma disciplina de governança tolerante impede o adiamento indefinido:

Gatilhos de reclassificação baseados em condições:

• Vulnerabilidade de segurança identificada que não pode ser corrigida em 30 dias → analisar para Migração ou Eliminação
• O fornecedor anuncia o fim da vida útil de um componente da plataforma do qual o aplicativo depende → revisão para Migrate
• A pontuação de valor do negócio aumenta acima do limite (novo requisito regulatório, mudança no modelo de negócios) → revisão para Investir ou Migrar
• A descontinuação de dependências força a mudança de interface → revisão para Migrar ou Eliminar
• A análise de código morto revela que o aplicativo está efetivamente inativo → revisar para Eliminar

Cadência de revisão baseada no tempo:

• As candidaturas entram no Tolerate com um prazo de revisão de 12 meses.
• Na revisão de 12 meses, o pedido é explicitamente reclassificado ou explicitamente re-tolerado com uma nova data de 12 meses.
• A re-tolerância exige uma justificativa por escrito que documente por que as condições não mudaram.
• Uma aplicação que tenha sido Re-Tolerada mais de duas vezes sem reclassificação aciona uma escalação para o comitê de revisão de arquitetura.

O registro Tolerate: uma lista atualizada de todos os aplicativos Tolerate, com sua data de classificação, data de revisão, proprietário e o conjunto de condições que acionaria a reclassificação. Este registro é revisado em todas as reuniões do conselho de revisão de arquitetura, não apenas na revisão anual do portfólio.

Tornando o Plano de Eliminação Executável: Preenchendo a Lacuna do Descomissionamento

A lacuna entre “classificado como Eliminar” e “desativado com sucesso” é onde os programas de racionalização travam. Para superar essa lacuna, é preciso tratar cada decisão de Eliminar como um projeto com escopo, dependências e critérios de sucesso definidos, e não como uma conclusão.

Lista de verificação de execução do Eliminate:

• Verificação de dependência concluída: A análise estática confirma a ausência de dependências de produção de entrada (não apenas a ausência de dependências documentadas, mas sim a ausência de dependências estruturalmente verificadas).
• Plano de descarte de dados aprovado: Requisitos regulamentares de retenção identificados, plano de migração ou arquivamento de dados aprovado pelas áreas jurídica e de conformidade.
• Notificação downstream concluída: O proprietário de cada sistema consumidor foi notificado e confirmou que não há dependências ativas.
• Verificação de obrigações regulatórias concluída: Não há requisitos ativos de submissão regulatória, auditoria ou conformidade que dependam da aplicação.
• Responsável pela desativação: A pessoa designada é responsável por executar o descomissionamento, e não apenas pela decisão de classificação.
• Plano de reversão definido: Procedimento para restabelecer o serviço caso a desativação revele uma dependência não detectada.
• Data de desativação definida: Data específica no calendário de TI, não "quando tivermos tempo".

A etapa de análise estrutural: nenhuma decisão de Eliminar prossegue para o planejamento de desativação até que uma análise estrutural confirme a ausência de dependências de entrada provenientes dos caminhos de execução de produção. A causa mais comum de falha na execução da etapa de Eliminar é a descoberta de uma dependência após o anúncio de desativação, o que força uma reversão. A análise de dependências estruturais realizada antes do anúncio evita esse problema.

O Ciclo de Reavaliação TIME

As classificações de TEMPO não são permanentes. O valor comercial muda conforme a estratégia da organização evolui. A adequação técnica muda conforme o aplicativo é mantido, estendido ou deixado de lado por um tempo. O modelo é um instantâneo; o portfólio requer uma visão em movimento.

Reavaliação completa anual: Cada proposta no portfólio é avaliada de acordo com os critérios atuais de valor comercial e adequação técnica. Classificações que não sofreram alterações em três anos consecutivos são analisadas especificamente, seja porque a proposta é realmente estável (com justificativa documentada), seja porque a avaliação não está captando as mudanças que estão ocorrendo.

Reavaliação desencadeada por eventos: Eventos específicos desencadeiam uma revisão imediata de reclassificação.

• Fusão ou aquisição (nova combinação de portfólio)
• Alteração regulamentar que afeta as obrigações de conformidade
• Anúncio importante do fim do suporte a plataformas (banco de dados, sistema operacional, ambiente de execução)
• Mudança significativa no modelo de negócios (nova linha de produtos, saída do mercado, reestruturação organizacional)
• Incidente de segurança envolvendo o aplicativo

Disciplina de registro de alterações: Cada reclassificação é registrada com: classificação anterior, nova classificação, data, evidência que motivou a alteração e aprovador. O histórico de classificação de cada aplicação é a trilha de auditoria que demonstra que o portfólio é gerenciado ativamente, em vez de ser categorizado e esquecido.

Como SMART TS XL Fornece evidências para a classificação TIME.

As decisões de classificação do modelo TIME são tão boas quanto as evidências que as sustentam. Para aplicações modernas com cobertura de CMDB, monitoramento de API e arquiteturas documentadas, essas evidências são acessíveis. Para portfólios COBOL legados onde o CMDB está incompleto, os proprietários se aposentaram e a estrutura de dependências não está documentada, as evidências devem vir da análise estrutural do próprio código.

SMART TS XL'S análise de código estático Produz os dados de adequação técnica que a avaliação COBOL exige: complexidade ciclomática por programa, percentual de código morto, identificação de padrões de segurança (credenciais embutidas no código, acesso a arquivos desprotegidos) e atualização do dialeto COBOL. Essas métricas são derivadas do código-fonte, não de estimativas de desenvolvedores, e não dependem da memória de ninguém sobre o funcionamento da aplicação.

O mapeamento de dependências da aplicação gera as contagens de fan-in que impedem decisões prematuras de Eliminação e as contagens de fan-out que dão suporte à pontuação de valor de negócio. Uma aplicação com 45 dependências de entrada provenientes de programas de produção não é uma candidata segura à Eliminação, independentemente de como seu proprietário avalie seu valor de negócio. A contagem de dependências é o fato estrutural que se sobrepõe ao argumento de classificação.

A análise de modernização de sistemas legados gera um inventário de código morto que altera as classificações: programas que aparecem no CMDB como aplicativos ativos, mas que não possuem dependências de produção de entrada, são considerados candidatos a código morto, sendo reclassificados de Tolerável para Eliminar com base em evidências estruturais, e não na avaliação do proprietário da empresa sobre um programa cuja existência ele talvez nem soubesse.

A capacidade de análise de impacto torna a lista de verificação de execução da etapa de Eliminação viável: a análise estrutural que confirma a ausência de dependências de produção antes do início de qualquer planejamento de desativação. Este é o fator que impede a falha mais comum na execução da etapa de Eliminação: a dependência não detectada que surge após o anúncio.

A funcionalidade de busca corporativa permite consultar o processo de classificação TIME ao longo de todo o ciclo de reavaliação: encontre todas as aplicações classificadas como Toleráveis ​​com data de revisão nos próximos 30 dias, todas as aplicações classificadas como Eliminar sem data de desativação definida e todas as aplicações com pontuação de adequação técnica inferior a 30 que ainda estejam classificadas como Investir. Essas consultas são a ferramenta de governança que mantém o modelo TIME como um instrumento de gestão ativa, em vez de um exercício de classificação pontual.

Uma estrutura só é tão boa quanto as evidências que a sustentam.

A estrutura de dois eixos do modelo TIME está correta. Valor comercial e adequação técnica são as dimensões certas para as decisões de portfólio de aplicações. As quatro disposições são as opções corretas. O problema não está na estrutura em si, mas sim nas evidências que as organizações trazem para ela.

Classificações baseadas em dados de entrevistas e estimativas do CMDB geram debates organizacionais. Classificações baseadas em análise estrutural, complexidade mensurada, contagem de dependências verificada e adequação técnica derivada do código produzem decisões defensáveis. O proprietário da aplicação que argumenta que seu programa COBOL é um investimento em vez de uma migração tem um argumento mais fraco quando a análise estrutural mostra uma complexidade ciclomática média de 35, 40% de código morto e 12 vulnerabilidades de segurança. A equipe de TI que argumenta que um programa pode ser eliminado tem um argumento mais fraco quando a análise de dependências mostra 45 dependências de produção de entrada.

O modelo TIME funciona quando as evidências o sustentam. A análise estrutural do portfólio de aplicações é a forma como as organizações constroem essas evidências para as aplicações legadas que mais necessitam de decisões de racionalização e que têm menor probabilidade de possuir a documentação que facilite essas decisões.