Cómo convertir un sistema viejo en un problema nuevo

Una historia real sobre migraciones tecnológicas que no fueron realmente migraciones

Hace unos años, por allá en 2018, trabajaba como coordinador de desarrollo en una empresa que era asociada comercial de la ya extinta Electricaribe.

Mi trabajo era liderar al equipo de desarrollo y participar activamente en el proyecto principal de la empresa: migrar una aplicación “old school” a tecnologías más modernas.

O al menos eso era lo que todos pensaban que estaba pasando.

El sistema original

La aplicación original estaba desarrollada en Delphi y utilizaba Firebird como motor de base de datos.

Una combinación bastante popular en los años 90 y principios de los 2000.

Era un sistema enorme. Tenía cientos de tablas en la base de datos y una gran cantidad de funcionalidades. Durante todo el tiempo que trabajé en ese proyecto nunca logré conocer completamente todo lo que hacía la aplicación.

Era uno de esos sistemas que crecieron durante años hasta convertirse en el corazón operativo de la empresa.

En teoría, el objetivo era migrarlo a la web.

Pero al analizar el proyecto más de cerca, me di cuenta de algo importante:

Si realmente queríamos migrarlo correctamente, no se trataba de migrar.

Se trataba de reconstruirlo desde cero usando tecnologías modernas. Algo como una nueva arquitectura con PHP y MySQL, que en esa época estaban muy de moda.

Pero el mundo empresarial rara vez se mueve al ritmo ideal de la ingeniería de software.

Y ahí empezó el problema.

Una arquitectura que permitía una mala práctica

La arquitectura original del sistema era muy particular.

En la interfaz de usuario prácticamente no existía lógica de negocio.

Todo estaba en la base de datos.

Literalmente todo.

El corazón del sistema eran procedimientos almacenados en Firebird. Estos procedimientos realizaban:

• Transacciones
• Validaciones
• Cálculos
• Lógica de negocio completa

La interfaz Delphi simplemente llamaba a esos procedimientos y mostraba el resultado.

Este modelo de trabajo abrió la puerta a una idea que, en teoría, parecía brillante.

Y en la práctica… no tanto.

La “gran idea” de la migración

El plan era el siguiente:

Crear todos los formularios nuevamente usando:

• HTML
• jQuery
• CSS

Estos formularios usarían PHP para conectarse a la base de datos Firebird y ejecutar los mismos procedimientos almacenados que ya existían.

En otras palabras:

• La base de datos seguía igual
• Los procedimientos seguían igual
• La lógica de negocio seguía igual

Lo único que cambiaba era la interfaz.

La aplicación pasaba de Delphi a una interfaz web… pero todo lo demás seguía siendo exactamente lo mismo.

La idea aparentemente surgió de algunos de los programadores originales del sistema, quienes además ocupaban cargos directivos.

Y hay que admitir que, desde su perspectiva, tenía ventajas:

• Podían reutilizar los procedimientos existentes
• Mantenían control sobre el core del sistema
• El equipo nuevo solo construía las interfaces

Así, mientras nosotros desarrollábamos vistas web, el verdadero sistema seguía viviendo dentro de Firebird.

Cuando entré a la empresa, este modelo ya estaba bastante avanzado. Cambiar el enfoque en ese momento era prácticamente imposible.

Así que durante los siguientes dos años el proyecto continuó bajo ese mismo modelo.

La infraestructura fisica

Durante la inducción me explicaron que el sistema corría en servidores de AWS.

Estos servidores tenían:

• Windows Server
• Firebird
• El servidor PHP

Hasta ahí todo parecía razonable.

Pero luego descubrí algo curioso.

En la oficina había un portátil bastante viejo que funcionaba como servidor de pruebas.

El flujo de despliegue era algo así:

• Se desarrollaban los formularios
• Se subían al portátil por FTP
• Los jefes revisaban los cambios
• Si todo estaba bien, se subían al servidor de producción

También por FTP.

Pero la verdadera sorpresa llegó después.

El regreso al hardware físico

En algún momento la empresa decidió abandonar AWS.

La razón: costos y licencias.

La solución fue implementar servidores físicos dentro de la empresa.

Personalmente me gustan los servidores on-premise para aprender y experimentar. Pero mantenerlos en producción implica retos importantes:

• Seguridad
• Conectividad
• Energía eléctrica
• Mantenimiento físico

Y en ese momento Montería tenía problemas frecuentes tanto de electricidad como de internet.

No era exactamente el entorno ideal para alojar infraestructura crítica.

Lo que aprendí de todo esto

Tiempo después dejé la empresa y estos problemas aun estaban cuando eso.

La compañía sigue existiendo, está bien posicionada en el mercado y ha crecido bastante desde entonces. Es muy probable que hoy tengan mejores prácticas tecnológicas.

Pero esa experiencia me dejó una reflexión importante.

El mercado no espera a nadie.

Desde el punto de vista empresarial, muchas de las decisiones que se tomaron eran comprensibles. Los clientes no van a esperar meses o años mientras se diseña la solución perfecta.

Si una empresa no tiene lista la solución, los clientes buscarán otra que sí la tenga.

Por eso es tan importante que los proveedores de software pensemos siempre en el corto y mediano plazo.

No basta con resolver el problema inmediato.

Debemos construir soluciones que también puedan sostenerse en el tiempo.

La importancia de la arquitectura de software

Algo que también quedó muy claro durante esta experiencia fue la importancia de los arquitectos de software y arquitectos de soluciones dentro de los proyectos tecnológicos.

La infraestructura y el modelo de desarrollo que tenía este sistema muy probablemente fue pensado por programadores con buena intención, pero sin experiencia formal en arquitectura de software. Esto es algo bastante común en muchos proyectos: el sistema crece, se agregan funcionalidades y con el tiempo termina convirtiéndose en una estructura difícil de mantener.

Un arquitecto de software no solo piensa en que la aplicación funcione hoy, sino en cómo va a crecer, cómo se va a mantener y cómo se va a adaptar a nuevas tecnologías en el futuro.

Con una arquitectura bien diseñada, el flujo de trabajo del equipo de desarrollo suele ser mucho más claro y fluido. Las responsabilidades de cada componente están definidas, los cambios se pueden implementar con menos riesgo y las nuevas funcionalidades pueden integrarse sin afectar todo el sistema.

Además, una buena arquitectura permite que las aplicaciones sean mucho más escalables, mantenibles y sostenibles en el tiempo. En muchos casos, la diferencia entre un sistema que evoluciona con facilidad y uno que se vuelve un problema constante radica precisamente en las decisiones de arquitectura que se tomaron al inicio del proyecto.

Porque cambiar la interfaz puede hacer que un sistema parezca moderno.

Pero modernizar realmente un sistema significa algo mucho más profundo: cambiar su arquitectura.