Modelo TIME (Tolerar, Invertir, Migrar, Eliminar) para carteras de aplicaciones

La reunión de racionalización de aplicaciones comienza a las 9 a. m. A las 11 a. m., el equipo ha clasificado doce de las cuatrocientas aplicaciones incluidas en el alcance. Tres de esas doce clasificaciones ya han sido impugnadas, revisadas y nuevamente impugnadas. El programa por lotes COBOL que gestiona la nómina claramente no se puede eliminar, pero ¿se puede tolerar o invertir? El sistema de facturación heredado, que todos coinciden en que es técnicamente inadecuado, claramente se puede migrar, pero ¿a qué?, ¿y qué sucede con los diecisiete programas que dependen de él? La reunión está programada hasta el mediodía. Al mediodía, alguien sugiere continuar la semana siguiente. Para el mes siguiente, la iniciativa ha dejado de producir resultados discretamente.

El modelo TIME de Gartner es el marco de gestión de cartera de aplicaciones más utilizado en TI empresarial. Clasifica cada aplicación de la cartera en una de cuatro categorías: Tolerar, Invertir, Migrar o Eliminar, utilizando dos dimensiones de puntuación: valor de negocio y adecuación técnica. El marco es lógicamente sólido, de amplia aplicación y el Manual de Racionalización de Aplicaciones del Consejo de CIO federal de EE. UU. lo cita como metodología recomendada. Sin embargo, en la práctica suele fallar más de lo que acierta, por una razón que sus defensores mencionan pero rara vez desarrollan: la validez de las clasificaciones depende de la evidencia que las respalda. Sin evidencia estructural, recuentos reales de dependencias, mediciones reales de complejidad y datos reales de valor de negocio derivados de registros de ejecución en lugar de entrevistas con los propietarios, las clasificaciones TIME se convierten en política organizacional. Los debates sobre la ubicación comienzan en Migrar o Eliminar, donde está en juego la aplicación favorita de alguien, y nunca se resuelven.

El modelo: dos ejes, cuatro disposiciones

El modelo TIME representa cada aplicación en una matriz de 2x2. El eje horizontal indica la idoneidad técnica, es decir, qué tan bien la implementación técnica actual de la aplicación respalda su función prevista: calidad de la arquitectura, mantenibilidad, capacidad de integración, postura de seguridad y confiabilidad operativa. El eje vertical representa el valor comercial, es decir, qué tan importante es la función de la aplicación para las operaciones comerciales de la organización, la generación de ingresos, el cumplimiento normativo o los objetivos estratégicos.

	Ajuste técnico de alto nivel	Ajuste técnico bajo
Alto valor comercial	INVIERTEFinancienla. La aplicación es estratégicamente importante y técnicamente sólida. Inviertan para mantener su liderazgo.	EMIGRARLa empresa lo necesita, la tecnología es incorrecta. Reemplace la plataforma, no la función.
Bajo valor comercial	TOLERARDéjalo estar por ahora. La aplicación funciona bien, pero no merece una inversión adicional.	ELIMINARRetíralo. Poco valor, baja calidad, no hay razón para conservarlo.

La simplicidad es intencional. TIME no está diseñado para generar una planificación de inversiones minuciosa, sino para tomar decisiones direccionales claras para cada aplicación de la cartera. Una aplicación que no se puede clasificar con claridad requiere más información antes de poder ser clasificada.

Los modelos operativos de los cuatro cuadrantes

Cada estado de TIME no es solo una etiqueta, sino un modelo operativo que determina cómo la organización gestiona la aplicación en el futuro.

Invertir: Máxima extracción de valor

Las aplicaciones Invest son la joya de la corona de la cartera: alto valor comercial y excelente compatibilidad técnica. Justifican la inversión más agresiva en nuevas funcionalidades, optimización del rendimiento, expansión de la integración y mantenimiento de la tecnología. Una aplicación Invest que se queda atrás en cuanto a su actualización técnica, un entorno de ejecución obsoleto, una postura de seguridad desactualizada y una deuda técnica acumulada, corre el riesgo de entrar en migración antes de que se detecte el problema.

