¿Cómo justificar ante el negocio la transformación del legacy?

Pocos son los mercados que no se han visto alterados por la transformación digital. Ahora, todo va mucho más rápido, cualquier unidad de negocio tiene acceso sencillo a la tecnología y han surgido multitud de empresas pequeñas, ágiles, capaces de impactar en el mercado. El negocio exige más velocidad y adaptabilidad al CIO, mientras que se reduce la inversión y el OPEX en las áreas de sistemas.

En ese contexto, los departamentos de sistemas y desarrollo, en muchos casos, no están bien posicionados. Se ven obligados a mantener unos sistemas pesados, con muchas horas de desarrollo invertidas, difíciles de adaptar, con usabilidad muy mejorable y con una estructura de costes poco competitiva. En definitiva, las unidades de negocio no están satisfechas con sus áreas de sistemas.

Cabría preguntarse qué es lo que ocurre dentro de esos sistemas ¿Por qué el evolutivo tarda tanto en liberarse desde que se identifica la necesidad? ¿Por qué suele haber fallos tras un pase a producción, cuando en las webs de internet no? ¿Por qué tienen que parar durante un fin de semana cuando hacen cambios? No existe una única respuesta para todas estas preguntas, aunque sí existe una variedad de antipatrones, que son la causa de esas consecuencias cuando se encuentran combinados en un mismo legacy.

Algunos ejemplos de antipatrones

Muchos equipos desarrollando sobre un mismo código

El equipo del proyecto X aportando evolutivos, además de los evolutivos que aporta el equipo del proyecto Y. Por otro lado, está el equipo de producción remediando problemas y comiteando correctivos. No nos podemos olvidar del equipo de rendimiento que también aporta cambios al código del sistema.

Tanto equipo adaptando en paralelo el mismo código es un antipatrón que genera costes ocultos derivados de las colisiones, de la necesidad de orquestación, de que cada equipo persigue objetivos distintos o de otras tantas razones.

Falta de cohesión en el código

La premura de las adaptaciones, la falta de conocimiento previo o la imposibilidad técnica de implementar ciertas funcionalidades llevan a los desarrolladores a tomar soluciones tácticas en el código que valen para el corto plazo, pero es necesario refactorizar si se quiere mantener el software limpio. Refactorizar es vital para la calidad de software, pero pocas veces se logra justificar, siempre prevalece la necesidad del negocio. Al final se genera un software difícil de adaptar por su fragilidad y complejidad.

Quauntum demasiado grande

Definimos quantum como la cantidad mínima que se debe desplegar en producción cuando se quiere promocionar un cambio. Cuanto mayor es el quantum, más difícil y más tiempo se tarda en hacer un pase a producción, más fallos puede haber, etc. Normalmente los sistemas heredados no han vigilado esto, no son modulares y adolecen de quantum muy grandes.

Falta de automatización y de pruebas automáticas

Muchos procesos manuales para hacer pruebas y para realizar los despliegues dan lugar a costes ocultos con cada pase a producción. Además, complican la gestión de entornos lo que, a su vez, lleva a otro antipatrón como es que varios equipos empleen el mismo entorno y, por lo tanto colisionen, lo que a su vez genera más costes ocultos.

Ahora bien, ¿cómo salimos de esta?

No es nada fácil. Existen acuerdos comerciales con fabricantes y con proveedores, existen maneras de hacer que se han mantenido durante mucho tiempo y que presentan fricción al cambio y técnicamente es complejo transformar un sistema mientras se atiende al día a día.

Ante un ambiente tan costumbrista es imprescindible que un agente externo, mientras que ocurre el día a día, se convierta en aliado de los equipos a cargo del legacy para transformarlo en un sistema más adaptable.

Por otro lado, todos sabemos que grandes proyectos de transformación tecnológica tardan mucho en materializarse y entrañan unos riesgos imposibles de asumir. Nadie cree que sea justificable una inversión multimillonaria para transformar tecnológicamente un sistema. Existe otra manera...

Desde Paradigma lo hemos hecho siempre aprovechando las necesidades del negocio. En lugar de pensar en cambiar la tecnología en un big bang, da mejor resultado romper el monolito en base a procesos de negocio, extraerlos a subsistemas dedicados.

Top-down, en lugar de bottom-up. Así, los procesos que han sido extraídos logran en el corto plazo mejorar su time to market, reducir el número de bugs, etc. Este gráfico muestra la evolución esperada:

Partimos de un modelo donde un solo código está evolucionado por varios equipos, con un quantum grande que soporta varios procesos de negocio. Queremos llegar a un modelo en el que los equipos se especializan por proceso de negocio, para ello paulatinamente se van extrayendo del monolito procesos a módulos dedicados.

El ciclo de vida de cada nuevo módulo es responsabilidad de un único equipo que hace todos sus evolutivos o correctivos. Este enfoque puede parece que necesita más equipos, pero esto se justifica con el ahorro al eliminar costes ocultos.

Se eliminan colisiones, hay más cohesión en el código, menos acoplamiento entre los módulos, más automatización de despliegues y pruebas... en definitiva, menos impedimentos, más certidumbre, concentración de la responsabilidad de cada módulo en un equipo, todo esto repercute finalmente en un mejor time to market y menos fallos.

Pero, ¿por dónde empezamos?

Antes de nada, pensemos en cuál es nuestra herramienta de separación del monolito en módulos. Tenemos dos técnicas posibles descritas en este diagrama:

Por otro lado, disponemos de estos principios para elaborar la estrategia de fragmentación:

• Es preferible extraer un proceso funcional que un proceso técnico. Ejemplos de proceso técnico son la gestión de sesiones o la gestión de autentificación.
• Busquemos los procesos de negocio que pueden significar una diferenciación en el mercado o una ventaja competitiva.
• Es mejor extraer un proceso que no genera dependencias hacia el legacy en lugar de uno que las genera.
• Si el proceso extraído genera dependencias hacia el legacy, se ha de estandarizar una interfaz para que terceros puedan consumir esa dependencia. Así se va ordenando también el monolito.
• Será mejor reescribir el proceso en la nueva tecnología y retirar los fragmentos de código del legacy que extraerlos para reutilizarlos.
• Cada extracción de un proceso no debe tardar más de 6 meses.

Aplicando estos principios sobre nuestro legacy podemos trazar una estrategia que lo convierta en un sistema más modular, más adaptable. Una estrategia cimentada sobre las necesidades del negocio como motor de la transformación y lograríamos que cada 6 meses el negocio disfrute de ventajas técnicas sobre sus procesos, priorizando los más acuciantes.

¿Estás dispuesto a intentarlo?