Como parte de la transformación digital que han abordado durante los últimos años las compañías, es necesario considerar también los sistemas CORE. Se trata de un punto relevante, pero a menudo olvidado, de cara a realizar una transformación completa que permita cubrir las necesidades que implica el desarrollo de los nuevos negocios digitales.
Si revisamos el proceso de transformación de los sistemas de TI, vemos que, habitualmente, se ha comenzado por los elementos más cercanos a la interacción con los clientes. Esto es así porque la propia transformación digital, desde un punto de vista de negocio, implica el desarrollo (o modernización) de nuevos canales de venta de servicios y productos, y porque es más sencillo transformar las capas de frontend, e incluso de middleware, que la capa de backend.
Sin embargo, como es bien sabido, la digitalización de las compañías va más allá del uso de nuevas tecnologías e implica cambios a nivel metodológico, organizativo y de arquitectura. Esto pone foco sobre la necesidad de plantearse también que los sistemas CORE sean parte de este proceso de transformación.
Índice de temas
Frenos y retos de la transformación
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 a través de APIs en un API Gateway. A continuación, será necesario segmentar el backend por dominios funcionales: agrupar y encapsular funciones, desarrollar microservicios, descomponer las aplicaciones en servicios y adaptar el modelo de datos para poder segmentarlo entre datos CORE globales y datos propios de dominios. Finalmente, se separarán componentes especializados y, por último, las aplicaciones no críticas para el modelo de negocio.
El principal reto es seleccionar las funcionalidades candidatas. Para ello, es recomendable realizar análisis de impacto exhaustivo de cara a valorar la viabilidad y priorización de cada elemento a transformar. Dicho estudio nos permitirá conocer el grado de retorno de transformación de la funcionalidad respecto a otras (por ejemplo, ahorro de costes en función del numero de llamadas desde otros sistemas); el coste de implementación de la funcionalidad transformada fuera del CORE; el coste de la convivencia con la actual; y otros aspectos impactados dentro del sistema CORE y en sistemas externos.
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.
Pero, en general, la mayor problemática de transformación de los sistemas CORE es que su implementación no tiene una cohesión funcional, es decir, incluye muchas funcionalidades, pero el código, aunque modularizado suele estar altamente acoplado. A esto se suma que, a menudo, se trata de sistemas donde los procesos y la base de datos se ejecutan dentro del mismo hardware, por lo que no hay una separación clara del código que utiliza cada entidad de la base de datos.
¿Por qué ahora?
Las principales razones que llevan a las organizaciones a mirar hacia sus CORE y plantearse una posible transformación son: la reducción de costes (con los cambios de hábitos de los clientes, el número de llamadas a los sistemas CORE se ha visto aumentado, aunque no necesariamente el beneficio obtenido); la reducción de riesgos operativos de arquitecturas y tecnologías obsoletas de las que cada vez hay cada vez menos recursos; reducción del time to market (que suele implicar cambios a todos los niveles, tanto organizativos, como metodológicos y tecnológicos, así como de los sistemas legados); y para facilitar la adopción de nuevas arquitecturas que permitan la evolución de los sistemas de IT hacia arquitecturas orientadas a dominio, data hubs, o migración de los sistemas batch hacia arquitecturas de procesado en tiempo real, por citar algunos ejemplos.
Sin embargo, también hay motivos que han frenado esta transformación. Reimplementar un sistema de la criticidad y peso, tanto a nivel funcional como operativo, del CORE, es una tarea extremadamente compleja, y no siempre rentable si sólo se mira desde un punto de vista de ahorro de costes. Además, este proceso de transformación suele ser largo, e incluso puede haber funcionalidades donde realmente no compense la migración. De hecho, muchas compañías suelen empezar por realizar acciones como la optimización del core y aplicación de técnicas DevOps, llevar a cabo un rehosting y/o apificación, antes de abordar planes más ambiciosos de transformación de sus sistemas CORE.
En algunos casos las acciones de modernización pueden ser suficientes para cubrir las necesidades de transformación digital de una compañía, pero en otros, es necesario una transformación total o parcial. En general, este proceso se suele abordar de forma iterativa, porque una reimplementación total del CORE puede ser costosa y larga.
No obstante, a menudo, el número de cambios que se necesitan realizar en las funcionalidades del CORE son mayores que la máxima cadencia de evolución, acciones de modernización incluidas, puede ofrecer. Hemos llegado a un punto en el que, el avance en estos aspectos periféricos ha hecho que, en muchas ocasiones sea el CORE el que retrasa significativamente el desarrollo de nuevos servicios y productos digitales, lo que también supone un impacto costoso y largo.
