¿Gastar ahora y pagar más tarde? Saldar las cuentas pendientes de la deuda técnica

Cuando un cliente de servicios web cambia un ajuste, y una gran parte de internet se vuelve inaccesible como resultado, sabe que es hora de abordar las malas configuraciones y la deuda técnica. El apagón de Fastly, que hizo que varios servicios de noticias globales, áreas del sitio web gubernamental del Reino Unidoy algunos sitios de Amazon quedaran inactivos por más de una hora, catapultó a los ajustes de software y la administración de infraestructura de vuelta a una posición de protagonismo, que es exactamente donde deberían estar, en mi opinión.

La deuda técnica es un concepto complejo, que se remonta a décadas atrás, y las relativamente simples malas configuraciones como la de Fastly son solo un ejemplo muy visible de un problema mucho mayor. Pero, ¿qué significa, qué comprende y qué deben hacer al respecto los líderes de TI y seguridad?

¿Desarrollar ahora y pagar más tarde?

El problema de la deuda técnica se discute desde hace tiempo en los círculos de desarrollo de software, pero hoy todas las compañías y los departamentos operan en un mundo interconectado y digitalmente transformado, de modo que, al parecer, ha llegado la hora de saldar esa deuda. Esencialmente, la deuda técnica es la diferencia entre el “precio” (tiempo, recursos humanos, inversión en tecnología) que debe tener un proyecto técnico para ser perfecto y estar preparado para el futuro, y el “precio” que una organización está preparada para pagar en el momento.

Sin embargo, no vivimos en un mundo perfecto, de modo que la deuda técnica se acumula gradualmente, proyecto tras proyecto, y esto debe abordarse antes de que un producto desarrolle fallas, no pueda actualizarse o deje de funcionar por completo. Dado que trabajamos en organizaciones en constante cambio y con productos múltiples, resulta muy fácil que, poco a poco, se acumulen montos significativos de deuda técnica y que esto dé como resultado un incidente a gran escala que puede causar una fuga de datos, un ataque cibernético o un incidente de continuidad del negocio.

A mi entender, existen tres áreas principales donde se acumula la deuda técnica, los cuales deben monitorear los líderes comerciales y de TI como parte de sus programas de evaluación del riesgo en curso.

1. Inversión redirigida

Toda compañía evoluciona y elige redirigir presupuesto y recursos a productos y tecnologías nuevos o diferentes, al mismo tiempo que conservan los productos más antiguos, pero estos no reciben el mismo nivel de soporte que antes. Hasta aquí, todo normal. Sin embargo, si no se implementan planes de fin de vida útil, las empresas corren el riesgo de terminar teniendo productos creados con código desactualizado que no puede actualizarse a las versiones más recientes de los sistemas operativos, lo que da como resultado baches de seguridad significativos.

Cuando se deja de invertir en ciertos productos, el entorno de codificación tampoco se actualiza. Esto puede causar problemas con el mantenimiento y la administración en curso, mala configuración y vulnerabilidades.

Los cambios en la inversión no solo afectan a los productos más antiguos que se encuentran en el camino a ser retirados. También vemos que se genera deuda técnica con productos actualmente en uso, cuando una situación de desarrollo ideal lleva mucho tiempo e inversión, pero se puede crear un producto viable en un lapso más corto, incluso si no es perfecto. Encontrar ese equilibrio entre la perfección, la funcionalidad adecuada y la viabilidad mínima es todo un desafío, y algunas personas pueden encontrarse en una situación en la que se promete realizar mejoras una vez completado el proyecto, pero luego las prioridades comerciales cambian y los planes no se concretan.

Evidentemente, gestionar la deuda técnica en estas situaciones es un desafío muy concreto para los equipos de liderazgo. Opino que se puede encontrar un punto óptimo con una administración cuidadosa, pero los líderes de TI y del negocio deben trabajar en estrecha colaboración con los equipos de desarrollo, estableciendo objetivos claros y ayudando a crear un producto que sea a la vez satisfactorio para el desarrollador de software, seguro y de bajo riesgo, y aceptable para el líder que busca entregar un producto dentro de un lapso limitado.

2. Tecnología física

