Travelocity’s flight to open systems

CTO Barry Vandevier trusts Linux to keep Travelocity’s renowned extended enterprise aloft.

The extended enterprise concept is as old as networking itself, and as young as  e-commerce. Few companies typify that old/young dichotomy better than  Travelocity, the Internet child of Sabre Holdings – granddaddy of extended enterprises.

In Travelocity’s seven-plus years of operation, it expertly has piloted the e-business skies, serving millions of customers with connections to thousands of hoteliers, airlines, car rental agencies and other travel suppliers.

Its Merchant Program, just one instance of its e-business architecture, already represents more than 7,500 hotels one year after its launch. With this program, which increased by 3,000 partners from June to September 2003 alone, Travelocity behaves like a hotelier’s own Web site. Via exclusive contracts negotiated between Travelocity and the hoteliers, the site taps into the hoteliers’ central reservation systems (CRS) and carts out the lowest rates and real-time availability. This is in addition to the 55,000 hotels that Travelocity sells via the Sabre system (the same data accessible by all travel agencies using Sabre).

CTO Barry Vandevier, one of Travelocity’s early site developers and a member of Sabre’s IT team before that, became CTO in October 2002. He describes his passion for open source tools and shares his thinking on Web services, security and site management in an interview with Julie Bort, executive editor for Network World’s Signature Series.

From an IT standpoint, describe your relationship with Sabre.

We have separate IT organizations. We focus on the Travelocity site, Sabre on the infrastructure, but we collaborate heavily on a constant basis building out our projects. For instance, the Hotel Merchant product that [Travelocity has], we built together. The Total Trip product that we released in June, where we are packaging our hotel and air products together, was a combined product between Travelocity and Sabre.

Tell me a bit about Travelocity’s architecture.

We are migrating to a new architecture, from our original system built on C++, running on Unix SGI. We are migrating to an open source Java platform running on Linux. Total Trip is running on the new architecture, as is some other functionality. We’ll continue migrating over the next several months [for completion] next year.

Why Linux?

We want to improve our flexibility and really decrease our time to market. The system we run for some of our older products is great, but from a total-cost-of ownership perspective, Linux was just a very good ROI.

We’re a big fan of open source, from total cost of ownership and from the sharing/collaboration [creation processes], using tools developed by other people and having [easy access] to other people who have experience with them. We’re using Tomcat, Struts, Linux, JUnit, as well as some off-the-shelf products, like [IBM’s] Rational Rose and [JetBrains’] IntelliJ, for our [Java] development environment.

Tell me about Travelocity’s Merchant Program. What infrastructure was needed to enable direct connectivity to the hoteliers’ CRS?

We took advantage of existing Sabre connectivity to 55,000 hotels’ CRS to really improve our suppliers’ ability to update rates and inventories on our system. We partnered with Sabre and built interfaces to [Sabre’s] Merchant platform through XML services.

You say XML services. You don’t consider the connectivity between the Travelocity and Sabre Merchant systems to be Web services?

I would actually. But because that was built a while back, we are working on a much more robust gateway, right now, with Sabre. This is Sabre’s Universal Services Gateway, which gives us access to Sabre capabilities via Web services.

So the current XML services don’t have all the latest fancy things, like UDDI, etc., I would guess?

That is correct.

What then is your opinion of Web services?

Web services are a big key for us for the future, to improve flexibility and changes between [us and our] partners. Web services will enhance our suppliers’ connectivity, so making changes or adding content will be much faster for both parties.

What advice can you offer for security?

Security has got to be top of the mind. We have a full-time security officer. We also work a lot with Sabre security, and we involve security at the beginning of every one of our projects. We walk through a set of security questions so that we get our technical leads thinking about the subject. Any profile or customer data has to be heavily encrypted. Anything [sensitive] we store in any servers or database has to be encrypted. We never send, for instance, credit card data through the customer’s [user interface], we only do the last four digits.

We do security awareness training. HTTPS is readily available, Triple DES or PGP when we are transferring files – there are a lot of very secure capabilities out there, and we make sure our technical leads are trained and thinking about them.

One big issue for extended enterprises is finger-pointing – blaming the other folks when problems occur. What is the best way to handle trouble ticketing over multiple systems?

It is more than trouble ticketing. This is another area that you’ve got to think about from the beginning: Make sure your product is well-instrumented with monitoring. If you don’t, that’s where the finger- pointing comes up. [Monitor] all the way down to the connectivity, the time it takes to receive responses. Record in a consistent manner the right, detailed data to flag an issue. We have people dedicated to building out monitoring for our systems. We built [code that moves] any error messages we record to a centralized location that we can then monitor. Flags [are sent] either via paging, or some of our hosting services will flag via Computer Associates’ Unicenter. We are using some open source monitoring products like Java Message Service. One of the complexities with Total Trip is that we are connecting multiple partners at once and packaging that for our customers. That magnifies the connectivity and forces you to, upfront, make sure you’ve got good instrumentation.

How do you test?

Before we launch any product we have multiple test systems. We use JUnit, and require unit tests on all of our new architecture. [This involves testing code in small units while it is being developed.] Before [new architecture] ever goes to production, we use products like [Qwest Software’s] JProbe and [Mercury Interactive’s] LoadRunner, so we can look for appropriate load, any issues that may be hogging up the CPU or memory. Once it’s done over there, it goes into certification testing before it launches into production. We do continuous integration testing – we use an open source product called CruiseControl.