Sistemas de reservas aéreas: ¿Por qué siguen funcionando en mainframes?

Cuando reserves un vuelo con tu smartphone en 2026, tu solicitud pasará por múltiples capas de tecnología moderna: una aplicación móvil, un servicio web y un procesador de pagos, antes de llegar al sistema que realmente reserva tu asiento. Este sistema, en la mayoría de los casos, es un software con raíces en la década de 1960, que funciona sobre una infraestructura que la industria de viajes lleva décadas intentando reemplazar sin éxito. Sabre, Amadeus y Travelport gestionan prácticamente todas las reservas aéreas del mundo. Entre ellas procesan miles de millones de transacciones anuales a través de cientos de aerolíneas, miles de agencias de viajes e inventario en tiempo real que abarca millones de combinaciones de asientos. La más antigua de ellas tiene sus orígenes en un ordenador central IBM de 1964 que redujo los tiempos de reserva de 90 minutos a apenas segundos y cambió la aviación comercial para siempre.

La razón por la que estos sistemas permanecen donde están no es una cuestión de inercia organizacional ni de conservadurismo en ingeniería. Es una historia sobre lo que sucede cuando el software se integra tan profundamente en un proceso operativo crítico que el costo y el riesgo de reemplazarlo resultan injustificables en un plazo realista, y sobre cómo la industria ha respondido modernizando el núcleo en lugar de intentar reemplazarlo. Para quienes trabajan en la modernización a gran escala de sistemas heredados, los sistemas de reservas de las aerolíneas constituyen el ejemplo más claro de lo que significa en la práctica la expresión «demasiado importante para fallar».

El origen: Por qué los mainframes ganaron el problema de las aerolíneas.

El SABRE original (Semi-Automated Business Research Environment) no era un producto, sino una solución personalizada para una crisis operativa específica. A finales de la década de 1950, American Airlines crecía más rápido de lo que su sistema manual de reservas podía gestionar. Reservar un asiento requería una llamada telefónica, una comprobación manual de una ficha de inventario física, una espera, una devolución de llamada y un registro en papel; un proceso que duraba un promedio de 90 minutos por reserva y que no era escalable.

Cuando SABRE entró en pleno funcionamiento en 1964, basado en dos ordenadores centrales IBM 7090 y conectado a 1,500 terminales en Estados Unidos y Canadá, podía procesar 7,500 reservas por hora con una tasa de error prácticamente nula. Por primera vez, una aerolínea podía mantener un inventario de asientos en tiempo real, almacenar registros completos de pasajeros y permitir reservas instantáneas en toda su red. Los tiempos de reserva se redujeron de 90 minutos a segundos.

La elección arquitectónica que lo hizo posible, el procesamiento centralizado de transacciones en hardware de mainframe, no se basó en razones filosóficas. Se eligió porque era la única arquitectura disponible en 1964 que podía cumplir con los requisitos de latencia, fiabilidad y acceso concurrente de la gestión de inventario de aerolíneas en tiempo real. Y funcionó tan bien que se convirtió en el modelo arquitectónico sobre el que se construyeron todos los sistemas de reservas de aerolíneas posteriores.

La plataforma Transaction Processing Facility (TPF) de IBM, diseñada originalmente para SABRE, se convirtió en el entorno operativo de toda la categoría. Casi todos los bancos, aseguradoras, minoristas y aerolíneas más importantes aún la utilizan, según IBM. Cuando Amadeus se fundó en 1987, se basó en TPF. Cuando Galileo (ahora Travelport) lanzó su GDS, también se basó en TPF. Actualmente, tres generaciones de sistemas de servicio al pasajero coexisten en la aviación comercial, y muchos aún funcionan con mainframes TPF, no porque la tecnología nunca se haya puesto en duda, sino porque el rendimiento, la fiabilidad y la tolerancia a fallos que TPF ofrece en hardware de mainframe han demostrado ser realmente difíciles de replicar a una escala equivalente en arquitecturas alternativas.

Qué hacen realmente estos sistemas a gran escala.

