Una de las más diferenciales características del software frente a los productos físicos tradicionales, es su capacidad de ser configurado, programado y, por tanto la posibilidad de adaptarlo a casi cualquier circunstancia o necesidad.
Esa característica del software se transmite a las organizaciones que lo utilizan intensamente, convirtiéndolas en organizaciones más ágiles, más preparadas para el cambio. Sin embargo, en algunas ocasiones esto puede no ser así. En algunas ocasiones el software puede actuar como freno.
¿Por qué?
Pues porque a medida que el software se convierte en columna vertebral de la operación de una compañía, tiende a hacerse más grande y complejo y la empresa mucho más dependiente en todos sus aspectos del funcionamiento de ese software.
Y empieza, por tanto, la dificultad para la modificación, no tanto por la naturaleza del software en si, que sigue siendo maleable, sino por las implicaciones de todo tipo para la empresa y por las dificultades de la gestión del proyecto de cambio.
La organización, pues, queda presa, anclada de alguna manera a ese software.
Así nos lo recuerda Renato Bellu en su libro ‘Microsoft Dynamics 365 for dummies‘, hablando de los ERP:
ERP tends to become entrenched in organizations because, once it is established, migrating to a different solution is often expensive, time-consuming, and fraught with peril. Therefore ERP is considered an anchor application.
Los ERP, en efecto, son de ese tipo de aplicaciones ancla que, tanto por la amplitud de su alcance funcional, como por el hecho de gestionar el ‘núcleo duro’ de la actividad empresarial, tienden a establecerse casi como una parte constituyente de la empresa y, por tanto, difíciles de cambiar. A eso se añade, además, el hecho de tratarse de productos cerrados, propiedad de fabricantes transversales, y con sus propias políticas y planes de versiones, no siempre cercanas a las necesidades de sus empresas usuarias.
¿Qué se puede hacer?
No cabe duda de que cuando un software se hace complejo y nuclear para la organización, siempre va a ser algo más difícil de modificar, pero algunos elementos nos pueden ayudar.
Hay quien aboga o ve como tendencia, por ejemplo, la vuelta al desarrollo personalizado, en lugar del uso de grandes productos comerciales, de manera que la empresa sea dueña de la evolución de su propio software. No necesariamente esto es la mejor opción, pero es una posibilidad.
El diseño ‘componentizado’, es decir, con módulos claramente diferenciados e independientes ayuda también a la facilidad de modificación. En esa tendencia se mueve desde hace ya unos cuantos años la filosofía SOA hoy en día reforzada con el concepto de los microservicios.
También corre a favor de obra la tendencia ‘low-code‘ es decir, soluciones dotadas de herramientas gráficas de desarrollo que reducen mucho la necesidad de la programación tradicional y de conocimientos informáticos avanzados.
La adopción de modos de trabajo agile y DevOps, aunque no siempre fáciles de poner en marcha, especialmente la segunda, también corren en la dirección de la agilidad y sobre todo, de la capacidad de adaptación.
No creo que haya una receta mágica. A pesar de la maleabilidad del software, la modificación de aplicaciones nucleares complejas siempre será un proyecto de una cierta dificultad. Pero una arquitectura técnica y funcional limpia, a ser posible basada en una arquitectura empresarial definida, unida a algunas de las características mencionadas más arriba, pueden aliviar algo las dificultades.
