6 minutos de lectura
La trampa de la deuda técnica: por qué el código heredado está ralentizando a las universidades
Introducción
Existe cierta deuda técnica en el departamento de TI de cada universidad. Es una consecuencia inevitable de trabajar rápidamente, cumplir con los plazos de entrega y mantener las operaciones durante la semana de inscripciones. Sin embargo, cuando las instituciones no saldan esa deuda, esta se acumula y se vuelve mucho más costosa que el tiempo mismo.
Los sistemas heredados de hace diez o más años siguen impulsando funciones esenciales en la TI de la educación superior, incluyendo la ayuda financiera, admisiones, procesos de registro e incluso partes del LMS. Fueron diseñados para un entorno de seguridad diferente, un ritmo de desarrollo distinto y una era diferente de expectativas de los estudiantes. Hoy en día, con frecuencia son la causa inadvertida de sobrecostos presupuestarios, retrasos en los proyectos y de que los equipos de TI sientan que constantemente están tratando de ponerse al día.
Antes de que esto determine la estrategia de TI de su organización para los próximos 10 años, es importante comprender esta trampa de la deuda técnica.
Cómo se ve realmente la Deuda técnica en la educación superior
La deuda técnica es más que solo código desactualizado. Es el costo total de parches, atajos y actualizaciones retrasadas que tenían sentido en su momento, pero que ahora impiden el avance.
En un entorno universitario, con frecuencia se manifiesta como integraciones personalizadas creadas por un desarrollador o proveedor que ya no está, que es demasiado peligroso tocar y que nadie comprende realmente. Se manifiesta como soluciones rápidas para un problema particular que nunca se integraron en un diseño completo, o como soluciones puntuales agregadas de forma improvisada al SIS o al LMS.
Además, reside en marcos de trabajo desactualizados y versiones de software sin soporte que todavía se utilizan porque migrar parece más riesgoso que quedarse como están, así como en soluciones manuales que los empleados han incorporado discretamente en las operaciones diarias para compensar las limitaciones del sistema.
Esto no es culpa de ningún equipo en particular. Es el resultado de años de decisiones de "lo arreglaremos más tarde" tomadas bajo restricciones reales, y la dificultad radica en que ese "más tarde" rara vez ocurre hasta que la deuda obliga a enfrentar el problema.
Piense en una universidad que quiere implementar asesoramiento estudiantil impulsado por inteligencia artificial. El proyecto parece sencillo en papel. En realidad, se congela casi al instante porque la herramienta de asesoramiento descubre registros de estudiantes dispersos en tres sistemas históricos y algunos enlaces punto a punto no documentados creados hace años, cuando lo que requiere son datos limpios y conectados. Antes de que alguien tenga acceso a las capacidades de IA para las cuales se financió el proyecto, se pasan meses desenredando la infraestructura. El aspecto desafiante no fue la tecnología. Debajo de ella estaban los sistemas heredados.
Por qué la deuda técnica frena a las universidades
Es fácil subestimar la ralentización que esto causa hasta que se tiene que lidiar con ella. Cada proyecto nuevo se vuelve más costoso porque se requiere más tiempo para agregar una función, integrar una nueva herramienta o dar soporte a un nuevo requisito de informes cuando se debe eludir el código heredado en lugar de construir sobre una arquitectura sólida, lo que convierte solicitudes sencillas en esfuerzos de varios meses.
Además, hace que la seguridad y el cumplimiento sean más vulnerables. Cuando las instituciones gestionan datos financieros y de estudiantes que son confidenciales, los sistemas heredados representan un riesgo significativo, ya que son más difíciles de parchear, auditar y adaptar a las normativas de accesibilidad y protección de datos.
Debido a que los equipos dedican una cantidad de tiempo desproporcionada a mantener lo que ya existe en lugar de desarrollar lo que viene a continuación, postergando proyectos de IA, herramientas de aprendizaje personalizado y mejores experiencias orientadas a los estudiantes, esto agota la capacidad de TI que debería utilizarse para la innovación. En un momento en que ambos grupos desean cada vez más que el software universitario funcione como las aplicaciones de consumo contemporáneas, también perjudica la experiencia del personal y de los estudiantes, lo que genera fricciones para asesores, registradores y alumnos.
Lo más importante es que aumenta el costo de no hacer nada. La deuda técnica fluctúa. Si no se controla, empeora, lo que hace que un sistema que ya estaba sobrecargado sea más vulnerable con cada nueva integración o solución alternativa.
Reconocer la trampa: Deuda frente a inversión
La deuda técnica no siempre es algo negativo. Ante un plazo de entrega, tomar un atajo puede ser la mejor opción, siempre que se revise. Cuando la deuda se vuelve irreversible debido al impago, ahí es donde radica la trampa. La siguiente tabla explica cómo distinguir entre una trampa de deuda que está empezando a dictar la estrategia de TI de su institución y una deuda técnica manejable.
Convertir la deuda técnica en una prioridad de la estrategia de TI
Para la mayoría de las universidades, una reconstrucción única y masiva no es necesaria ni viable. Modernizar las aplicaciones obsoletas como un componente continuo de la estrategia de TI, en lugar de un ejercicio de limpieza de una sola vez, resulta más eficaz:
Haga un inventario antes de modernizar. Determine qué dependencias, integraciones y sistemas representan un riesgo real. Algunos componentes históricos solo requieren una mejor
documentación y supervisión, por lo que no es necesario eliminarlos todos.Priorice por el impacto empresarial, no por la antigüedad. Se le podría dar más atención a una integración de cinco años que ya está obstaculizando nuevas iniciativas que a un sistema de diez años que es sólido y bien comprendido.
Modernice de manera incremental. En lugar de desmantelar y reemplazar todo a la vez,
se superponen interfaces contemporáneas, API y componentes nativos de la nube alrededor de los núcleos heredados para reducir el riesgo mientras se sigue haciendo avanzar a la organización.Incorpore la reducción de la deuda en cada proyecto. En lugar de simplemente acumular más, los equipos deberían liquidar parte de las características anteriores cuando lancen otras nuevas.
Aporte experiencia externa donde sea necesario. Un socio de modernización con experiencia que pueda evaluar, priorizar e implementar sin empezar de cero es ideal para los sistemas heredados creados por personas que ya han dejado la organización.
Conclusión
Una interrupción del sistema no es un signo de deuda técnica. Esta se manifiesta sutilmente como insatisfacción de los trabajadores, proyectos retrasados y una brecha cada vez mayor entre lo que requiere su organización y lo que sus sistemas pueden proporcionar.
El objetivo de la modernización no es reemplazar cada aplicación heredada de la noche a la mañana. El objetivo es crear una arquitectura que permita la IA, el análisis y mejores experiencias para los estudiantes en el futuro sin que las limitaciones heredadas impidan cada iniciativa. Las universidades que lideran el camino en la transformación digital de la educación superior no son aquellas que no tienen código heredado; más bien, son aquellas que ven la modernización como una disciplina continua y no como una reacción a una crisis.
La pregunta no es si su institución tiene deuda técnica. Es si tiene un plan para ella o si esta se ha convertido sutilmente en el plan predeterminado.