La magnitud de los sistemas de reserva de las aerolíneas no es fácil de comprender intuitivamente desde la perspectiva de la ingeniería de software. Un sistema de distribución global no solo gestiona la disponibilidad de asientos, sino que también administra un problema de inventario combinatorio de una complejidad asombrosa.

Un solo vuelo transatlántico tiene cientos de clases tarifarias. Cada clase tarifaria tiene reglas específicas: requisitos de compra anticipada, estancia mínima, fechas restringidas, cargos por cambio, escalas permitidas o no, y acuerdos de código compartido con aerolíneas asociadas. Una reserva que involucre dos aerolíneas, una conexión y un viaje de ida y vuelta crea una matriz de miles de combinaciones tarifarias válidas que deben verificarse, calcularse y compararse con el inventario en tiempo real antes de obtener una respuesta, generalmente en menos de un segundo.

Durante los periodos de mayor demanda, Sabre y Amadeus procesan conjuntamente decenas de miles de transacciones por segundo. No por minuto, sino por segundo. Cada transacción implica la consulta de inventario en tiempo real, la evaluación de las reglas tarifarias, la creación o modificación del PNR (Registro de Nombre de Pasajero) y la coordinación con los sistemas de control de salidas, programas de viajero frecuente y servicios complementarios. El tiempo de respuesta garantizado se mide en milisegundos, ya que si un agente de viajes o un motor de reservas espera más de unos segundos para la verificación de la tarifa, se agotará el tiempo de espera y la transacción se reintentará o se cancelará.

El rendimiento de TPF en hardware de mainframe ofrece esta capacidad con una tasa de fallos que a los profesionales de TI de otros sectores les resulta difícil de creer. La tolerancia a fallos del mainframe, sus procesadores redundantes, sus componentes intercambiables en caliente y décadas de código de sistema operativo robusto, garantizan una disponibilidad del 99,999 % como parámetro operativo estándar, no como un objetivo ambicioso. Replicar esto a un coste equivalente en la infraestructura en la nube ha sido el principal reto técnico de todos los programas de modernización de TI de las aerolíneas que se han intentado desde la década de 1990.

Los intentos de modernización: lo que realmente revelaron los programas que duraron una década.

La historia de la modernización de los sistemas de reservas de las aerolíneas es una historia de programas que se propusieron reemplazar el sistema central y que, años después, llegaron a un sistema híbrido que, en cambio, lo envolvía.

El proyecto Jetstream de American Airlines, lanzado en la década de 2000 con el objetivo explícito de reemplazar el sistema central Sabre PSS, concluyó con la adopción de un nuevo producto Sabre en lugar de desarrollar una alternativa. La premisa inicial de construir internamente o comprar, según la cual construir un sistema de reemplazo internamente produciría un sistema mejor y más rápido, se topó con la misma realidad que casi todos los programas de reemplazo de sistemas heredados a gran escala: el sistema existente contenía requisitos que nadie conocía hasta que el sistema de reemplazo no pudo cumplirlos.

Necesitamos profundizar en la arquitectura del sistema, modificar el motor principal y desacoplar las reglas para poder cambiarlas rápidamente. Esta declaración, realizada por la dirección de TI de American Airlines durante el programa Jetstream, describe el problema con precisión. Las reglas integradas en el sistema heredado (lógica de cálculo de tarifas, implementaciones de acuerdos de código compartido, cálculos de cumplimiento normativo, integraciones de gestión de ingresos) se habían acumulado a lo largo de décadas de cambios empresariales y no estaban documentadas de forma que permitieran extraerlas sin ejecutar el sistema existente y observar su comportamiento.

El programa de modernización de Sabre, que comenzó formalmente en la década de 2010, tardó más de una década y costó miles de millones de dólares para trasladar la mayor parte de su código fuera de la infraestructura de mainframe local. En 2019, aproximadamente el 11 % del código de Sabre aún se ejecutaba en centros de datos locales, mientras que el resto se había migrado. En febrero de 2026, Sabre renovó su acuerdo PSS a largo plazo con WestJet, demostrando que, incluso después de una década de esfuerzos de modernización y miles de millones en inversión, el PSS sigue siendo la base comercial del negocio.

