Acciones de modernización en los sistemas CORE. Cap 2

por José Manuel López Doña - CTO Sopra Steria España
| minutos de lectura

En el primer capítulo de esta serie de artículos sobre la transformación de los sistemas TI, vimos cómo, a menudo, la modernización del CORE suele ser dejada de lado frente a la atención prestada a los canales de interacción con el cliente. No obstante, explicamos también que las ventajas superaban a los costes, de modo que las empresas podían consolidar la transformación a un nivel más profundo y, de este modo, garantizar su competitividad presente y futura.

A continuación, detallaremos cómo transformar o reimplementar un sistema de la criticidad y peso de un CORE. Sin embargo, como es un proceso largo y pueden existir funcionalidades donde realmente no compense la migración, muchas compañías suelen empezar por realizar acciones de modernización antes de abordar planes más ambiciosos:

  • Rehosting & replatforming: ayuda en la reducción de costes al poder ejecutar código legado en servidores de propósito general, tanto en infraestructura on-premise como en plataformas cloud públicas. Por este motivo, además de la posible reducción de costes, facilita la portabilidad de los entornos de ejecución de los sistemas CORE. Se puede abordar manteniendo la misma base de código fuente o traduciendo este a otro lenguaje que pueda ser ejecutado en sistemas abiertos, como, por ejemplo, Java.
  • Aplicación de técnicas DevOps para agilizar el desarrollo, pruebas y despliegue de software en sistemas legados. Compuware es uno de los fabricantes en el mercado que ofrece herramientas para abordar la agilización de sistemas mainframe.
  • APIficación: para mejorar la interoperabilidad de las funcionalidades que ofrece el CORE para ser integradas por otros sistemas, una acción habitual es la publicación de dichos servicios como APIs. Esto facilita la exposición, consumo y gobierno de los servicios.

De la modernización a la transformación 

En algunos casos, las acciones de modernización del CORE pueden ser suficiente para las necesidades de digitalización 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, ya que una reimplementación completa del CORE suele ser larga y costosa.

El principal motivo para transformar estos sistemas se da cuando el número de cambios que se necesita realizar en las funcionalidades de los mismos es mayor que la máxima cadencia de evolución, acciones de modernización incluidas, puede permitir. Lo habitual es centrarse en la evolución de los sistemas de TI que tienen mayor incidencia en el desarrollo de la “experiencia” de servicios y productos, asumiendo algunos cambios e integraciones con los sistemas CORE. Pero si estos son de mayor calado o causan retrasos significativos, tanto a nivel tecnológico u organizativo, como metodológico, es necesario plantearse la transformación de los elementos del CORE involucrados para incluirlos en una arquitectura más alineada con las necesidades de cambio del negocio.

Compromiso entre reutilización y autonomía

En cierta medida la disyuntiva que lleva actualmente a plantearse una transformación, más allá de lo relacionado con costes u obsolescencia, está relacionada con el cambio de paradigma en el enfoque de los sistemas de TI. En un inicio, se consolidaron arquitecturas donde prevalecía la reutilización sobre la autonomía. Esto llevó a que se popularizasen arquitecturas como SOA, donde la reutilización y composición de servicios es un pilar fundamental. Pero, en los últimos años, tanto por el abaratamiento de las infraestructuras y la facilidad de aprovisionamiento, en especial en plataformas cloud, como por una mayor competitividad (que empuja a reducir los tiempos de desarrollo y despliegue del software), el factor autonomía ha ganado peso. Fruto de esta tendencia, se ha popularizado el uso de arquitecturas de microservicios.

Como suele ser habitual, en el término medio esta la virtud, y se recomienda ir hacia arquitecturas orientadas a dominio, también es totalmente factible que parte de las funcionalidades de los actuales CORE tan solo se actualicen.

Motivos para la segmentación por dominios funcionales

Una de las razones comentadas para la transformación del CORE es la integración de forma orgánica en arquitecturas segmentadas por dominios funcionales, en contraposición con un enfoque de arquitectura tradicional dividida en capas. A modo de resumen, los principales motivos son:

  • Facilitar el diseño en base a quantum arquitectónicos, es decir, componentes desplegables de forma independiente y con una alta cohesión funcional, que incluya todos los elementos estructurales necesarios para que el sistema funcione correctamente. La principal motivación detrás de dividir un sistema así, es crear equipos independientes que puedan construir y operar el quantum, de forma que el trabajo sea paralelizado por estas personas para alcanzar una mayor escalabilidad y velocidad operativas.
  • Los enfoques tradicionales de evolución de plataformas CORE siguen segmentando el desarrollo en tres capas: canales, middleware y backend. Esta práctica es ineficiente, pues ninguna de estas se puede considerar un quantum arquitectural, y es una división artificial y sin capacidad operativa dentro del mismo dominio. Esto provoca fricciones respecto a las necesidades de cambio, al tiempo que limita la capacidad de evolución

En un enfoque de este tipo hay dominios ligados a procesos de negocio, dominios transversales y dominios de soporte. Es importante evitar que los transversales y de soporte condicionen el desarrollo y la evolución de los de negocio. Para ello es fundamental promover una cultura de autoservicio basada en plataformas, al tiempo que se despliega una correcta estrategia de apificación en la compañía para compartir recursos entre los diferentes dominios.

Sin embargo, no debemos caer en la estrategia de apificarlo todo, ya que puede acarrear más perjuicios que beneficios, por ejemplo, incumplir bases bien establecidas del desarrollo de software, como son los principios SOLID. 

Como, podemos ver, a la hora de abordar estos procesos, hemos de partir de tendencias con una base bien fundamentada. En el último artículo de esta serie, veremos los retos y dificultades que existen en la transformación de los sistemas CORE y cómo superarlos, además de las lecciones aprendidas en los proyectos realizados por Sopra Steria.

 

Search

sopra-steria-es

tecnología

Contenidos relacionados

Evolución de la cultura corporativa de Airbus

Desde Sopra Steria Next hemos colaborado con Airbus, multinacional del sector industrial referente en su ámbito de negocio, en la implantación de un nuevo modelo de cultura corporativa, participando en la definición y acompañamiento en la  implantación del mismo.

Ciclo de vida del producto digital de entidad bancaria

Sopra Steria y una entidad bancaria en España hemos acordado y definido un modelo de colaboración en el que dicha entidad nos delega la responsabilidad de construir y desplegar “features” completas. ¿Qué implica realmente esto?. Que Sopra Steria adquiera la responsabilidad plena de construcción de una interacción completa, con carácter trimestral, en calidad y productividad de la interacción de construcción del producto.

Plataforma del dato para toma de decisiones operativas en tiempo real de la Autoridad Portuaria Bahía de Algeciras

La Autoridad Portuaria Bahía de Algeciras (APBA) desea convertir la Transformación Digital y la Innovación en pilares indispensables de su estrategia de negocio para aumentar su competitividad, maximizar la creación de valor y consolidarse como plataforma logística intercontinental.