Compromisos operativos para Invest:

• Capacidad de ingeniería especializada para el desarrollo de funciones y el mantenimiento técnico.
• Actualizaciones de cumplimiento y parches de seguridad de primera prioridad
• Cobertura del comité de revisión de arquitectura para cada cambio significativo
• Monitorización proactiva con objetivos SLA en el nivel Tier 1

Migrar: Reemplazar la plataforma, conservar la funcionalidad.

Las aplicaciones migradas cumplen una función empresarial que la organización realmente necesita, pero se encuentran en una plataforma técnica que ya no es adecuada, es demasiado costosa de mantener, demasiado frágil para ampliar y está demasiado aislada del panorama de integración moderno. El valor empresarial justifica la inversión en la migración; el estado técnico hace que continuar invirtiendo en la plataforma actual no genere un buen retorno.

La decisión de migrar responde a una pregunta específica: ¿merece la pena conservar la función? Si la respuesta es sí, migre. A qué plataforma migrar y cómo hacerlo es una decisión independiente que la clasificación TIME no toma; simplemente establece que la plataforma actual no es la solución.

El escenario de migración más común en entornos heredados: un programa por lotes COBOL que implementa lógica empresarial crítica, cálculos regulatorios complejos, reglas de precios propietarias y lógica fiscal específica de cada jurisdicción, en una plataforma que dificulta su ampliación, prueba e integración. La lógica es irremplazable; el problema reside en la plataforma. La solución es migrar a una plataforma moderna que conserve la lógica y, al mismo tiempo, proporcione las características operativas que la empresa requiere actualmente.

Tolerar: Inacción deliberada con fecha de caducidad

El cuadrante de tolerancia es el más incomprendido. No significa «esta aplicación está bien», sino «la calidad técnica de esta aplicación no justifica la inversión necesaria para modificarla ahora mismo, y su valor comercial no justifica su eliminación». Se trata de una decisión deliberada de aceptar el statu quo durante un período determinado, no de una postergación indefinida.

La tolerancia es un estado de espera temporal, no permanente. Cada aplicación en el cuadrante de tolerancia debe tener una fecha de revisión explícita, generalmente de 12 a 18 meses, y condiciones definidas que desencadenarían una reclasificación anticipada: una vulnerabilidad de seguridad que no se puede parchear, la eliminación de una dependencia que obliga a un cambio de plataforma, un aumento del valor comercial que justifica la inversión en la aplicación o un cambio en la función comercial que elimina su propósito.

Las organizaciones que consideran la tolerancia como algo permanente acumulan precisamente la deuda técnica que el modelo TIME fue diseñado para prevenir. Un programa COBOL tolerado en 2019 que aún se encuentra en el cuadrante de tolerancia en 2026 ha recibido siete años adicionales de mantenimiento diferido que eventualmente necesitará, ya sea como una emergencia cuando algo falle o como una migración forzada cuando la plataforma ya no pueda recibir soporte.

Eliminar: La decisión que todos toman y nadie ejecuta

Eliminar es la clasificación más sencilla y la menos ejecutada. La aplicación tiene poco valor comercial y poca adecuación técnica; no hay razón para conservarla. Retírela.

El fracaso en la ejecución está bien documentado: la lista de proyectos a eliminar se llena con entusiasmo, pero casi nunca se implementa. Una revisión de cartera realizada en 2024 en una gran institución financiera arrojó 87 proyectos candidatos a eliminar. Dieciocho meses después, 71 de ellos seguían activos. El lapso entre la clasificación y la desactivación es donde los programas de racionalización pierden impulso.

Tres obstáculos específicos impiden la eliminación de la ejecución:

Dependencias ocultas. La aplicación se clasificó como "Eliminar" debido a su aparente independencia. Tras la clasificación, un análisis estructural revela que otros doce programas generan resultados que la aplicación candidata a "Eliminar" procesa, o que tres sistemas externos le envían datos a través de una interfaz de archivos no documentada. La aplicación no es independiente; es la infraestructura oculta de otros sistemas. Es necesario revisar la clasificación.

