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.