Amadeus logró una desmantelación más completa de sus mainframes, alcanzando un hito al retirar sus últimos equipos y migrar a la infraestructura en la nube. Sin embargo, el enfoque de Amadeus, que consistió en reemplazar gradualmente los componentes funcionales manteniendo el modelo de datos central y la arquitectura de transacciones, preservó eficazmente las decisiones arquitectónicas que se originaron en el mainframe, incluso con la evolución del hardware. La semántica de las transacciones, la estructura PNR y la lógica de gestión de inventario se trasladaron a una infraestructura moderna conservando su diseño fundamental.

Por qué la sustitución es más difícil de lo que parece: La complejidad oculta

La explicación habitual de por qué los sistemas de reservas de las aerolíneas siguen funcionando en mainframes es el coste y el riesgo. Ambos son reales. Pero son síntomas de una realidad técnica más profunda que merece la pena comprender con precisión, ya que se aplica a cualquier programa de modernización de sistemas heredados de misión crítica.

Reglas de negocio que existen únicamente en el código. La lógica de construcción de tarifas en un sistema de distribución global representa décadas de requisitos regulatorios, acuerdos bilaterales entre aerolíneas, revisiones de los estándares de la IATA y cambios en las reglas de negocio, ninguno de los cuales está documentado de forma independiente del código que los implementa. La especificación es la implementación. Reemplazar la implementación sin la especificación implica observar el comportamiento del sistema existente con la suficiente exhaustividad como para reconstruir lo que la especificación habría indicado, un proceso que lleva años y nunca se completa, ya que la cobertura de observación nunca puede ser lo suficientemente exhaustiva como para abarcar todos los casos excepcionales.

Semántica de transacciones que las arquitecturas modernas tienen dificultades para replicar. TPF proporciona procesamiento de transacciones atómico y síncrono con consistencia garantizada en todo el PNR, reserva de asiento, actualización de registro de pasajero, autorización de pago y registro de confirmación, todo confirmado como una sola unidad atómica o no confirmado en absoluto. Replicar esto en arquitecturas de microservicios distribuidos requiere una orquestación cuidadosa, transacciones compensatorias y gestión de bloqueos distribuidos, lo cual es complejo y potencialmente más lento que el equivalente síncrono en mainframe. La experiencia de la industria aérea demuestra que la "consistencia eventual" no es una propiedad tolerable para el inventario de asientos; un vuelo sobrevendido es un fallo concreto y operativamente catastrófico, no una inconsistencia temporal que se resolverá más adelante.

La superficie de integración. Un sistema PSS de aerolínea maduro está conectado a cientos de sistemas externos: control de salidas, gestión de ingresos, programa de viajero frecuente, sistemas aeroportuarios, conexiones GDS de terceros, socios de código compartido, informes regulatorios y más. Cada conexión tiene contratos de interfaz específicos, formatos de mensajes, requisitos de tiempo y comportamientos de manejo de errores que el sistema existente ha implementado y en torno a los cuales se ha construido cada sistema dependiente. Reemplazar el PSS requiere mantener simultáneamente todos los contratos de interfaz existentes (lo que limita la arquitectura de reemplazo) o coordinar los cambios con cada sistema dependiente (lo que amplía el alcance más allá de lo que cualquier programa individual puede gestionar).

El problema de los datos en tiempo real. Las reservas aéreas son datos en tiempo real; se realizan con meses de antelación y deben respetarse exactamente como se reservaron. No existe un punto de transición limpio donde se puedan dejar atrás los datos del sistema antiguo. La migración debe transferir cada PNR en tiempo real del sistema antiguo al nuevo, con todas las reglas, tarifas, restricciones y servicios complementarios asociados intactos. La migración de PNR a escala global, con cero pérdida de datos y garantía de comportamiento idéntico, ha demostrado ser uno de los problemas técnicos más difíciles en la modernización empresarial.

La respuesta arquitectónica: modernizar en torno al núcleo.

El enfoque que realmente ha tenido éxito, en Amadeus, en Sabre, en las aerolíneas individuales, no es la sustitución, sino el encapsulamiento estratégico y la extracción gradual.

