Islands of Automation: Bridging the Gap Between Disparate Systems

Order a reprint of this story
Close (X)

ORDER A REPRINT

To reprint an article or any part of an article from Hospitality Upgrade please email geneva@hospitalityupgrade.com. Fee is $250 per reprint. One-time reprint. Fee may be waived under certain circumstances.

SEND EMAIL

June 01, 2002
Feature
Jon Inge - jon@joninge.com

View Magazine Version of This Article

© 2002 Hospitality Upgrade. No reproduction without written permission.

Why interfacing the islands of automation all over your property is still such a challenge despite the benefits, and what we’re doing about it.

Plus, a highlight of what’s happening with systems and interfaces you’re likely to find on property.

This year HITEC celebrates its 30th anniversary, a period that has seen an astonishing growth in both the capabilities of computer-based systems and the number of areas in a hotel where they’re used. From pretty simple beginnings they’ve expanded to offer remarkably sophisticated functionality as their benefits became more widely recognized, and operations folk have continued to come up with new ways to use them.

A great many of these systems were, and still are, developed in isolation from each other by talented people who recognize and focus on a specific operational problem they realize could be solved through automation. They weren’t necessarily aware of the larger picture or, for whatever reason, may have chosen not to focus on it; after all, you can only fix so much at one time. The possible exchange of data with other systems in the future is often farther down the list of priorities than solving an apparently self-contained problem right now.

As a result, wherever you look in most properties these days you’ll find a miscellany of individually very capable systems that don’t talk to each other very well. They often run on different operating systems, use different data formats and make different assumptions about what a piece of data means under their own, very specific circumstances. Too often, however valuable they may be in their own location, they’re islands of automation.

Interface Libraries
The benefits of sharing data between systems have long been apparent in providing more complete, consistent and accurate information about the guests and about the property’s operations. The main approach to achieving this, of course, has been to rely on specific interface bridges between individual pairs of systems.

Simple posting interfaces such as from POS or telephone call accounting systems to a PMS are straightforward and effective, once the data elements, message format and communications parameters have been agreed. More complex ones, such as two-way central reservation/property management system (CRS/PMS) links or three-way PMS/sales and catering (S&C)/revenue management (RM) interfaces, require a careful understanding of where each system derives the information to be exchanged, and what it does with it when received.

InfoWorld columnist Bob Lewis put it well when he said, “Every piece of software is an opinion.” This is loosely translated to mean that it represents the developing company or programmer’s viewpoint on how the data should be represented, organized and manipulated – and that’s seldom going to be the same as anyone else’s.

A familiar example is where a CRS that can handle 10 four-character room type codes per property has to exchange availability and reservations information with a PMS using 30 six-character room type codes. Understanding what each code means to each system is obviously crucial before the necessary translation tables in each system can be built. Every combination of different vendors’ systems may require a different set of such definitions, and in the absence of industry standards each vendor has had to develop a huge library of unique system-to-system links over the years to handle this.

For anything beyond the simplest posting links, this quickly became very complex to maintain as systems continued to be enhanced. It’s also complex to install, since each vendor has provided precisely the right version of its interface to match the exact release levels of both its own system and the one it’s talking to. A one-character change in format between one release and the next can stop a previously reliable interface cold. This is why most vendors require representatives of both companies to be onsite when an interface is installed, just to make sure they can determine where something needs to be tweaked if a problem arises.

How About Integrated Systems?
In a parallel approach many vendors set out to expand their products to cover more areas, removing both the need to maintain interfaces and the chance that a piece of data would be misinterpreted between different systems. The downside was that these multi-area, integrated systems didn’t always provide the same functional depth in every area as their more specialized cousins, though continuous development brings them closer every year.

Even the most capable multi-function integrated system still needs good interfaces, though, both to the simpler specialist systems on any property (PBX, call accounting) and to existing systems from other vendors that the client finds perfectly satisfactory and doesn’t want to replace with one or more of an integrated system’s modules.

The whole assembly is a web of cross-links between different areas, reinforcing the abilities of each to capture and use really useful stuff. But if you don’t truly understand how it works, it’s also capable of ensnaring you and leaving you dangling in a sticky bind of misunderstandings, incomplete data transfers and frustration. Interfaces aren’t easy.

So What Are We Doing About It?
Software Standards
Having an agreed set of interface standards would clearly be a huge help, but it’s proven fiendishly difficult to achieve despite some valiant attempts such as the HITIS (Hospitality Industry Technology Integration Standards) project. After all, there’s been little incentive for the vendors to re-develop interfaces they already have sitting in their proprietary libraries.

Standards have a more obvious benefit to vendors newly arrived on the scene, but they’re often able to emulate an existing interface that has become a de facto standard. Many POS vendors, for example, emulate the widely used MICROS 4700/8700 format when writing their PMS posting interfaces. This is a simple way to enter the market, but is by definition self-limiting since it stifles the introduction of fresh interface capabilities.