Obstáculos para la migración de datos. La aplicación contiene datos que no se pueden destruir, registros regulatorios con periodos de retención obligatorios, datos de clientes que deben transferirse a un sistema sucesor y registros históricos de transacciones que los procesos de auditoría consultan anualmente. La migración de datos debe preceder a la desactivación y es costosa.

Obligaciones regulatorias. Algunas aplicaciones no pueden retirarse aunque su valor comercial sea cero, porque los marcos regulatorios exigen la funcionalidad que proporcionan. Una aplicación de informes que genera un informe regulatorio trimestral tiene un valor regulatorio que no aparece en ningún análisis de valor comercial. Hasta que la obligación regulatoria se transfiera a otro sistema, la aplicación debe seguir funcionando.

El problema de la evidencia: por qué TIME falla sin datos estructurales.

El principal problema en las implementaciones de TIME es precisamente lo que la documentación de Catio identifica: las discusiones sobre la ubicación de las aplicaciones comienzan con Migrar y Eliminar, donde la aplicación favorita de alguien está en juego. Sin evidencia objetiva, cada clasificación se convierte en una negociación. El responsable de la aplicación aboga por Invertir. El equipo de TI aboga por Migrar. El equipo de finanzas prefiere Eliminar. La reunión termina con Tolerar porque es la opción menos controvertida.

La evidencia estructural resuelve estas negociaciones al reemplazar la opinión con la medición.

Para la evaluación del ajuste técnico, la evidencia que importa es:

Indicador de ajuste técnico	Fuente	Mueve la clasificación hacia
Complejidad ciclomática por programa (promedio)	Análisis de código estático	Bajo = mejor ajuste, Alto = peor ajuste
Porcentaje de código muerto	Análisis de accesibilidad	Código muerto alto = ajuste inferior
Recuento de dependencias entrantes (Fan-in)	Mapeo de dependencia	Los altos aumentos de entrada de ventilador Tolerar sobre Eliminar
Cuaderno de ejercicios que comparte amplitud	Análisis de dependencia de COPIA	Mayor compartición = mayor acoplamiento = menor ajuste
Tiempo transcurrido desde el último cambio significativo	Registro de gestión de cambios/Git	Un período prolongado de inactividad puede indicar código muerto o inestabilidad.
número de vulnerabilidades de seguridad	escaneo SAST	Recuento alto = ajuste más bajo

Para la evaluación del valor empresarial, la evidencia que importa es la siguiente:

Indicador de valor empresarial	Fuente	Mueve la clasificación hacia
Volumen de transacciones por período	Registros de ejecución de JCL, registros del planificador	Mayor volumen = mayor valor
ramificación aguas abajo	Mapeo de dependencia	Mayor factor de ramificación = mayor valor (muchos dependen de él)
Indicador de función regulatoria	Clasificación de datos, registro de cumplimiento	Presente = valor mínimo piso independientemente de otras puntuaciones
Adyacencia de ingresos	Análisis del flujo de datos hacia los sistemas de facturación/ingresos	Adyacencia directa = mayor valor
Número de usuarios o número de llamadas a la API	Registros de acceso, tráfico de red	Recuento alto = valor más alto

La clave reside en lo siguiente: para los sistemas COBOL heredados, la mayoría de estos indicadores no se obtienen de las entradas de la CMDB, las entrevistas con los responsables de la aplicación ni el análisis del tráfico de red. Se obtienen mediante el análisis estructural del código fuente, los registros de ejecución y la planificación de trabajos JCL, que documenta qué se ejecuta realmente en producción y cuándo.

Evaluación de la idoneidad técnica para COBOL y sistemas heredados

