Islands of Automation

In this article…

Interface Libraries

How about integrated systems?

Software standards

The Comtrol Box

Custom Interface Developers

The Vendors’ Dilemma

Can’t We All Just Get Along?

Finally

Sidebars

ASP Systems – Connections Are Critical

OH, WHAT A TANGLED WEB WE WEAVE

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.
This year HITEC celebrates its thirtieth 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 a lot further 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 (CRS/PMS) links or three-way PMS/Sales & 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 in saying that “every piece of software is an opinion,” meaning 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 ten 4-character room type codes per property has to exchange availability and reservations information with a PMS using thirty 6-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 provide 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 on site 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 a lot of 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 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 PMSs, CRSs, GDSs and Internet-based booking engines in the not too distant 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.


Figure 1 [click to enlarge}
Schematic diagram of Comtrol’s property system interface box, showing the different protocols and links used between property-level systems in an off-the-shelf product. Courtesy of Comtrol Corp..

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 cove 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-S&C.

Custom Interface Developers

For more unusual or complicated interface needs, vendors such as No Barriers, 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 No Barriers to link their CRS products with their client properties’ multiple different PMSs and S&C systems, and Starwood uses them to link its Siebel Sales Force Automation system to its properties’ Delphi Sales & Catering applications.


Figure 2 [click to enlarge}
Schematic diagram of NoBarriers’ custom PMS switch, showing the variety of systems that can be interconnected. Courtesy of NoBarriers, Inc..

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.

All these custom developments aren’t inexpensive, but the benefits for the companies that really need them very quickly outstrip 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, 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 on-site are legendary. There’s just no excuse for it; it may be true or it may not, but no-one’s 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 fly with the accusations.

Finally

Interfaces are always going to be with us. You can avoid a lot of 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’s 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.

  • Search all current and archived News and Articles here:

  • Jon Inge & Associates
    9301 236th Street SW
    Edmonds, WA 98020

    office: 206-546-0966
    fax: 206-337-1355
    cell: 206-355-3111

    jon@joninge.com