El encapsulamiento de API expone las funciones principales de reserva como API REST o SOAP modernas, lo que permite que las nuevas aplicaciones interactúen con el sistema heredado a través de una interfaz moderna sin modificar la lógica central de las transacciones. Las aerolíneas han desarrollado aplicaciones móviles, motores de reservas web y herramientas de atención al cliente sobre capas de API que traducen las solicitudes modernas en llamadas de transacción TPF y devuelven respuestas estructuradas. El terminal de pantalla verde se reemplaza por una interfaz gráfica de usuario moderna; el procesamiento subyacente de las transacciones permanece inalterado.

Figura estranguladora para funciones no esenciales. Las funciones adyacentes al núcleo, como la gestión de ingresos, la gestión del programa de fidelización, los informes y análisis, y la planificación de la tripulación, se extraen una a una y se reimplementan en una infraestructura moderna. Cada extracción reduce la huella del sistema heredado sin afectar el núcleo de transacciones, que presenta el mayor riesgo. Tras más de una década de extracción incremental, el rol del sistema heredado se reduce, pasando de ser una plataforma de aplicaciones integral a un motor de transacciones especializado.

Infraestructura en la nube con arquitectura preservada. El desmantelamiento del mainframe de Amadeus trasladó las cargas de trabajo a la infraestructura en la nube, conservando la arquitectura de transacciones original. Si bien el hardware cambió, el diseño del software, el modelo de datos, la semántica de las transacciones y la estructura PNR mantuvieron las decisiones arquitectónicas que habían demostrado su eficacia durante décadas.

Nueva gestión de ofertas y pedidos junto con el sistema PNR tradicional. El estándar IATA ONE Order, que reemplaza los registros basados ​​en PNR con un modelo moderno de gestión de pedidos, está siendo implementado por las aerolíneas como una capa adicional al sistema PNR existente. Las tecnologías de ofertas y pedidos de próxima generación de Sabre, mencionadas en la renovación de WestJet para 2026, posicionan esta opción como el camino a seguir, no como un reemplazo del PSS, sino como la adición de una capa comercial moderna que eventualmente gestionará una proporción cada vez mayor de reservas, mientras que el núcleo PNR gestionará el resto.

Qué significa esto para cualquier modernización de sistemas heredados de misión crítica

El caso del sistema de reservas de las aerolíneas no es exclusivo de la aviación. Es el ejemplo más visible de un patrón que se repite en los sistemas centrales de la banca, la administración de pólizas de seguros, la facturación de telecomunicaciones y el procesamiento de prestaciones gubernamentales: un software que se convierte en la especificación autorizada de las reglas de negocio, sirve como centro de integración para docenas de sistemas dependientes y opera con una escala y unos requisitos de fiabilidad que hacen que una sustitución radical sea realmente inviable.

Las lecciones son las mismas en todos los sectores:

La extracción de las reglas de negocio del código, antes de cualquier modernización, es imprescindible. Los programas COBOL y TPF que implementan la construcción de tarifas, la lógica de los acuerdos de código compartido y las normas de cumplimiento normativo constituyen la única documentación que se conserva de dichas reglas. Una modernización que no extraiga y valide previamente esta lógica no puede generar un reemplazo que funcione correctamente en todos los casos, ya que no puede prever todos los casos sin analizar todo el código.

El mapa de dependencias determina la secuencia de migración. Ninguna aerolínea ha logrado reemplazar su sistema PSS comenzando por el componente más crítico e integrado. Toda modernización exitosa comenzó por los extremos: los sistemas de informes, los servicios auxiliares, las funciones administrativas no críticas, y avanzó incrementalmente hacia el interior. Esta secuencia se deriva del gráfico de dependencias: los componentes con menos dependencias entrantes son los más seguros para abordar primero.

La validación operativa en cada etapa es fundamental. El método de validación de doble ejecución, que consiste en ejecutar el nuevo sistema en paralelo con el antiguo, comparar los resultados y validar la equivalencia antes de que se modifique el tráfico, es el único que cumple con los requisitos de fiabilidad de los sistemas donde los fallos tienen consecuencias físicas, financieras y regulatorias.

