SOA Migration: An Airline Keeping Its Feet on the Ground

In a mission-critical project like modernizing an airline’s product suite for reservations, inventory and passenger check-in, technology is almost beside the point. Management is key.

“We’re having a heart transplant,” said United’s Shama Patel, business program manager of the Horizon Project, a service-oriented architecture (SOA)-fueled modernization effort by United Airlines and Lufthansa.

MORE ON CIO.com

United Airlines Recruits New CIO from EDS

How to Save an Airline

Tips to Avoid SOA Implementation Problems

The existing system needed to be replaced. It’s 40 years old, built in Assembly language and still green-screen-based (even with a prettier graphical interface glued on top). The back end is no longer scalable for today’s needs and it doesn’t integrate well with…well, with anything, explained Patel. In addition, each airline and other travel providers(think Travelocity) had disparate systems that didn’t talk with one another, and they needed to do so. With customer demands for modern technology (such as, “Why can’t I check in using my BlackBerry?”), it was time for a change. (Need a good primer on SOA? Read The ABCs of SOA.)

Lufthansa and United are partnering to develop a common platform that will be used by both airlines and, eventually, also used by other members of the Star Alliance. It’d be easy to dive into the technologies they’re using to accomplish this, and to describe the IT architecture. But in Patel’s presentation, she urged IT leaders to look at the business challenges rather than code and servers. That’s what we talk about here.

The modernization project, dubbed Horizon, is huge. When it rolls out, it will impact 20,000 people in 350 locations in a three- to four-year time frame, and it will touch 20 company divisions. All while they’re trying to get people on the plane, she added.

Horizon initially focused on three major back-end functions: sales, planning and departure management. That’d be mission critical enough for any enterprise since “the reservations system holds the customer through the whole journey,” said Patel. But, she added, “What you start off with isn’t how it transpires.”

“As we worked on the back-end system, we realized we also had to replace the front end,” she said. The new back end wouldn’t be able to interact with the old front-end—and as part of the new system architecture, they needed an abstraction layer in the middle. As a result, the larger-than-expected Horizon project also impacts the integrated agent portal, another green-screen application that’s 15 to 20 years old with plenty of cryptic commands; that’s the application the gate agent pounds on when she’s trying to change your flight. Horizon also affects the corporate intranet, real-time systems for flight status and baggage systems—and plenty more. (Also read Tips to Avoid SOA Implementation Problems.)

The impetus for change wasn’t all technological. Currently, it takes seven weeks of training to prepare a new gate agent for the job, with a turnover of 50 percent. Younger employees are less patient with the old computing paradigms. (One can almost hear them complaining, “Green screen? How gross!”)

So, concluded Patel, “We needed a heart transplant and a face lift—at the same time!”

The Four Stages in Big Projects

The only way to make a project like this succeed is to address the people and business issues long before you think about technology. “Managing change is essential to help people through the ’emotional curve,'” Patel said.

First, she advised, recognize that there are four stages in any long-term IT project.

1. Awareness. People are excited and have high expectations. But they lack a clear understanding of the project scope or budget, so the rumor mill is heavily engaged.

   Be sensitive to the emotions of those who will be affected by the program but are not part of it, Patel said. If you are in the program, you can recognize and deal with the day-to-day changes, but your partners do not have that advantage.

2. Understanding. This phase kicks in about two years into a large project, according to Patel. That’s when the scope of what you took on begins to sink in, and when you realize the project is more complex than envisioned. You’ll have plenty of those “Oh, my God!” moments, Patel advised.

3. Acceptance. The acceptance phase occurs only after understanding. That’s when, for the first time, you see everyone moving in the same direction, Patel says. Participants adopt the attitude, “We’re in it together; we’ve got to get this done.”

4. Commitment. Despite your instincts, team commitment doesn’t happen until the fourth to sixth year, said Patel. “That’s when people can touch [the software], feel it.” They can see what change the new system will create in their lives.

Every big project goes through these stages, according to Patel. “But you can mitigate some of the stress and tension by using change management.”

Putting Change Management to Work

The Horizon project is using several techniques to manage the project through to success, and has developed best practices that work well (at least for United). Some of these are organizational.

For instance, United business sponsors and IT leaders are aligned through a strong executive governance board. The full, dedicated team exists to help drive change through the company—especially during the phases where many people say, “Oh, it’s just an infrastructure change” or “It’s just an IT project.” At United, this is a nontrivial department: 40 people report to Patel.

The company established a “Guidance Coalition.” This is not a matrix organization with business on one side and IT on the other, explained Patel. Participants make decisions for the division. Nor are they just a bunch of strangers who only see each other at meetings, she added; true alignment is a necessity. “The truth is that there is always a divide and a schism [between IT and the business]; on a project like this, that just won’t work,” Patel said.

United created a job title of “business engagement manager” to be a consistent point of contact between the IT project and the division. This is broader than the role of the business analyst, she said; it’s a trusted business operations person who can engage at all levels and act as “the single voice of the business across all aspects of the development lifecycle.” The business engagement manager is sourced from the business, not from technology professionals, Patel stressed: Choose someone who is “great at connecting the dots.”

Bring business process management into the company. Horizon uses enterprise process models and techniques to maintain a strong cross-functional perspective, Patel said. “Everyone [in each department] uses a different language, but we’re building a system that affects 20 divisions.”

Additional suggestions can help you get the design just-right before you write a line of code.

Put risk in a framework, she suggests. Identify which scenarios are high-versus-low impact, which have high or low probability of occurring. Doing so is critical for long-term projects. “It’s better to be prepared than to be surprised,” Patel said. Charting these in a graph or framework is an exciting exercise, she added; get a facilitator and get the team involved.

Determine the process architecture. (Finally: technology!) Identifying the process architecture sounds complicated, said Patel, but it’s about understanding what you’re doing and it gives more transparency to both business and IT participants. To determine how to create the SOA building blocks, and map processes relevant to the project scope, the Horizon project had a LEGO party. Each group of two or three team members was given tagged LEGO blocks and asked to “build a reservation” in a controlled scenario. Everyone learned what each of the pieces involved added to the process and, she implied, the competing team approach helped the Horizon personnel understand the different ways a “simple” transaction could be addressed by IT.

The Horizon project created a business integration roadmap. At first glance, it looks like a typical project management application, showing the order of software subprojects and their dependencies. But the roadmap is presented in a business way, since its intention is to communicate expectations to the businesspeople rather than to techies. It reflects dependencies from all business teams, not just IT; a call center move or union negotiations can impact the software rollout schedule, after all. Identify which migrations will happen, when.

And, added Patel, be sure to factor in the benefits realized from each stage in the project. “Tell them the value,” she said, “Or they’ll stop giving you the money.”