My last column outlined the challenges of connecting hotel systems in order to exchange the data they need from each other. Where vendor-supported interfaces exist and do exactly what you need, they are usually the best way to get reliable performance. But in many cases, available interfaces may not meet your hotel’s particular requirements, they may not exist at all, or they may be cost prohibitive.

This week I will cover some alternative technologies for connecting systems, including how they work and some of the situations where they are most useful. To some extent, these technologies compete with each other (and with vendor-provided interfaces), but they are mostly good at different things, and the vendors I spoke with viewed the different approaches as more complementary than competing.

Traditional APIs

Most modern technology providers offer Application Programming Interfaces (APIs) to facilitate connectivity to their systems. APIs vary greatly in terms of their architecture, reliability, speed, purpose, and functionality. Some vendors make them freely available to encourage third parties to connect, while others guard them closely and/or impose significant costs on the third parties, hotel clients, or both. Some vendors are happy to enhance interfaces to meet client needs at modest or even no cost, while others may charge fees that hotels may see as extortionate.

APIs provide a means for a third party to send or receive data to or from other systems, and many APIs can also initiate, amend, or close out transactions in another system.

The challenges of traditional APIs were covered in the first installment of this article, so I won’t repeat them here. The upshot is that APIs can be excellent solutions if they meet your needs in terms of functionality, speed, and reliability. But this depends both on the capabilities of the API itself, and on the specific needs of your hotel or hotel group. Many standard APIs may meet those needs well and cost effectively. Others may not, in which case you will either need to engage the vendor to modify it, find an alternative connectivity solution, or live without. Most individual hotels and smaller groups have limited leverage over vendors or funding for custom development, so alternatives from one or more of the categories covered below may make sense.

Enterprise Service Buses

One option that can work well for connecting a wide variety of systems is an Enterprise Service Bus (ESB) that has been customized for hospitality. I covered ESBs in this blog from about three years ago, which is worth a read if you want some background on them; the basics have not changed.

Numerous larger technology companies such as Oracle, MuleSoft, IBM, Red Hat, Microsoft, Tibco and others offer mature ESB platforms, which receive messages from one system (the “producer”), transform them, apply business logic, and send them to one or more “consuming” systems (they can do much more than this, but for today’s purposes, this is a good start). ESBs can orchestrate complex relationships across multiple systems, for example taking a message from one system, delivering it to four different ones, waiting for responses from all four, and confirming them back to the first system. Or if one of the four systems detects a critical error condition, the entire sequence can be “rolled back” as if it never happened. Properly applied, logic can ensure that the systems always remain sufficiently in sync.

However, these commercial ESBs need transformations and business logic to solve hospitality-specific problems. These customizations can be developed either by a hotel company, by a consultant, or by a specialized vendor that provides the ESB platform but also adds business logic and connectivity to various hotel systems. Two companies, Ireckonu and NEC (via its Univerge platform), offer commercial-scale products for hospitality based on ESBs, but with specific connectors for various hospitality products. I am aware of a couple of others, but they are not currently marketed as products; they are rather more in the nature of consultants that have developed custom ESB solutions for larger hotel groups.

Ireckonu has a large portfolio of connectors and is used by several hotel groups to orchestrate anywhere from a few to most of their in-house systems. NEC has a more limited offering that is used primarily to support some of its partners, such as those who provide check-in kiosks. Jonas Chorum also has an ESB called Jonas ARC in its portfolio, using it for internal efficiencies and to make it easier for third parties to connect to their multiple Property Management Systems (PMSs), spa system, and club software system. The company does not currently sell Jonas ARC independently, but it may be useful for hotels using one or more of the Jonas products.

ESBs are powerful connectivity tools, arguably the best available for connectivity “at scale.” While they can be deployed on a Software-as-a-Service (SaaS) basis to solve specific interfacing issues, one of their real strengths is the ability to convert many point-to-point interface connections to a hub-and-spoke topology, where each system needs only a single connection to the ESB. In a hotel, this replaces the traditional role of the PMS as the controller of messaging. The ESBs from the major tech companies are best-of-breed solutions for connectivity management, and as such are far more capable at doing this reliably, robustly, and at scale than even the best PMS.

While ESBs can address interface issues for individual hotels, they are unlikely to be cost-effective unless they are either (a) used behind the scenes to support a specific subset of functionality (such as NEC’s check-in kiosk support), or (b) deployed across many hotels. There can be a nontrivial cost to deploy the infrastructure just to get started, and the connectors for each system must be developed or purchased.

A big advantage of ESBs for a hotel group is increased agility to support new systems. If a hotel company acquires a competitor that uses a different PMS than its existing hotels, for example, it can connect that PMS to its ESB once, and take advantage of the ESB’s preexisting interfaces to each of the other systems. While not a trivial process (or a perfect one), it is far simpler, faster, and cheaper than forcing all the acquired hotels to change PMSs (or central reservation or point-of-sale or any other system for that matter). It is also much simpler than buying or building new interfaces between the new PMS and all the other existing corporate systems. And if a hotel brand decides to replace one major system, it can plug the replacement system into the ESB, test it out on a few hotels, and then roll it out over time to other hotels at whatever pace suits it – there is no need for the dreaded “flash cut” where you try to move 1000 hotels to a new system all at once. Rather, the ESB simply needs to be reconfigured to point to the new system when a hotel is ready to switch over to it. The ESB can translate data from multiple PMSs (or other systems) into a common format and set of interfaces for handoff to other systems.