On a more technical level, XML protocols have been held up as the great hope to lead us to interface nirvana, since they offer considerable power and flexibility in describing what data a message packet contains and how it can be treated. But a truer analogy is that XML is more like a universal alphabet than a language. Two different systems may easily recognize the character. But they won’t necessarily understand how to combine it with other characters to make universally understood words without knowing the operational assumptions built into the data elements and handling instructions it contains.

Fortunately, the Open Travel Alliance (OTA) is working on a set of standard XML words and phrases appropriate to the travel industry as a whole, building on the detailed HITIS specifications for hotel-related messages. This does at least hold the promise for easier links between property management, central reservations, GDS and Internet-based booking engines in the near future.

The Comtrol Box
Another set of standards at the local level is represented by the Comtrol (originally Protocol Technologies) Lodging Link product, which acts as a common interface processor for a wide range of property-based systems. With this approach a new PMS vendor, for example, need develop only a single POS interface to the Comtrol box, and can then interface with any POS system that has a PMS link to the same unit, removing the need to develop different versions for different POS products.

Another advantage is space saving. The wall-mounted Comtrol unit is very compact and handles up to seven interfaces, replacing the full-size PCs otherwise used by most PMS vendors to process interfaces, often at only four interfaces per PC. Comtrol’s interfaces cover a good variety of the most widely used products on the market, and a number of PMS vendors use them as their complete interface solution, but they obviously can’t cover all possible products, and don’t cover the more complex interfaces such as PMS-to-sales and catering.

Custom Interface Developers
For more unusual or complicated interface needs, vendors such as NoBarriers, HubX and others have found considerable success developing custom interfaces. Originally inspired by MicroScript, (which was acquired by New Era of Networks, later absorbed into SyBase), these companies use their custom middleware tools to develop fast and capable interfaces between multiple products for specific client needs.

A classic example is the need of small-to-midrange management/ownership groups to consolidate information from multiple properties, all of which use the specific – and different – systems required by their flag brands. Similarly, representation companies such as Lexington and Trust use NoBarriers to link their CRS products with their client properties’ multiple different property management and S&C systems, and Starwood uses them to link its Siebel sales force automation system to its properties’ Delphi sales and catering applications. HubX has extended the concept by providing a range of flexible tools to work with the data it transfers between disparate sources, from Internet booking engines through centralized reporting to a complete central reservations service.

These kinds of custom developments aren’t inexpensive, but the benefits for the companies that really need them quickly outweigh their cost.

Major brands attempt to eliminate the problem altogether by requiring their franchisees to use only certain specified products, so they can focus their energies on developing comprehensive interface capabilities between just those particular software applications. Even this doesn’t ensure a completely uniform environment, however, given the constant turnover of properties between flags, and some flexibility in working with data from other systems is always desirable.

The Vendors’ Dilemma
Systems vendors are caught between a rock and a hard place. On the one hand they need to continue to expand the scope of their systems, both in depth of functionality and in area of coverage, so that properties have the option of buying as much as possible from one source with the minimum number of interfaces to other systems.

On the other hand they also need to constantly improve their products’ ability to interface with the outside world because no one system will ever be able to do it all. It’s a never-ending and eternally complex task.

Can’t We All Just Get Along?
Apart from all the technical issues, probably the biggest difference most vendors could make to improve the situation would be to cooperate with each other far more meaningfully. It’s really sad how seldom vendors with complementary products approach each other to improve their interfacing capabilities, thereby extending the value and attractiveness of both. The relationships are much more often wary, with constant concern that unannounced changes one vendor makes to its products will make the other look bad.

The finger-pointing and territorial cries of it’s not MY problem that go on when interface problems arise onsite are legendary. There is just no excuse for it; it may be true or it may not, but no one is perfect. Every vendor enhances its products. Some of those changes may affect important interfaces, and it’s seldom possible to notify every vendor whose interface might be impacted.

In any event squabbles over who caused a malfunctioning interface just make the property think badly of both vendors, and neither can ever win from adopting that attitude. This has always been a small industry, and word travels quickly about which vendors work with everyone to solve problems and which are the first to let accusations fly.

Finally
Interfaces are always going to be with us. You can avoid much of the interface pain by sticking with widely used systems, but these may not always represent the best answer to your operational needs.

As long as we have to pass data between systems developed by different people – and we always will, since no one is ever going to produce a single system that covers every single area that needs automating on a property – we will always have the potential of misunderstanding the message.

There is hope. The continuing attempt to define interface standards has been given added strength and impetus by the involvement of the wider travel community through OTA. XML does at least hold the promise of making the technicalities of exchanging data both simpler and more powerful, and the continuing spread of ever more capable, integrated systems steadily reduces the number of interfaces actually required.

But patience and a genuine willingness to cooperate will always be our biggest assets.
Jon Inge is an independent consultant specializing in property-level technology. He can be reached by e-mail at jon@joninge.com or by phone at (206) 546-0966.

Articles By The Same Author



want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.