American began the initiative in 2007 with the development of an enterprise service bus (ESB) it dubbed Flight Hub. The ESB uses IBM products -- including WebSphere, Message Broker, MQSeries messaging and Application Server -- as its core components. It also uses IBM's Data Power for service management.
American built the system on instances of Red Hat Linux Enterprise running within VMware virtual machines hosted on x86-based blade servers, and has a few machines running Windows Server for off-the-shelf applications that require it.
At some point, Jetstream too will have its own ESB, Customer Hub, a new cargo system will have Cargo Hub, and so on. These ESBs serve as transport mechanisms that connect to all related applications and enable real-time data sharing between applications as well with other ESBs and with the mainframe.
Flight Hub is highly available, highly recoverable and runs simultaneously in more than one place -- unlike the mainframe, which offered redundancy within a single data center but had no backup site. "The program objective was to enable true disaster recovery," Hassell says.
The Flight Hub ESB consists of three main components. Applications can access data on demand, receive information on a regular schedule and send and receive data through topic-based publish/subscribe messaging. In the latter case, applications can subscribe to or publish information to update current flight times or let staff know when a crew can no longer legally continue to fly because they must rest, for instance. "The Horizon architecture uses standard distributed [computing] patterns using message queues and service calls between components," Hassell says.
"Flight Hub is a hybrid. It provides ESB capabilities and provides services to other applications," and passes data to and from the mainframe, Hassell says. In this way, it can pass data to and from any application and keep all data in synch.
After completing Flight Hub, American created a new relational data store to hold flight operations data, and began bringing in new applications. Hassell's team has been rewriting or replacing existing mainframe FOS applications for Flight Hub, one at a time, as well as writing and acquiring new ones. "Horizon was not keen on writing applications. Our strategy from the beginning was buy versus build," she says. "We continue to be thoughtful about which applications should be built." So far American has 22 applications deployed, with 20 in development, and has connected a total of 55 applications to Flight Hub, including the AA.com Web site.
Around 20% of the completed applications were written from scratch, Hassell says; the rest were purchased and modified as needed.
The latest applications include:
A revamp of the Aircraft Communications Addressing and Reporting System (ACARS), which allows text-based messaging between the cockpit and the personnel -- usually the dispatcher responsible for that flight, or operations. American runs ACARS on AIRCOM Server, an off-the-shelf product it acquired from Geneva-based SITA.
A tool that shows aircraft locations on the taxiway.
A mobile crew check-in app.
An aircraft tracking application with routes of flight for dispatchers.
"We can seamlessly pass information to all of those applications and we don't have to modify them any more from an integration perspective," Hassell says.
American also deployed a new flight-following tool. Users, primarily dispatchers and the operations towers at some airports, "have the ability to talk to our airplanes in the air and report more efficiently any information regarding specific weather situations or something where they need to alert more than one aircraft," Hassell explains.
In some cases American has been able to buy instead of build, with little or no customization required. One example is ACARS. Previously, those functions were written entirely on the mainframe in a proprietary language called SabreTalk. With the new software architecture, Hassell says, "We were able to deploy [new functionality] much faster and take advantage of the new technology."
American's partners, its Oneworld carriers, will also benefit from enhanced operational information sharing, as will their customers. "We are able to help them have a seamless experience," Hassell says, by doing development work to make sure American can share detailed flight information with each Oneworld airline's systems.
A matter of timing
American continues to chip away at both projects, one application at a time, with the ultimate goal of creating a more flexible and dynamic set of core systems and associated applications that can help the airline innovate. "The new systems are designed to fundamentally improve both the customer and the employee experience, which will lead to increased loyalty and revenue," Leibman says.
While work is progressing, American has no firm date for moving completely off the Sabre system and shutting off the mainframe. As new applications are added, "we pull things out of the mainframe," Hassell says. The airline can slow down or speed up development as resources -- especially money -- allow.
For American, it's a slow, deliberate and very collaborative process with the business that focuses on both business process change and the trade-offs involved when moving from a highly customized, homegrown system to buying off-the-shelf software. Collaboration with all stakeholders is essential, says Hassell. "That partnership is what makes us more effective."
Robert L. Mitchell is a national correspondent for Computerworld. Follow him on Twitter at twitter.com/rmitch, or email him at firstname.lastname@example.org. Johanna Ambrosio is managing editor for technologies at Computerworld. Follow her on Twitter at twitter.com/jambrosio, or email her at email@example.com.
This story, "From build to buy: American Airlines changes modernization course midflight" was originally published by Computerworld.