While ESBs at their core manage inter-system messaging, they can do much more. Because an ESB sees every transaction flowing between any connected systems, it can also store transactional or state history, which can be used for business intelligence, real-time dashboards, transaction logs, and similar analytics, combining data from multiple systems into a single view. Some ESBs, such as Ireckonu’s, define a canonical data model that allows data from multiple sources, such as different PMSs, to be intermixed even though data definitions may be inconsistent. ESB providers can also add significant business logic in support modules around the edges, potentially reducing the number of vendors needed to support a hotel, a strategy Ireckonu is following. ESBs are also particularly good at monitoring interface health; one ESB may be monitoring 1,000 different interfaces at a time, and it can raise alerts instantly if anything stops working or if unexpected errors occur. Some errors can even be self-healed by the ESB.

ESBs can connect any two systems that want to cooperate, but they are particularly useful for transactions where two or more systems need to accurately reflect the results of transactions that may be started, amended, or completed by one or both systems. Examples include posting of point-of-sale transactions to a PMS guest folio; synching reservations or group blocks between a central reservation system, sales and catering system, and PMS; checking a guest into a room and activating in-room devices like the telephone, TV, or energy management; or keeping track of housekeeping status changes that might be initiated either from the housekeeping system or the PMS.

The main limitations of ESBs are the initial infrastructure cost and development of the initial set of interfaces and associated business logic, and the fact that they typically require cooperation from vendors that are connecting to it. This cooperation may be satisfied by an existing API that is either published or made available privately; by custom interface development; or by a combination (as in where the API exists but may not handle certain variations in ways that suit the hotel’s needs). Where that vendor cooperation is lacking, other options may make more sense.

Event Streaming

‍A second class of solutions can be described as event streaming, which is where events in one system are passed as a “stream” of data to another system. Events may be sent individually or batched; they are typically converted to a standardized data model for archival storage, for passing along to analytics or business intelligence systems, or for conversion to data models used by other systems that will consume the data. This technology is still young in hospitality, with the only significant vendor being Hapi. But it is gaining traction, with Hapi deployed at about 5500 hotels in just a few years.

Event streaming platforms can handle many of the same tasks as ESBs and require less heavy lifting if the main requirement is simply to move data. While transaction processing across systems is possible and sometimes cost-effective, event streaming is less flexible for this than an ESB, which is natively designed for transaction processing.

Event streaming is, however, an excellent option when you need to move data between systems, and especially if you need to combine data from multiple disparate sources (such as PMSs or accounting systems from different vendors) and see it all in a single place in a consistent format. Hapi converts data from the producing systems into its own canonical format, which allows transformation from multiple formats into one. It can then send the resulting data to a consuming system, such as an enterprise business intelligence platform, in that format, or transformed into whatever custom format the receiving system needs.

Event streaming, similar to ESBs, can also be used to reduce the number of interfaces, particularly where real-time transactional integrity is not critical. If Hapi already has a connection to a particular software product, and that connection meets your own interface requirements, and your PMS or another core system is already connected to Hapi, it can often be a simple and inexpensive matter to connect the two systems. Even the first connection is typically much lighter weight than an ESB, simply because less infrastructure needs to be deployed to support it.

Event streaming is sometimes feasible for connections with vendors that don’t offer APIs, or at least ones that meet your needs. Many systems produce transaction logs that are stored in a file system or database that can be “read” by an external process that can then stream it to a system like Hapi. Others produce database snapshots or status reports containing relevant data; these can be fed into an event streaming platform, which can then compare each successive version to the prior one, detect any changes, and create a stream of implied events. For example, a PMS might be able to schedule an in-house guest report to be generated every hour and emailed to the platform. Comparison of two consecutive reports would enable it to infer the intervening check-in and check-out events and create a stream of them. You might not know the exact order in which the events occurred between the two captured reports, and you might miss situations where a guest is checked into one room but then moved to another one before the next report extract, but in many cases the result may be “close enough.”

Robotic Process Automation

While the name may sound scary, Robotic Process Automation (RPA) is a very simple concept. It is designed to automate tasks that must otherwise be performed manually; it does so by simply emulating the actions that a human would take. There are dozens of tasks in most hotels that are managed by a staff member pulling up information in one system, only to then retype that same information (or some minor variation of it) into another one. Or the information may already be in the other system, but some additional action might be needed based on specific criteria that the system can’t filter on.

