La narrativa predominante siempre trató la arquitectura híbrida como un estado intermedio. El mainframe seguiría siendo responsable de los sistemas críticos mientras las aplicaciones y los datos se trasladaban gradualmente a la nube, hasta culminar en una arquitectura más simple y concentrada en plataformas consideradas modernas.
Los movimientos recientes del mercado ponen en duda esta interpretación.
El modelo híbrido ya es dominante entre las organizaciones y, al mismo tiempo, muchas de ellas han aumentado el uso del mainframe. Las empresas están obteniendo retorno financiero con las tres estrategias analizadas: modernizar en el mainframe, integrar el mainframe con otras plataformas y migrar workloads seleccionados.
Para muchas empresas, mainframe + cloud puede dejar de ser una arquitectura provisional y convertirse en el diseño más racional para el negocio.
En lugar de invalidar los proyectos de migración, la premisa pasa a ser reconocer que determinadas cargas siguen teniendo sentido en el mainframe, mientras que otras pertenecen a la nube, a plataformas de datos o a aplicaciones distribuidas.
Sin embargo, si este entorno híbrido es permanente, surge una cuestión más difícil que simplemente conectar tecnologías: ¿cómo operar procesos de negocio que atraviesan todas ellas?
El problema ya no es lograr que los sistemas se comuniquen
La primera generación de iniciativas híbridas concentró gran parte de sus esfuerzos en la conectividad. Era necesario exponer aplicaciones, habilitar APIs, crear integraciones y permitir que sistemas ejecutados en diferentes plataformas intercambiaran datos.
Este trabajo sigue siendo necesario, pero ya no resuelve por sí solo el problema operativo.
Una transacción iniciada en una aplicación puede depender de un procesamiento en el mainframe, activar un servicio en la nube, alimentar una plataforma de datos y, posteriormente, desencadenar otro proceso en un sistema corporativo.
Cada componente puede funcionar perfectamente de manera aislada y, aun así, el proceso completo puede fallar debido a una dependencia no ejecutada, un orden incorrecto, un retraso o una transferencia de datos interrumpida.
Por eso, a medida que la arquitectura se vuelve híbrida, la unidad operativa deja de ser únicamente el sistema y pasa a ser el workflow que atraviesa múltiples sistemas.
Un proceso de cierre financiero, por ejemplo, puede comenzar en aplicaciones distribuidas, depender de jobs en z/OS, transferir archivos, ejecutar transformaciones en la nube y finalizar en una plataforma analítica.
Una rutina de procesamiento de datos puede combinar aplicaciones on-premises con servicios de AWS, Azure o Google Cloud. En ambos casos, la disponibilidad individual de cada plataforma dice poco sobre la capacidad del proceso para finalizar dentro del SLA.
El desafío pasa a ser garantizar que todas esas dependencias funcionen como una sola operación.
El modelo híbrido aumenta la flexibilidad y también las dependencias
La principal ventaja de una arquitectura híbrida es que no obliga a todas las aplicaciones a encajar en un mismo modelo tecnológico. Cada workload puede permanecer o desarrollarse allí donde sus características de rendimiento, costo, seguridad, proximidad a los datos y velocidad de evolución tengan mayor sentido.
Sin embargo, esa libertad genera una mayor cantidad de relaciones entre plataformas.
El problema aparece cuando cada entorno también mantiene su propia lógica de automatización. El mainframe tiene un scheduler. La nube utiliza otro mecanismo. La plataforma de datos cuenta con su propio workflow. Un área de negocio controla otra parte del proceso.
Poco a poco, un servicio que parece único para el usuario pasa a depender de varias cadenas independientes. La arquitectura está integrada, pero la ejecución sigue fragmentada.
Esta es una de las razones por las que el debate sobre automatización está evolucionando hacia la orquestación. Automatizar una actividad significa permitir que se ejecute sin intervención manual. Orquestar significa coordinar diferentes actividades, dependencias y plataformas para que el proceso completo se ejecute en la secuencia necesaria.
La distinción es relevante en entornos híbridos porque el problema rara vez está en un único job. Está en lo que debe ocurrir antes y después de él.
Es precisamente para cubrir esta brecha que BMC posiciona Control-M.
La plataforma fue desarrollada para orquestar workflows de aplicaciones y datos en entornos heterogéneos. En el contexto de mainframe, BMC destaca la posibilidad de conectar jobs nativos de la plataforma con procesos distribuidos y en la nube, administrando esas dependencias desde una visión unificada.
El producto también ofrece gestión de SLA, automatización de recuperación e integración entre z/OS y entornos como AWS y Azure.
La propuesta no consiste en retirar el procesamiento del mainframe, sino en permitir que participe del mismo flujo operativo que las demás plataformas.
Esto marca una diferencia porque, en muchas empresas, la modernización digital no sustituyó los procesos ejecutados en el mainframe; añadió nuevas etapas a su alrededor. Aplicaciones móviles, APIs, servicios en la nube, plataformas analíticas y nuevos canales comenzaron a consumir o producir información asociada al core.
Por lo tanto, el workflow de negocio se volvió más amplio que cualquiera de las plataformas que lo ejecutan.
Control-M actúa precisamente en esa capa de coordinación. La solución es una plataforma de orquestación de aplicaciones y datos capaz de operar en entornos híbridos y multicloud e integrar diferentes fuentes de datos, aplicaciones y servicios cloud.
En lugar de mantener schedulers y mecanismos de control separados para cada entorno, la organización puede definir dependencias que atraviesan esas fronteras y acompañar la ejecución del proceso de punta a punta.
El SLA pertenece al proceso, no a la plataforma
Este cambio también transforma la manera de pensar la disponibilidad.
Imaginemos una rutina que debe estar finalizada antes de las 7:00 para que pueda comenzar una operación de negocio. Parte de ella se ejecuta en el mainframe. Otra etapa procesa datos en la nube. Después, una aplicación distribuida genera un resultado que alimenta un sistema corporativo.
Para el negocio, no importa que cada plataforma, individualmente, haya registrado una disponibilidad del 99,99 %. Lo que importa es si el proceso terminó antes de las 7:00.
Esta diferencia puede parecer obvia, pero las arquitecturas híbridas hacen que este tipo de seguimiento sea más complejo. Cuando cada etapa cuenta con sus propias herramientas, equipos y mecanismos de monitoreo, identificar dónde se detuvo el flujo puede exigir la correlación manual de información distribuida entre diferentes entornos.
Una capa de orquestación crea otra perspectiva: el objeto monitoreado deja de ser únicamente el job individual y pasa a incluir la cadena de actividades que entrega el servicio.
BMC destaca precisamente las capacidades de gestión de SLA y visualización end-to-end entre mainframe, aplicaciones híbridas y entornos multicloud de Control-M. La plataforma también ofrece integraciones con más de un centenar de servicios y tecnologías de nube, aplicaciones y datos.
Esto no elimina los incidentes, pero reduce la distancia entre un retraso técnico y la identificación de su impacto sobre el proceso de negocio.
Hay otro aspecto que suele subestimarse en esta discusión.
A medida que los equipos adoptan servicios cloud con mayor autonomía, aumenta la cantidad de tecnologías involucradas en los workflows. Los equipos de datos pueden utilizar Snowflake o Databricks. Los desarrolladores pueden activar funciones serverless. Las aplicaciones corporativas siguen dependiendo de SAP. El mainframe permanece en el centro de procesos críticos.
Sin una capa común de coordinación, la automatización tiende a crecer en silos.
Un equipo crea scripts. Otro utiliza el scheduler nativo de la plataforma. Un tercero construye sus propios pipelines. La suma de estas decisiones puede funcionar localmente, pero dificulta responder preguntas sencillas a escala empresarial:
¿Quién depende de quién?
¿Qué proceso está retrasado?
¿Qué SLA está en riesgo?
¿Quién puede modificar el workflow?
¿Qué se ejecutó y en qué orden?
Por eso, la orquestación no es solo una cuestión de conveniencia operativa. También crea condiciones para una mejor gobernanza.
Control-M ofrece una capa central para la definición, el seguimiento y el control de workflows, combinando capacidades de automatización, self-service, políticas de acceso, auditoría y visualización.
BMC posiciona esta capacidad como una forma de coordinar entornos complejos sin perder el control operativo a medida que las aplicaciones y los datos se distribuyen entre diferentes infraestructuras.
La idea resulta especialmente relevante para organizaciones en las que la autonomía de los equipos debe coexistir con altos requisitos de seguridad y confiabilidad.
Tal vez no exista una “plataforma de destino”
La propia evolución de las estrategias de modernización sugiere que muchas empresas están abandonando la idea de un único destino tecnológico.
En lugar de grandes migraciones lineales, las organizaciones están adoptando enfoques más graduales, combinando modernización en la propia plataforma, integración y migración selectiva. Este pragmatismo tiene una consecuencia arquitectónica.
Si diferentes workloads encuentran diferentes destinos, la arquitectura final tenderá a seguir siendo heterogénea.
La nube no desaparece. El mainframe tampoco. Las plataformas de datos, el SaaS y las aplicaciones distribuidas continúan incorporándose al entorno.
La cuestión estratégica deja de ser cómo llegar a una plataforma única y pasa a ser cómo operar un negocio que depende permanentemente de múltiples plataformas.
En este escenario, el modelo híbrido no representa necesariamente una modernización a medias. Puede ser precisamente el resultado de una decisión madura sobre dónde debe operar cada workload.
El próximo desafío es hacer que el entorno híbrido funcione como uno solo
La modernización del mainframe ya ha avanzado considerablemente en las discusiones sobre APIs, cloud, DevOps e integración. La siguiente etapa exige observar qué ocurre después de que esas conexiones han sido creadas.
Una transacción puede comenzar en el core y terminar en la nube. Un pipeline de datos puede atravesar diferentes plataformas. Una rutina crítica puede depender simultáneamente de aplicaciones antiguas y de servicios creados hace apenas unos meses.
Para el usuario y para el negocio, sin embargo, todo esto sigue siendo un único proceso.
Es en esta capa donde soluciones de orquestación como BMC Control-M, representado por Eccox, adquieren relevancia. El producto permite coordinar workflows de aplicaciones y datos entre mainframe, entornos distribuidos y cloud, manteniendo dependencias, visibilidad y gestión de SLA dentro de una misma lógica operativa.
Si la arquitectura híbrida dejó de ser una etapa temporal, la capacidad de operarla también debe dejar de ser improvisada.
El desafío ya no consiste únicamente en conectar mainframe y cloud. Consiste en garantizar que el proceso que depende de ambos siga funcionando como si la frontera entre ellos no existiera.
About Post Author