Los criterios estándar de evaluación de idoneidad técnica, como la compatibilidad con API, la preparación para la nube, la compatibilidad con contenedores y la arquitectura de microservicios, resultan irrelevantes para los programas por lotes de COBOL. Un programa COBOL no puede contenerizarse; evaluarlo según los criterios de la nube produce una puntuación de idoneidad técnica de cero para todos los programas heredados, lo que no aporta información útil a la organización.

Para los sistemas COBOL y mainframe, la puntuación de idoneidad técnica requiere criterios específicos de COBOL:

Puntuación de complejidad (ponderación: 30%): Complejidad ciclomática promedio en los párrafos y secciones del programa. Los programas con una CC promedio inferior a 10 tienen una complejidad manejable; los programas superiores a 20 tienen una complejidad estructural que hace que el mantenimiento sea costoso y arriesgado.

Puntuación de mantenibilidad (ponderación: 25%): Compuesto por el porcentaje de código muerto, la amplitud del uso compartido de copybooks y la tasa de duplicación. Un programa con un 40% de código muerto, 15 copybooks compartidos y una duplicación de código significativa tiene baja mantenibilidad, independientemente de su corrección funcional.

Puntuación de riesgo de dependencia (ponderación: 20%): Recuento de dependencias entrantes ponderado por la criticidad de las dependencias entrantes. Un programa con 50 dependencias entrantes de programas de Nivel 1 tiene un alto riesgo de dependencia; cualquier cambio en él requiere la coordinación de 50 programas posteriores.

Puntuación de vigencia (ponderación: 15%): vigencia del dialecto COBOL y la versión del compilador, modernidad de la sintaxis JCL e interfaz de base de datos (versión de SQL integrado, VSAM frente a DB2, solo procesamiento por lotes frente a procesamiento por lotes + CICS). Los programas escritos en sintaxis COBOL-85 con SQL integrado en DB2 son más actuales que los programas escritos en COBOL-74 con acceso a archivos solo mediante VSAM.

Puntuación de seguridad (ponderación: 10%): Presencia de credenciales codificadas, acceso a archivos sin protección, ausencia de comprobación del ESTADO DEL ARCHIVO y exposición a la inyección SQL en la construcción 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 puntuación genera una calificación de adecuación técnica de 0 a 100, derivada del análisis del código estructural en lugar de una evaluación cualitativa. Dos aplicaciones con funciones idénticas pero características estructurales diferentes producirán calificaciones de adecuación técnica distintas, y estas calificaciones reflejarán con precisión la diferente inversión necesaria para el mantenimiento y la ampliación de cada una.

El problema de la deriva tolerante: gobernanza para el cuadrante de retención

Tolerar es el cuadrante que acumula deuda con el tiempo en toda organización que utiliza TIME sin una gobernanza explícita de Tolerar. El mecanismo es simple: una aplicación entra en Tolerar porque no vale la pena cambiarla, y luego permanece en Tolerar indefinidamente porque cambiarla nunca es la prioridad más urgente.

Una disciplina de gobernanza tolerante evita el aplazamiento indefinido:

Desencadenantes de reclasificación basados ​​en condiciones:

• Se ha identificado una vulnerabilidad de seguridad que no se puede solucionar en 30 días → revisar para migrar o eliminar.
• El proveedor anuncia el fin del ciclo de vida de un componente de la plataforma del que depende la aplicación → revisión para Migrate
• La puntuación de valor empresarial aumenta por encima del umbral (nuevo requisito normativo, cambio de modelo de negocio) → revisión para invertir o migrar.
• La retirada de dependencias obliga a cambiar la interfaz → revisión para Migrar o Eliminar
• El análisis de código muerto revela que la aplicación está prácticamente inactiva → revisión para Eliminar

Ritmo de revisión basado en el tiempo:

• Las solicitudes ingresan a Tolerate con una fecha de revisión de 12 meses.
• En la revisión de 12 meses, la solicitud se reclasifica explícitamente o se vuelve a tolerar explícitamente con una nueva fecha de 12 meses.
• La readmisión a la tolerancia requiere una justificación por escrito que documente por qué las condiciones no han cambiado.
• Una aplicación que ha sido readmitida más de dos veces sin reclasificación desencadena una escalada al comité de revisión de arquitectura.

