Después de una publicación en la que tratamos la transformación de los sistemas TI y cómo la modernización del CORE suele ser un elemento abordado tan solo superficialmente, pese a su importancia y criticidad, publicamos un segundo capítulo sobre las acciones de modernización tradicionales de los sistemas CORE. Ahora, damos fin a esta serie de artículos hablando de las dificultades que existen en estos procesos.
El principal reto cuando se afronta la transformación de un CORE es seleccionar los elementos candidatos. Para ello, es recomendable realizar un análisis detallado que nos permita obtener la siguiente información:
- Grado de retorno de transformación de la funcionalidad con respecto a otras. Por ejemplo: ahorro de costes en base al número de llamadas desde otros sistemas, involucración en el desarrollo de nuevas características y productos, retorno en términos de coste de oportunidad, etc.
- Otras funcionalidades impactadas dentro del sistema CORE y en sistemas externos
- Coste de implementación, incluidos los cambios a realizar en el CORE y en otros sistemas
- Coste de la convivencia de la funcionalidad transformada con la actual en el CORE, en caso de ser necesario
Respecto a las integraciones entre componentes del CORE, como de otros sistemas con éste, es fundamental también tipificar y analizar el mecanismo técnico empleado. Es completamente diferente llevar a cabo esta integración mediante una invocación remota a modo de servicio, aunque no se use una tecnología moderna, que realizar directamente el acceso a base de datos, lo que puede ser complicado de cara a desacoplar dichos sistemas.
Además, hay que prestar especial atención a procesos batch, tanto internos, como externos al sistema, pues habitualmente suelen acceder directamente a la base de datos del CORE.
Pero, en general, la mayor problemática de transformación es que su implementación no tiene una cohesión funcional, es decir, incluye muchas funcionalidades, pero el código, aunque pueda estar modularizado, suele encontrarse altamente acoplado. A esto se suma que, a menudo, se trata de sistemas donde los procesos y la base de datos se ejecutan como parte del mismo entorno, y no hay una separación clara del uso de cada entidad del modelo de datos.
Lecciones aprendidas y recomendaciones
La primera línea de acción de cara a la transformación de un sistema CORE es el desacoplamiento del frontend. Esto implica la creación de una capa de servicios independiente para la interacción online, componentes reutilizables entre aplicaciones y la conexión con el backend mediante APIs a través de un API Gateway. Otra de las líneas de trabajo es la relativa a ir segmentando el backend por dominios funcionales: agrupar y encapsular funciones, desarrollar microservicios, descomponer las aplicaciones en servicios y adaptar el modelo de datos para poder dividirlo entre datos CORE globales y datos propios de dominios. De forma complementaria, también se suele comenzar con la extracción de componentes especializados, que responden a funciones lógicas muy concretas y que no implican actividades excesivamente acopladas al resto de dominios del CORE. Así, como, de aplicaciones no críticas para el modelo de negocio, de propósito funcional propio, que no están en camino critico del modelo operativo.
Además, como se ha comentado previamente, es imprescindible realizar un análisis exhaustivo de impacto de cara a valorar la viabilidad y priorización de cada funcionalidad a transformar del CORE.
También se recomienda:
- Asegurarse que se tiene el conocimiento funcional del modulo que se va a refactorizar
- Empezar por extraer funcionalidades que puedan ser utilizadas por sistemas externos al CORE en modo de consulta, aunque se siga inicialmente manteniendo la interfaz para inserciones y actualizaciones
- Mantener un periodo de coexistencia entre la funcionalidad fuera y dentro del CORE e implementar mecanismos que validen que la información es coherente
- Intentar que el periodo de coexistencia, casi siempre inevitable, sea el menos posible, no solo por los costes asociados, sino porque se corre el riesgo que se mantenga indefinidamente y se convierta en algo estructural
- Segmentar el backend, del que habitualmente forma parte el CORE, y realizar la transformación de éste con un enfoque por dominios funcionales
- Priorizar la separación de componentes muy especializados, pues suelen ser los que mayor retorno proporcionan, valorando siempre el grado de acople interno que puedan tener
Por último, es importante empezar el proceso de transformación por aplicaciones no criticas para el modelo de negocio, para ir ganando experiencia. En algunos casos, incluso las acciones de modernización pueden ser suficientes para cubrir las necesidades de transformación digital de una compañía. En general, este proceso se suele abordar de forma iterativa, porque una reimplementación total del CORE puede ser costosa y larga.
En cuanto al roadmap de migración de una funcionalidad de un sistema CORE, recomendamos seguir una serie de pasos. Aunque, por la complejidad de este tipo de procesos, este esquema no debe de verse como un método de carácter general, pues cada caso puede requerir un enfoque particular.
En primer lugar, es necesario seleccionar un dominio o subdominio candidato a ser extraído del CORE; rediseñar, reorganizar y crear un nuevo modelo de datos compatible con la división por dominios funcionales y lógica de negocio; y crear un gateway que reciba la información del CORE y la guarde en el nuevo sistema de datos. En segundo lugar, y antes de abordar la creación de los servicios que ofrece la nueva implementación, es conveniente comprobar la integridad de los datos almacenados en el nuevo esquema. Después habrá que modificar el gatewaypara que pueda grabar en el CORE, en el caso de ser necesario, recibiendo los datos a insertar en el nuevo modelo y crear servicios que accedan a éste. Por último, se realizaran las adaptaciones de los sistemas que accedan a esta funcionalidad para que pasen a consumir de forma progresiva, por ejemplo, con una estrategia blue/green, los servicios del nuevo sistema. De esta forma, una vez desarrollada y validada cada funcionalidad, y no queden mas consumidores de ésta que accedan al CORE, se puede dar por finalizada su migración.
El mayor riesgo, no obstante, continúa siendo ignorar esta transformación. A menudo, los cambios que se deben realizar en las funcionalidades del CORE son mayores que los que su evolución natural puede permitir, de modo que puede ser el causante de retrasos en el desarrollo de nuevos servicios y productos digitales, lo que sí que supone un impacto costoso y largo.