Cómo SMART TS XL Se aplica al análisis de legado relacionado con las aerolíneas.

Las aerolíneas que utilizan Sabre o Amadeus PSS junto con sus propios programas COBOL, sistemas de cálculo de tarifas, contabilidad de ingresos, cálculo de puntos de fidelidad e informes regulatorios, se enfrentan exactamente al mismo desafío analítico que cualquier programa de modernización de mainframes empresariales: comprender qué contiene realmente el código antes de decidir qué hacer con él.

SMART TS XL, análisis de código estático Extrae la lógica de las reglas de negocio integradas en los programas COBOL, las reglas de validación de tarifas, los cálculos de contabilidad de ingresos y la lógica de elegibilidad de niveles de fidelización, que solo se encuentran en el código del programa. Para las aerolíneas que planean modernizar sistemas adyacentes sin modificar el núcleo del PSS, esta extracción genera la especificación que debe cumplir el sistema de reemplazo.

El mapeo de dependencias de la aplicación crea el grafo de dependencias que determina la secuencia de migración: qué programas del lado de la aerolínea dependen de qué flujos de datos del PSS, qué programas de informes dependen de qué salidas de lotes COBOL, y qué sistemas posteriores deben actualizarse cuando cambia algún componente. El grafo de dependencias es lo que posibilita una modernización incremental y segura, el mismo enfoque que Sabre y Amadeus han utilizado para los sistemas centrales, aplicado al código del lado de la aerolínea que los rodea.

La capacidad de análisis de impacto responde a la pregunta que precede a toda decisión de modernización: si este programa cambia, ¿qué más se verá afectado? Para los sistemas de las aerolíneas, donde un cambio en el cálculo de un programa de contabilidad de ingresos puede afectar simultáneamente a la presentación de informes regulatorios, la liquidación con socios y la consolidación financiera, conocer el alcance del impacto antes de realizar cualquier cambio es un requisito previo para un control de cambios que cumpla con los requisitos de confiabilidad de la aerolínea.

El análisis de modernización de sistemas heredados proporciona el inventario completo previo a la modernización: cada programa incluido en el alcance, su complejidad, sus dependencias, su porcentaje de código obsoleto y su clasificación de riesgo de migración. La lección fundamental de todo programa de modernización de aerolíneas —comenzar por los límites, avanzar hacia el interior y validar en cada paso— exige conocer la ubicación de dichos límites y la estructura de dependencias. Este conocimiento proviene del análisis estructural del código real, no de la documentación escrita antes de que el código evolucionara.

Las capas geológicas del software de misión crítica

Cuando reserves un vuelo con un smartphone en 2026, estarás interactuando con un software con múltiples capas geológicas distintas. La interfaz moderna en la superficie. La capa de API debajo. El motor de transacciones PSS debajo de todo esto, que se ejecuta en una infraestructura que ha cambiado sustancialmente desde la década de 1960, pero que mantiene la semántica de las transacciones y los modelos de datos que eran correctos cuando se diseñaron y que han demostrado ser demasiado fiables como para abandonarlos.

El sistema de reservas de las aerolíneas no es un fracaso de la modernización. Es el resultado de seis décadas de decisiones racionales tomadas por ingenieros y ejecutivos que comprendieron, cada vez que se proponía una alternativa, que el riesgo de equivocarse superaba el costo de mantener lo que funcionaba. Los sistemas que perduran tanto tiempo lo hacen porque se lo ganan, transacción tras transacción, vuelo tras vuelo, temporada tras temporada de reservas.

La lección práctica para cualquier equipo de modernización no es que los sistemas antiguos nunca deban reemplazarse, sino que la decisión de reemplazarlos debe tomarse con pleno conocimiento de su contenido, de lo que depende de ellos y del alcance real del cambio, y no con estimaciones optimistas realizadas antes de medir su complejidad. La industria aérea aprendió esto por las malas. Las herramientas de análisis que generan un conocimiento estructural completo antes de escribir la primera línea de código nuevo son las que permiten aprenderlo de la manera menos costosa.