El registro Tolerate: Una lista actualizada de todas las solicitudes Tolerate con su fecha de clasificación, fecha de revisión, propietario y el conjunto de condiciones que desencadenaría una reclasificación. Este registro se revisa en cada reunión del comité de revisión de arquitectura, no solo en la revisión anual del portafolio.

Hacer que Eliminar sea ejecutable: Cerrando la brecha en el desmantelamiento

La brecha entre “clasificado como eliminado” y “desmantelado con éxito” es donde se estancan los programas de racionalización. Para cerrar esa brecha, es necesario tratar cada decisión de eliminación como un proyecto con un alcance, dependencias y criterios de éxito definidos, y no como una conclusión.

Lista de verificación para la ejecución de Eliminate:

• Verificación de dependencias completada: El análisis estático confirma que no existen dependencias de producción entrantes (no solo dependencias documentadas, sino dependencias verificadas estructuralmente).
• Plan de disposición de datos aprobado: Se han identificado los requisitos reglamentarios de retención de datos y el plan de migración o archivo de datos ha sido aprobado por el departamento legal y de cumplimiento normativo.
• Notificación descendente completada: El propietario de cada sistema consumidor fue notificado y confirmó que no existe ninguna dependencia activa.
• Verificación de obligaciones regulatorias completada: No existe ningún requisito activo de presentación regulatoria, auditoría o cumplimiento que dependa de la aplicación.
• Responsable de la baja asignado: Persona designada responsable de ejecutar la desmantelación, no solo la decisión de clasificación.
• Plan de reversión definido: Procedimiento para restablecer el servicio si la desactivación revela una dependencia no detectada.
• Fecha de desmantelamiento comprometida: Fecha específica en el calendario de TI, no "cuando tengamos tiempo".

El proceso de análisis estructural, en el que no se toma ninguna decisión de eliminación, continúa con la planificación del desmantelamiento hasta que un análisis estructural confirme la ausencia de dependencias entrantes provenientes de las rutas de ejecución de producción. La causa más común de fallo en la ejecución de la eliminación es el descubrimiento de una dependencia después del anuncio del desmantelamiento, lo que obliga a realizar una reversión. El análisis de dependencias estructurales previo al anuncio evita este problema.

El ciclo de reevaluación de TIME

Las clasificaciones TIME no son permanentes. El valor empresarial cambia a medida que evoluciona la estrategia de la organización. La adecuación técnica cambia a medida que la aplicación se mantiene, se amplía o se deja envejecer. El modelo es una instantánea; la cartera requiere una visión dinámica.

Reevaluación anual completa: Cada solicitud del portafolio se evalúa según los criterios actuales de valor comercial y adecuación técnica. Las clasificaciones que no han cambiado en tres años consecutivos se examinan específicamente, ya sea porque la solicitud es realmente estable (documentando el motivo) o porque la evaluación no refleja los cambios que se están produciendo.

Reevaluación desencadenada por eventos: Ciertos eventos desencadenan una revisión de reclasificación inmediata:

• Fusión o adquisición (combinación de nuevas carteras)
• Cambios normativos que afectan a las obligaciones de cumplimiento
• Anuncio importante sobre el fin del ciclo de vida de una plataforma (base de datos, sistema operativo, entorno de ejecución).
• Cambio significativo en el modelo de negocio (nueva línea de productos, salida del mercado, reestructuración organizativa).
• Incidente de seguridad relacionado con la aplicación

Disciplina del registro de cambios: Cada reclasificación se registra con la siguiente información: clasificación anterior, nueva clasificación, fecha, evidencia que motivó el cambio y aprobador. El historial de clasificación de cada solicitud constituye la pista de auditoría que demuestra que la cartera se gestiona activamente, en lugar de simplemente categorizarse y olvidarse.

Cómo SMART TS XL Proporciona la evidencia para la clasificación TIME.