De manera similar, las centrales de datos físicas plagadas de enrutadores, firewalls y servidores necesitan mantenimiento. He visto muchos ejemplos de inversiones en centrales de datos que luego se abandonaron, sin más administración, por hasta casi cuatro años.

Esta caricatura lo resume: operar en sistemas complejos donde se añadieron o adosaron servicios nuevos a sistemas existentes puede dejar a una empresa en una posición precaria.

Dependency: https://xkcd.com/2347/

Lamentablemente, suelen ser nuestros servicios más críticos los que sufren a causa de los desafíos de la integración con sistemas existentes, aunque esto se está comenzando a abordar lentamente. Los servicios financieros y de atención médica ambos sufrieron interrupciones, fugas de datos y ataques que pueden paralizar a los servicios críticos. La infraestructura crítica suele estar desarrollada sobre la base de tecnología operativa (operational technology, OT) de propiedad exclusiva, la cual, cuando se conecta a servicios digitales modernos, puede exponer a las organizaciones a riesgos. Si sumamos a esto la gran cantidad de firmas pequeñas que constituyen la cadena de suministro a las empresas grandes, los gobiernos o la infraestructura crítica, tenemos la tormenta perfecta de tecnología existente y sin el debido soporte.

3. Personas

Posiblemente la parte más importante de la deuda técnica sea las personas. Los sistemas de software suelen desarrollarse a lo largo de décadas y su mantenimiento queda en manos de equipos de trabajadores con gran experiencia, habilidades de programación amplias (p. ej. PERL o Python) y años de conocimiento institucional. Estas personas dan servicio, mantienen y administran la tecnología y los servicios más antiguos, híbridos o con financiación insuficiente.

Sin embargo, a medida que las empresas evolucionan con el tiempo, y que los líderes adaptan las estrategias y redirigen los recursos a nuevos productos y servicios, los sistemas desarrollados sobre la base de código más antiguo pueden descuidarse. Los cambios organizativos pueden llevar a que las personas se sientan excluidas, lo que aumenta el riesgo de amenazas internas, algo que resulta de particular importancia si son ellos quienes administran la infraestructura de TI crítica.

La planificación de sucesión es fundamental, dado que todos los trabajadores a la larga se irán de la empresa o jubilarán, y si no se comparten los conocimientos de forma exhaustiva se corre el riesgo de enfrentar una situación en la que los sistemas más antiguos necesiten recibir mantenimiento de empleados nuevos que tienen habilidades de programación muy diferentes. Se debe mantener una higiene de seguridad cotidiana de los sistemas más antiguos, con la aplicación de parches y actualizaciones, y un manejo adecuado de las configuraciones.

¿Cómo deben los líderes de TI evaluar el riesgo y administrar la deuda técnica?

Los líderes de tecnología deben garantizar que los desarrolladores incorporen procesos de fin de vida útil a cada producto o proyecto de infraestructura, incluso desde el comienzo. Cuando ocurren cambios organizativos, también deben cambiar las evaluaciones de riesgos, se debe documentar el impacto potencial sobre el software y hardware, e implementar planes de contingencia.

Incluso para la tecnología en vías a finalizar su vida útil, se debe proporcionar cierta inversión en infraestructura y recursos humanos. Al desarrollar nuevo software, dé los pasos necesarios para invertir a futuro y planifique con vistas al cambio. En otras palabras, desarrolle pensando no solo en la escalabilidad, sino en opciones de actualización futuras.

Necesitamos planificación de sucesión para el software o, de lo contrario, nos arriesgamos a sufrir interrupciones impulsadas por vulnerabilidades o malas configuraciones, fugas de datos o ataques cibernéticos.

Apéndice

Recursos y ejemplos adicionales:

• https://www.businesswire.com/news/home/20210615005115/en/4994345/Study-Reveals-Majority-of-IT-Leaders-Consider-Technical-Debt-One-of-the-Biggest-Threats-to-Innovation-as-They-Build-Back
• Mala configuración de la base de datos en la nube de CVS Health deja expuestos más de mil millones de registros
• https://www.theregister.com/2021/06/18/bofh_2021_episode_8/