About the company
The airline industry is undergoing a services revolution. Having once considered their proprietary systems and processes as core to their business, airline carriers increasingly rely on shared services providers such as the Amadeus IT Group, which processes over three million flight bookings a day.
Airlines are also now highly dependent on their alliance partners, leveraging one another’s flight networks to provide as broad a range of services to customers as possible.
This means that systems must integrate freely and easily, which explains why many carriers in the industry are turning to service-oriented architecture (SOA), the IT infrastructure design pattern in which application functionality is broken down into component ‘services’ – integrated via an enterprise service bus (ESB) – that can be quickly recombined to form new composite applications.
British Airways is one such carrier. The UK’s flagship airline began its SOA implementation, built around a Sonic ESB from Progress Software, in early 2009. Here, chief technology officer Gordon Penfold explains why the company turned to SOA, the immediate goals of the project and the long-term contribution he believes the SOA infrastructure will make.
Penfold believes that SOA is poised to become the new standard IT infrastructure for the airline industry, pointing out that Lufthansa, Air France and United Airlines have all begun significant SOA investments. This will enable far greater flexibility in the relationship between carriers and service providers, he says.
And while Penfold acknowledges that SOA is no longer the industry buzzword it once was – “the lunatic fringe has moved on” – it is now entering the mainstream, he says.
Information Age (IA): What is the immediate aim of your SOA deployment?
Gordon Penfold (GP): It’s designed to do three major things. The first is to remove our reliance on the IBM TPS 4.1 operating environment. We have a small number of TPS 4.1 applications, including our movement control system, which is the legal record of aircraft movement. Also, we use a number of services from [airline IT services provider] Amadeus, and two of those services are still on the TPS 4.1 base. So the first goal of the project is to get rid of our dependence on TPS 4.1 in any form.
The technology is at the end of its life. IBM is going to stop making the hardware in about a year’s time, and
the operating environment is a 32-bit environment. This thing has been running over the past 40 years, and it still just sort of runs now, but it is a dead end in terms of the future.
The second objective of the SOA project is to replace key infrastructure, such as our messaging and printing infrastructure. And once we’ve got the modern infrastructure in place, and we’re using the modern services from Amadeus, they will become a substantial platform upon which British Airways can build its service offering for customers.
Choosing SOA
IA: Why have you chosen an SOA approach to achieve these?
GP: In a nutshell, it is the modern way to do things. We are keen to have the ability to make all of our underlying services available through all of our various customer touch-points. If you are going to do that, clearly you need something with the capabilities of an SOA infrastructure.
The second reason we are going down the SOA route is to give ourselves a much more flexible platform. Partnering and mergers are a key part of the airline landscape going forward, so having this kind of infrastructure will help us to rapidly form new relationships with new partners.
Another benefit is that taking a view of your estate that allows you to segment key services, and the means to consume those services, enables you to improve the overall cost of ownership and the underlying quality of the asset base that you maintain.
IA: Why did you choose Progress Software’s Sonic ESB as the hub of your SOA?
GP: Every single messaging transaction that BA generates comes through this infrastructure, and they are things
that are mission critical, such as the association of a customer with a ticket, or the way in which baggage is loaded onto aircraft. These things demand a high level of assurance, although they are not huge in volume.
"Our SOA deployment is a fundamental re-engineering of our core infrastructure."
During our evaluation in 2008, we concluded that there were two sorts of SOA platforms around. There were SOA platforms that gave you the in-built security and resilience that we needed around our mission-critical infrastructure, and ones that didn’t. The Sonic platform is a good example of one that is highly secure and has a high degree of assurance associated with it.
Also, Progress was prepared to warrant the end-to-end coherence of a stack of products that was mainly sourced from Progress, but that had one or two other components that were from a third-party supplier. It was prepared to warrant the technical integrity of the full SOA stack.
A common architecture
IA: How have your in-house software development resources adapted to the SOA?
GP: There is a whole new approach to life that the architects and developers have to adopt as part of the SOA deployment. We’ve devised something called the ‘common architecture’, which will be deployed right across our estate, so any investments we make here on in will need to conform to that architecture. This allows us to deploy any capability through all of the touch-points.
IA: Was improved code-reuse part of the justification for the SOA?
GP: We have had a component-based architecture for some years. It falls short of being an SOA but has some of the same ideas behind it: we have chunks of code that are broken into useful components, which then support common business services, such as our payment-processing component. But this is not as flexible as a full-scale SOA deployment, so we’re wrapping those components as course-grained business services and making them available via the SOA infrastructure.
Customer touch-points
IA: What kinds of customer interaction are now possible?
GP: In April 2009, we launched a piece of functionality through BA.com called ‘dynamic packaging’ which allows customers to book and customise a holiday, including hotel booking and car rental, though our site.
We have a number of back-end links through to hotel and car providers, which operate in real time and give us a real-time quote. That is integrated with the rest of BA.com through the ESB; it was the first ESB-enabled technology we deployed.
Also, we are starting to make proactive offers to customers at different touch-points. We used to ask if they wanted to upgrade at the time of booking, but we are now going beyond that. So you may well be made a proactive offer when you service your booking, to indicate a seat preference for example, or at a self-service kiosk.
This is all happening through the same channel. When you have a clear distinction between the core business services that make up the components of your proposition and the front-end systems that consume them, you can mix and match [services] quite liberally to give yourself agility and to offer your customer the best mix available.
SOA in the future
IA: How does the move to SOA assist other strategic ambitions?
GP: We are currently reinvesting in our operational systems. At present, we have a number of point solutions in place, and we want to draw those together through the SOA infrastructure in order to improve the end-to-end control over our operations.
For example, we have a sophisticated system that helps direct our ground staff, and we have other applications that manage assets in the terminal area. We are now starting to link those together through the infrastructure, which allows you to use knowledge from one system to inform the other.
Another strategic area is our website. BA.com is essentially still a web channel, but we are looking to making it visible as a Web 2.0 application, as fragments or widgets.
SOA is the key enabler for all of this. Our SOA deployment is a fundamental re-engineering of our core infrastructure.
