Tu sistema funciona de maravilla. Hasta que trabaja la persona que sabe por qué.
La empresa tiene un sistema que se desarrolló durante siete años. Funciona. Atiende a los clientes. Se conecta con otros sistemas. Ejecuta procesos sin los cuales la empresa, en la práctica, no podría funcionar con normalidad.
Durante esos siete años, en el proyecto trabajaron cinco programadores. Además, dos freelancers y una agencia. Parte de la documentación está en Confluence, parte en Google Drive, parte en tickets. En algún lugar también está el viejo documento sobre una de las integraciones. Y cuando alguien pregunta por qué un fragmento concreto del sistema funciona justo de esa manera, la respuesta es: "Creo que eso lo recordaba Michał."
Michał se fue hace tres años.
Y justo ahí empieza el verdadero problema.
No porque el sistema esté mal escrito. No porque de repente haya dejado de funcionar. El problema es que la empresa ha dejado de tener conocimiento completo sobre su propio sistema.
El sistema funciona, pero la empresa puede no controlarlo
Esta es una de las formas más infravaloradas de deuda tecnológica.
Cuando hablamos de deuda tecnológica, normalmente pensamos en código antiguo, bibliotecas desactualizadas, errores arquitectónicos, falta de pruebas o soluciones que antes eran rápidas, pero que hoy dificultan el desarrollo.
Mientras tanto, existe otro tipo de deuda. La deuda de conocimiento.
Surge cuando el sistema depende de información que no está en la documentación, el repositorio, los procedimientos ni en la organización, sino en la cabeza de personas concretas.
Y mientras esas personas estén disponibles, todo puede parecer normal.
El problema aparece con el cambio de equipo, la marcha de un programador, la finalización de la colaboración con una software house, una caída del servidor, el cambio de administrador o la necesidad de implantar rápidamente una nueva solución.
De repente resulta que la empresa tiene el código, pero no tiene el conocimiento.
Tiene servidor, pero no tiene certeza de quién tiene acceso.
Tiene una integración, pero no sabe con qué cuenta se creó.
Tiene documentación, pero no sabe cuál de sus versiones es la actual.
Tiene un proceso, pero no sabe por qué se diseñó justamente así.
Y entonces aparece muy rápido la pregunta: ¿quién es realmente el propietario de este sistema?
Bus factor, o qué pasa si desaparece una persona
En el mundo IT existe el concepto de bus factor. Simplificando, significa el número de personas cuya indisponibilidad puede hacer que el equipo deje de ser capaz de desarrollar o mantener el proyecto con eficacia.
No se trata, por supuesto, de un hecho literal. Es una forma de pensar sobre la concentración del conocimiento.
Si solo una persona sabe cómo funciona una integración crítica, el bus factor de ese conocimiento es uno.
Si solo un administrador tiene acceso a producción, el bus factor es uno.
Si solo una persona sabe por qué el sistema ejecuta un proceso determinado cada noche, el bus factor puede ser uno.
Si la empresa colabora con una software house externa y, por parte del cliente, nadie entiende la arquitectura de la solución, surge un problema aún mayor: el conocimiento puede estar fuera de la organización.
Eso no significa que cada empresa tenga que contar con cinco expertos en cada fragmento del sistema.
Se trata de algo mucho más simple: la empresa debería saber dónde está el conocimiento crítico y si puede recuperarlo sin una persona concreta.
El código dice cómo. No siempre dice por qué.
Un programador puede leer el código y entender qué hace una función determinada.
Sin embargo, no siempre sabrá por qué se escribió exactamente de esa manera.
Es una diferencia enorme.
Se puede encontrar el fragmento responsable de enviar datos a un sistema externo. Se puede analizar el endpoint, los parámetros, la autorización y el manejo de errores.
Pero el código no necesariamente responderá a las preguntas:
- ¿Por qué enviamos los datos a las 2:00 de la madrugada?
- ¿Por qué se omite este estado concreto?
- ¿Por qué, tras un error, el sistema reintenta exactamente tres veces?
- ¿Por qué un valor se recalcula antes de enviarse?
- ¿Por qué no se puede cambiar el orden de estas operaciones?
- ¿Por qué esta integración usa una cuenta concreta?
La respuesta puede estar en el historial del proyecto, en un ticket antiguo, en un correo de hace seis años o, peor aún, exclusivamente en la memoria de la persona que ya no trabaja en la empresa.
Por eso una buena documentación no debería ser solo una instrucción de "qué hacer clic".
También debería guardar el contexto y las decisiones.
El mayor problema puede ser una integración de la que ya nadie se acuerda
Un sistema moderno casi nunca funciona de forma completamente autónoma.
Se conecta con un sistema ERP. CRM. Pasarela de pagos. Proveedor de SMS. Sistema de mensajería. API del socio. Servicio en la nube. Plataforma analítica. Sistema contable. Mecanismo de autorización.
Cada una de esas conexiones es parte de una cadena tecnológica.
Y cada parte de esa cadena puede tener su propio propietario, cuenta, clave API, certificado, contrato, límite, versión de API y ciclo de vida.
Después de unos años, puede que nadie recuerde ya quién creó esa cuenta.
Y entonces basta con que caduque el certificado o cambie la API para que el sistema deje de funcionar.
Peor aún si la empresa ni siquiera sabe que existe esa dependencia.
Por eso, en un enfoque maduro de los sistemas, cada vez cobra más importancia la procedencia del software, la gestión de dependencias y la transparencia de la cadena de suministro del software. NIST, en sus materiales actuales sobre seguridad de la cadena de suministro, señala entre otras cosas la importancia de la información sobre los componentes, su origen, su ciclo de vida y sus dependencias. SBOM, es decir, Software Bill of Materials, es una de las herramientas que permiten organizar el conocimiento sobre de qué componentes se compone el software.
Esto ya no es solo un tema para el equipo de seguridad.
También es un tema para la dirección.
Porque si la empresa no sabe de qué está construido su sistema, le resulta más difícil evaluar el riesgo, el coste de mantenimiento y las consecuencias de los cambios.
La documentación no es un coste. Es una póliza.
En muchas empresas la documentación se trata como algo que "se hará más tarde".
Primero la funcionalidad.
Luego la implantación.
Luego las correcciones.
Luego el siguiente proyecto.
¿Y la documentación?
"Cuando haya tiempo."
El problema es que el tiempo para documentar suele aparecer justo cuando ya es demasiado tarde.
La documentación debería funcionar como un seguro empresarial. No porque alguien la vaya a leer todos los días. Al contrario: ojalá haga falta lo menos posible en una situación de emergencia.
Pero cuando surja un problema, la empresa debería poder responder a preguntas básicas:
- ¿Cómo funciona el sistema?
- ¿De qué se compone?
- ¿Dónde está el entorno de producción?
- ¿Quién tiene acceso?
- ¿Cuáles son las integraciones críticas?
- ¿Qué cuentas y servicios externos se utilizan?
- ¿Cuáles son las dependencias?
- ¿Cómo se realizan las copias de seguridad?
- ¿Cómo es el proceso de despliegue?
- ¿Qué ocurre durante una avería?
- ¿Qué elementos son críticos para el negocio?
- ¿Por qué se tomaron las decisiones arquitectónicas clave?
- ¿Quién puede hacerse cargo del mantenimiento del sistema?
Eso no tiene por qué significar cientos de páginas de documentación.
Una buena documentación debe ser ante todo útil, actualizada y accesible para las personas adecuadas.
"No toquemos nada porque funciona" no siempre es una mala decisión
Hay otro problema muy frecuente.
El sistema funciona desde hace años, así que la empresa adopta la regla: "No lo tocamos. Funciona."
Y a veces eso es absolutamente razonable.
No toda tecnología antigua requiere una sustitución inmediata. No todo fragmento de código antiguo hay que reescribirlo. No toda biblioteca significa una catástrofe. No toda arquitectura de hace unos años es incorrecta.
El problema empieza cuando "no toquemos nada" también significa:
- "No analicemos."
- "No documentemos."
- "No verifiquemos las dependencias."
- "No preguntemos quién tiene acceso."
- "No comprobemos si aún tenemos todas las cuentas."
- "No definamos qué pasará cuando el contratista actual deje de estar disponible."
Entonces la falta de cambios no es una estrategia.
Es aplazar el riesgo.
A veces la mejor decisión técnica es realmente no reconstruir nada.
Pero esa decisión debería surgir del conocimiento del sistema, y no de la falta de conocimiento sobre el sistema.
¿Qué debería incluir una auditoría de un sistema heredado?
Cuando una empresa asume un sistema tras otro software house, un freelancer o un equipo interno, el primer paso no debería ser reescribirlo todo automáticamente.
Primero hay que entender qué se ha asumido exactamente.
La auditoría debería responder al menos a algunas áreas básicas.
Arquitectura. ¿Cómo está construido el sistema? ¿Cuáles son sus componentes principales? ¿Dónde se encuentran los datos? ¿Cómo se comunican los distintos elementos?
Código y repositorios. ¿La empresa dispone del código fuente completo? ¿Se sabe qué rama y versión están en producción? ¿Se puede reproducir el proceso de compilación y despliegue?
Infraestructura. ¿Dónde funciona la producción? ¿Cómo es el entorno de pruebas? ¿Quién tiene acceso? ¿Cómo son la monitorización y las copias de seguridad?
Integraciones. ¿Con qué se comunica el sistema? ¿Qué API utiliza? ¿Quién es el propietario de cada cuenta y clave?
Dependencias. ¿Qué bibliotecas, frameworks y componentes externos se utilizan? ¿Se actualizan? ¿Tienen problemas de seguridad conocidos? ¿Cómo es su ciclo de vida?
Proceso de despliegue. ¿Es capaz una persona nueva de preparar, probar y desplegar un cambio sin llamar al antiguo programador?
Conocimiento. ¿Qué hay en la documentación y qué sigue existiendo solo en la cabeza de la gente?
Riesgo empresarial. ¿Qué ocurre si un componente concreto deja de funcionar durante una hora, un día o una semana?
El enfoque contemporáneo sobre la seguridad de la cadena de suministro del software subraya cada vez más precisamente la necesidad de conocer los componentes, los proveedores, las dependencias, su procedencia y su ciclo de vida. NIST también señala la importancia de la diligencia debida con respecto a los proveedores de tecnología y de evaluar la resiliencia y el riesgo asociados a toda la cadena de suministro.
Una auditoría no significa "reescribamos el sistema desde cero"
Esto es importante porque una auditoría técnica a menudo se confunde erróneamente con una reconstrucción.
Mientras tanto, la auditoría puede terminar con una conclusión muy simple: "El sistema está bien. Solo hay que ordenar el conocimiento y eliminar algunos riesgos."
También puede resultar que el sistema solo necesite modernización en un área.
O que el mayor problema no sea el código, sino la falta de acceso a la infraestructura.
O que la aplicación esté bien escrita, pero nadie tenga conocimiento actualizado del proceso de despliegue.
O que todo funcione, pero la empresa dependa de un único proveedor externo.
Por eso un buen análisis de un proyecto heredado debería responder a la pregunta: "¿Qué hay que cambiar realmente y qué no hace falta tocar?"
Solo entonces se pueden tomar decisiones de inversión.
¿Y si cambias de software house?
Este es uno de los momentos en que sale a la luz el problema de la deuda de conocimiento invisible.
La empresa finaliza la colaboración con el proveedor.
El nuevo socio recibe el repositorio.
Y empieza a hacer preguntas:
- "¿Dónde está la producción?"
- "¿Cómo arranco el proyecto localmente?"
- "¿Qué versión es la actual?"
- "¿Para qué sirve este servicio?"
- "¿Quién posee la cuenta de esta API?"
- "¿Qué hace este cron?"
- "¿Por qué se ejecuta este proceso a esa hora?"
- "¿De dónde sacamos este parámetro?"
- "¿Qué pasará si lo desactivamos?"
Si la respuesta a la mayoría de las preguntas es "no lo sabemos", el nuevo software house no asume el proyecto. Primero tiene que descubrirlo.
Y descubrir el sistema cuesta tiempo. Tiempo que luego paga el cliente.
Por eso la transferencia de un proyecto entre equipos debería ser un proceso, y no simplemente lanzar un ZIP con el código y la contraseña de una cuenta.
El sistema debe sobrevivir a las personas
Probablemente esa es la regla más importante.
Las personas cambian. Los programadores cambian de trabajo. Los freelancers terminan la colaboración. Los software houses cambian de clientes. Los administradores se van a otras empresas. Las direcciones cambian.
El sistema permanece.
Por eso el sistema debe estar diseñado de manera que el conocimiento necesario para su mantenimiento pueda recuperarse.
Esto no significa que cada empleado tenga que saberlo todo.
Significa que la organización debe contar con un mecanismo para almacenar el conocimiento:
- Repositorios.
- Documentación.
- Registro de integraciones.
- Información sobre la infraestructura.
- Accesos gestionados por la empresa.
- Descripción de los procesos clave.
- Historial de decisiones importantes.
- Información sobre dependencias.
- Procedimientos de emergencia.
- Y sobre todo, personas que sepan utilizar esa documentación.
NIST, en las directrices actuales sobre la planificación de la seguridad de los sistemas, también destaca la definición formal de responsabilidades, del estado operativo del sistema y de los roles de las personas que lo gestionan, lo soportan o tienen acceso a él.
Esto muestra un cambio más amplio en la forma de pensar sobre la tecnología.
El sistema no es solo código. El sistema también es personas, procesos, infraestructura, dependencias, datos, acceso y responsabilidad.
En Web24 a menudo empezamos precisamente con la pregunta: "¿Qué tenemos aquí exactamente?"
La toma de control de un proyecto existente no debería empezar con la promesa de que todo se volverá a escribir desde cero.
Debería empezar por entender la situación:
- ¿Qué funciona?
- ¿Qué no funciona?
- ¿Qué es crítico?
- ¿Qué está obsoleto?
- ¿Dónde están los mayores riesgos?
- ¿Qué falta en la documentación?
- ¿Qué dependencias son invisibles?
- ¿Se puede desarrollar de forma segura el sistema existente?
- ¿Hace falta una modernización o solo poner orden?
Solo entonces se puede decidir si el proyecto debe desarrollarse, reconstruirse, reescribirse parcialmente o simplemente documentarse bien.
Esto es especialmente importante en proyectos que durante años han sido desarrollados por distintas personas y distintas empresas.
Porque un buen socio tecnológico no debería hacer falta solo porque solo él sabe cómo funciona el sistema.
Debería hacer falta porque sabe desarrollar, asegurar y transmitir ese sistema a otras personas.
El error más peligroso puede ser la persona que ya se fue
No siempre el problema es el código antiguo.
No siempre el problema es la tecnología obsoleta.
No siempre el problema es la falta del framework más nuevo.
A veces el mayor riesgo es una información que nadie escribió.
Una sola palabra clave.
Una sola decisión arquitectónica.
Una sola integración.
Una sola excepción en el proceso.
Una sola persona que durante años sabía cómo funcionaba.
Y luego se fue.
Por eso vale la pena hacerse hoy una pregunta muy simple: Si mañana desapareciera de la empresa la persona que mejor conoce vuestro sistema, ¿seguiríais siendo capaces de gestionarlo?
Si la respuesta es "sí", genial.
Si es "no lo sé", vale la pena comprobarlo.
Y si es "definitivamente no", probablemente acabáis de encontrar una de las áreas más importantes de riesgo tecnológico en vuestra empresa.
El sistema debe ser más grande que la memoria de una sola persona.
