Cuando nos planteamos la transformación de nuestros sistemas legacy hacia versiones más ágiles, debemos tener en cuenta el peso innegable de la ley de Murphy: “Si funciona, no lo toques”. Y lo cierto es que cuando hemos necesitado realizar modificaciones en esos sistemas monolíticos que se crearon hace 20, 30 o más años, frecuentemente basados sobre tecnologías obsoletas que se han ido virtualizando o encapsulando para salvar la obsolescencia del hardware, nuestro planteamiento ha sido: entrar, tocar lo mínimo indispensable, realizar el máximo de pruebas posibles y rogar a Dios que no existan efectos colaterales.

También es cierto que, en muchos casos, la escasa frecuencia de modificaciones exigidas por estas funciones desaconsejará abordar los costes y riesgos de su transformación en versiones más actualizadas y ágiles. Esto puede ocurrir, por ejemplo, en los sistemas de facturación, los cuales generalmente pueden resolver la incorporación o retirada de productos y servicios mediante tareas de configuración, sin necesidad de alterar el código fuente.

Sin embargo, existen momentos en los que una organización debe tomar la decisión estratégica de transformar sus modelos de trabajo, o de realizar una profunda renovación tecnológica, a pesar de que la rentabilidad económica no lo justifique. Y esos momentos impulsan la ejecución de migraciones de sistemas o adquisición de productos que los sustituyan. En el primer caso, será necesario realizar la fragmentación del sistema en piezas software de un tamaño menor, o incluso en microservicos, que puedan disfrutar de ciclos de vida más breves e independientes entre sí. ¿Cómo debemos abordar ese “despiece”, como irónicamente mostramos en la ilustración que encabeza este artículo?

Recientemente he podido visionar una conferencia de Cat Swetel en la que explica el modo en que una compañía de venta de entradas multicanal ha abordado este proceso partiendo de un sistema monolítico construido sobre VMS. Un aspecto interesante es que Swetel centra el secreto del éxito de esta transformación reside en que el proceso iterativo no se centra solo en la construcción misma de un nuevo sistema, sino que incluye revisitar como se tratan tres ejes, que coinciden a la perfección con los que propone la gestión por procesos tradicional:

  • Procesos: que la autora denomina práctica. La adopción de una metodología de trabajo es importante. Pero, como dice la Ley de Conway: “Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones”. De modo que es necesario añadir para nuestro cuadro de mandos los indicadores y métricas que reflejen el grado de avance en la adopción de la cultura Agile para evitar que la inercia nos devuelva a las actitudes y modos de hacer que queríamos transformar en el punto de partida.
  • Herramientas: que denomina materiales. Una de las cosas que siempre me han gustado de Kanban es la oportunidad de comenzar a trabajar desde un modelo muy simple (To Do, Doing, Done), y sin más herramienta que una superficie y un taco de Post-it. Las herramientas son un medio, nunca un fin. Pero son un medio de una utilidad extraordinaria, si somos capaces de aprovechar la oportunidad que nos ofrecen de cambiar el “esto nosotros lo hacemos de otra manera” para adaptarnos al modo de trabajo de la herramienta, que frecuentemente ha demostrado ser exitoso y estar alineado con las metodologías y marcos. Y manteniendo la exigencia de evaluar periódicamente si hemos elegido la herramienta adecuada. Y si no es así, tener la libertad y capacidad de decisión absolutas para reemplazarlas.
  • Personas: que denomina significado. Se centra en la necesidad no solamente de que todo el personal que interviene en el proceso esté adecuadamente formado y motivado para realizar la transformación. Sino de que además se reenfoque de forma periódica la visibilidad de los objetivos de la transformación, de manera que sea posible garantizar el alineamiento de todo el equipo con la misión de la transformación.

La toma de decisiones estratégicas y técnicas sobre cómo dar sentido a los módulos o piezas de software resultantes, la transformación del ciclo de vida del software, la construcción de pruebas, su ejecución y el control de los resultados y control de calidad o las herramientas y lenguajes de programación a utilizar en todo el proceso son cuestiones fundamentales. Pero incluso si tuviéramos todas esas preguntas técnicas contestadas, y si todos los recursos materiales y técnicos estuvieran a nuestra disposición, con todo el personal adecuadamente formado en cada una de las tecnologías y metodologías necesarias, nos faltaría todavía un elemento clave que está detrás de esta y otras muchas iniciativas de transformación: la necesidad de realizar un análisis crítico iterativo que nos permita garantizar el éxito a largo plazo de nuestro viaje hacia al Agilidad Empresarial.

 

Imagen: OCU.org