Service Oriented Architectures

A lot has been written over the last three years about the topic of a service oriented architectures (SOA). The concept refers to a more flexible way to create software using Web services. Rather than creating tightly coupled code that bounds specific functionality within the application, software written using SOA principles creates loosely coupled components that can easily be removed or altered without impacting the entire application. "SOA turns monolithic inflexible applications into hundreds, even thousands of small flexible applications" Gartner research estimates that by 2008, more than 60% of enterprises will use SOA as a “guiding principle” when creating mission-critical applications and processes.”

Understanding the underlying architecture of software has always been a difficult task for a variety of buyers in the travel value chain. Whether it is a corporate travel manager evaluating self-booking software or a leisure travel agency looking at reservation technology, the need to evaluate the underlying software architecture has never been greater.

Often vendors confuse the issue by stressing their use of Web services. Utilizing Web services to connect to disparate sources of content has become the norm in the last 3-4 years. Just because an application uses Web services for connectivity does not mean the software has been written using a SOA approach. As an example, a major hotel chain still uses a mainframe running TPF (an old operating system created by IBM for the GDS) as their central reservation platform. The company has created a Web services layer to aid in the communication with property based system and external channel distributors. This is obviously a good use of Web services but does not reflect a service-oriented architecture. If this chain wanted to do a complete revision of their rate structure, the antiquated mainframe approach would lead to a nightmare of programming tasks. If this application was built using SOA, an overall rate revision would be done with less pain, implemented faster and would not disrupt other modules of the reservation process. Unfortunately for this supplier, SOA theories were not around in the 1970's when the core reservation system was built.