Las decisiones de clasificación del modelo TIME son tan buenas como la evidencia que las respalda. Para aplicaciones modernas con cobertura CMDB, monitorización de API y arquitecturas documentadas, dicha evidencia es accesible. Para carteras de COBOL heredadas donde la CMDB está incompleta, los propietarios se han jubilado y la estructura de dependencias no está documentada, la evidencia debe provenir del análisis estructural del propio código.

SMART TS XL, análisis de código estático Genera los datos técnicos necesarios para la evaluación de COBOL: complejidad ciclomática por programa, porcentaje de código muerto, detección de patrones de seguridad (credenciales codificadas, acceso a archivos sin protección) y vigencia del dialecto COBOL. Estas métricas se derivan del código fuente, no de estimaciones de los desarrolladores, y no dependen de que nadie recuerde la función de la aplicación.

El mapeo de dependencias de la aplicación genera los recuentos de entrada que impiden decisiones de eliminación prematuras y los recuentos de salida que respaldan la puntuación del valor comercial. Una aplicación con 45 dependencias entrantes de programas de producción no es una candidata segura para la eliminación, independientemente de cómo su propietario evalúe su valor comercial. El recuento de dependencias es el hecho estructural que prevalece sobre el argumento de clasificación.

El análisis de modernización de sistemas heredados genera un inventario de código muerto que modifica las clasificaciones: los programas que aparecen en la CMDB como aplicaciones activas, pero que no tienen dependencias de producción entrantes, son candidatos a código muerto y se reclasifican de Tolerado a Eliminar en función de la evidencia estructural, no de la evaluación que el propietario del negocio haga de un programa cuya existencia quizás desconocía.

La capacidad de análisis de impacto permite completar la lista de verificación de ejecución de Eliminate: el análisis estructural que confirma la ausencia de dependencias de producción entrantes antes de que comience cualquier planificación de desmantelamiento. Este es el filtro que previene el fallo más común en la ejecución de Eliminate: la dependencia no descubierta que surge después del anuncio.

La función de búsqueda empresarial permite consultar el proceso de clasificación TIME durante todo el ciclo de reevaluación: encuentre todas las aplicaciones clasificadas como Tolerables con fecha de revisión en los próximos 30 días, todas las clasificadas como Eliminables sin fecha de desmantelamiento asignada, y todas las aplicaciones con una puntuación de ajuste técnico inferior a 30 que aún estén clasificadas como Inversiones. Estas consultas constituyen la herramienta de gobernanza que mantiene el modelo TIME como un instrumento de gestión activo, en lugar de un simple ejercicio de clasificación puntual.

Un marco de referencia es tan bueno como las pruebas que lo respaldan.

La estructura de dos ejes del modelo TIME es correcta. El valor comercial y la adecuación técnica son las dimensiones adecuadas para las decisiones sobre la cartera de aplicaciones. Las cuatro disposiciones son las opciones correctas. El problema no reside en el marco, sino en la evidencia que las organizaciones aportan a él.

Las clasificaciones basadas en datos de entrevistas y estimaciones de CMDB generan debates organizacionales. Las clasificaciones basadas en análisis estructural, complejidad medida, recuentos de dependencias verificados y aptitud técnica derivada del código, producen decisiones defendibles. El propietario de la aplicación que argumenta que su programa COBOL es para inversión en lugar de migración tiene argumentos más débiles cuando el análisis estructural muestra una complejidad ciclomática promedio de 35, un 40 % de código muerto y 12 hallazgos de seguridad. El equipo de TI que argumenta que un programa puede eliminarse tiene argumentos más débiles cuando el análisis de dependencias muestra 45 dependencias de producción entrantes.

El modelo TIME funciona cuando la evidencia lo justifica. El análisis estructural del portafolio de aplicaciones es la forma en que las organizaciones generan esa evidencia para las aplicaciones heredadas que más necesitan decisiones de racionalización y que tienen menos probabilidades de contar con la documentación que facilite dichas decisiones.