Scandinavian Airlines pilots SOA

Service oriented architectures (SOAs) can ease application development but they impose a significant administrative burden. David Braue finds out how Scandinavian Airlines dealt with the challenge of SOA proliferation with flying colours.

case study The value of service oriented architecture (SOA) development, which builds online services around reusable and commonly available components, has been widely recognised, particularly amongst large businesses with significant collections of servers and applications. For Scandinavian Airlines System (SAS), a steadily expanding role for SOA has extended the life of legacy systems and encouraged code reuse -- but has also forced the company to find new ways of managing the code bounty.

SAS carried 38.6 million passengers in 2006, an increase of 6.3 percent over the previous year and a reflection of the airline's growing footprint, particularly along busy Europe-Asia routes. Reflecting its multinational structure, the airline operates from primary hubs in Copenhagen, Oslo, and Stockholm and services 82 destinations worldwide.

After more than 30 years of computerisation, SAS is still using its original Unisys mainframe-based reservation and ticketing systems, responsibility for which is shared by the internal IT department and outsourcer CSC.

SAS IT's focus on developing new systems, and new system functionally -- as opposed to keeping them running, which is CSC's job -- has forced it to keep on top of both emerging technologies, and the ever more difficult task of keeping up with legacy platforms. For this reason, the division began looking into SOA technology as early as 2001, when it experimented with building its first Web services.

Magnus Clarving, manager of corporate and agent systems, SAS

The appeal of SOA came from its ability to provide more casual connections between systems than were possible under previous object-oriented systems, says Magnus Clarving, manager of corporate and agent systems with SAS. "With the older structures, you weren't as loosely coupled as you had to be to have an effective distributed environment," he explains. "You were still quite tied up with the application, interface, and business levels."

"With Web services, we could see the possibility of being much more loosely coupled, and to have more flexibility within the communication between the systems, and within the environment. We are still heavily dependent on those old systems and old IT structures, but if we don't use Web services we will have large problems delivering what we're supposed to do."

Seven years of coding
In the intervening years, SOA-driven development has become the norm at SAS, where the continuing pace of advancement has seen newer Windows Server environments rolled out alongside legacy platforms.

Although the company has stopped short of moving its entire IT environment to SOA, the paradigm has been used each time the team embarks upon a new project. To date, this has resulted in more than two dozen major Web services -- many of them highly complex -- which are regularly reused throughout the company's application environment.

This ability to reuse code has justified the company's SOA push, according to Clarving.

"It's mainly about time to market, and it helps us with quality. If we can centralise our data and use Web services to access it, we don't have to have redundancy in our data.

"Reducing our number of databases has always been a big issue for us, because in the old days you made a GUI, then built an application layer and a database that rarely connected to any others. Centralising our customer data, for example, reflects the possibility to develop new products in the long run," he explains.

Every technology has its downside, however, and SOA's downside has become clearer to SAS as time goes by. With links stretching from one side of the company's IT organisation to the other, a particular Web service might be inextricably linked with one or 10 others to make a particular function work. This complexity, and the increasing reuse of SOA services, has forced the group to develop a new skill: keeping track of them all.

Without a coherent way of tracking these code relationships, however, SAS IT staff have found themselves struggling to keep on top of just what goes where. This has made it difficult to extract particular bundles of Web services for new applications, and even harder to reflect them in documentation created for those applications. That documentation, of course, is essential given that CSC staff have to develop an intimate understanding of each new application that's introduced into the environment.

Over the past year, the airline's IT team has found the solution in Software AG's Centrasite, an SOA cataloguing tool designed to keep track of Web services and their relationships within the SOA environment. Because Centrasite maintains a single, central index of the spaghetti of SOA interfaces, it has helped the team finally get a handle on the diverse array of code that its SOA investment has created.

This capability, in turn, has helped the team plan new code rollouts more effectively in the past. "It's easier for us to break out the parts of a system and define it as its own system," says Clarving. "We have more flexibility now, and the Web service becomes its own system with its own documentation."

Documentation for the sake of application management is only one of the targets of the new project, however. Facing increasing pressure to improve version control, logging, tracing and overall governance mechanisms, the Centrasite repository has finally provided a robust way for the team to document the SOA's expansion. This makes the catalogue essential both at the business level, and as a technical aid for ongoing systems work.

"We're getting more and more questions about integration between systems," Clarving says. "We had to use some kind of tool to administer the Web services, because they will grow substantially during the coming years. With this environment in place, we've been able to control the environment in a different way. It's easier for us to share this information within SAS and other departments -- and to provide full documentation of existing and coming Web services."