A common example is hotels needing to validate or charge credit cards provided with reservations booked via online travel agencies. While the reservation is probably delivered from a channel manager via an API, the receiving PMS interface may not take all the necessary actions for the reservations that need them. The manual process might involve going into the PMS, filtering new reservations made via certain booking channels, pulling up each reservation in turn, and validating or processing the credit card transaction for each. Another example is the processing of virtual credit cards, which may only be honored if presented during a specific time interval and for a specific amount; the hotel may be unable to collect payment if it forgets to process it manually during the approved time window or does so for the wrong amount.

RPA has garnered a lot of interest in recent months, driven significantly by the “great resignation” of hospitality front-line staff. Manual labor is increasingly expensive and/or hard for hotels to get, and very few of the workers who are drawn to guest-facing hospitality jobs want to spend a lot of their work day reading a screen and performing repetitive manual tasks with a keyboard and mouse. The costs of labor hours, amplified by the constant turnover and costs associated with hiring and training replacements, can add up quickly for repetitive manual tasks, and for many tasks, RPA can be much cheaper.

As with ESBs, there are many generic RPA tools on the market, such as Blue Prism, Kryon, UIPath, and WorkFusion. These provide various forms of connectivity ranging from APIs and file transfers to reading screens or documents and emulating keyboard presses the way a human would. Applications are developed on top of these to solve specific problems such as those described above. Some larger hotel groups use tools like these and develop their own customizations. However, like ESBs, the entry cost is high, both in terms of licensing the underlying toolsets, and developing the expertise to customize them for specific needs. And while some of these companies do offer customizations for various common applications and vertical markets, none have ventured very far into the hospitality space.

For smaller hotel groups and even individual hotels, at least two recent startups, Aphy and Robosize ME (the latter of which you can see at E20X at HITEC), have developed specific toolsets for hospitality, as well as business models that offer RPA as a service, vastly reducing the entry cost and making RPA an attractive solution for automating many manual tasks. Some tasks can be automated for as little as a few hundred dollars a month, which can represent cost savings for tasks requiring as little as 20 minutes per day of manual labor.

RPA can solve the basic issue of transferring data from one system to another. However, it is not usually appropriate for high-volume activities that can be supported by an API, an ESB, or event streaming. Rather, it is most useful for edge cases that are not fully handled by the other options, or that require some cleanup work before or after. It can also be a solution of last resort when you need to connect to a legacy system that has no API, data extract, or canned report that meets your needs. In some cases, RPA may be only marginally faster than a human at navigating the various applications and screens, but it can cost significantly less, and enable staff to spend more time satisfying guests and less time doing drudge work.

Some of the interesting use cases that RPA from these companies can address for hotels today include:

• Prequalifying group RFPs by checking the PMS for sufficient guest rooms, the sales and catering system for meeting space, and the revenue management system for group displacement; and then rank-ordering RFPs for human response
• Entering guest details from the PMS into police reporting, tourism board, and similar databases
• Checking the heat or air conditioning status of a guest room before assigning it to a guest
• Loading corporate rates into distribution systems
• Augmenting synchronization of group blocks between a PMS and sales and catering system, where an interface fails to correctly transfer certain settings
• Identifying discrepancies between payments recorded in the PMS and in the payments back-end
• Processing no-shows in the PMS
• Extracting PMS data and uploading it to STR
• Auditing user rights in various systems against current employee lists, job titles, and roles to identify discrepancies
• Wholesale/FIT management in the PMS (reservation delivery, invoice uploading in Extranets, rate loading from contracts)
• Management of opening/closing of promotional rates depending on occupancy forecasts
• Automated job applicant resume/CV scanning

RPA can be difficult to visualize, because often everything happens behind the scenes and there may be “nothing to see.” Vendors can provide visualizations of certain RPA tasks through video screen captures showing information being pulled up, transferred and processrf, and these can be helpful, but may not be able to show you the specific use case you’re interested in. One example of Robosize ME processing virtual credit cards in Oracle Opera v5 can be found in a Youtube video here.

Conclusion

There are many options for connecting systems, and each one has sweet spots as well as situations where it is overkill or doesn’t really meet the need. If I had a complex portfolio of systems to orchestrate, I would absolutely be considering using all four options discussed here to address different pieces.

To decide what makes the most sense for a specific connectivity problem, I recommend working through the options in the order they are presented here. Start with APIs and move down the options in sequence, eliminating ones that don’t meet your needs at all or are too expensive. It often makes sense to use one of the tools mentioned earlier to handle the bulk of the work, and ones lower on the list to address some of the less frequent or edge cases. For example, an API (with or without an ESB) or event streaming solution might be the best option to deliver reservations from a Central Reservations System to a PMS, but still leave certain tasks (such as credit card validation) undone. If these require significant manual rework, they may be a good candidate for RPA.

In an ideal world, APIs would meet all our needs and be cost-effective, and could be effectively managed and monitored with an ESB. But sadly, APIs are often lacking or costly, and if too many of them are inadequate or the portfolio is too small, then an ESB may not solve enough of the connectivity problem to be worth the cost. However, by combining the right elements from the toolsets of APIs, ESBs, event streaming, and RPA, most connectivity problems can be addressed to reduce the need for manual tasks, reduce guest disservice from connectivity glitches, and save labor. All of which are good things!

‍