Interfaces come in all shapes and sizes. They communicate one-way or two-way, via a network, a serial cable, flat files written to a directory, or a direct database connection. Some use proprietary messages, others, messages built on pre-defined industry standards. They can be heavy- or lightweight, synchronous or asynchronous, dedicated point-to-point, or a part of a Service Bus. In many ways, they are built like human relationships. In the beginning, it is a beautiful partnership between two parties, created based on the needs of both sides at that particular time. Assuming neither side makes any changes, this relationship might continue in perfect harmony almost indefinitely. But, just like human relationships, parties on both sides can, and should, change. And when they do, that original interface may no longer meet the needs of both parties. At that point, everyone must agree to change together to keep the relationship viable. Unwillingness to change on one side hinders the growth of the other, or the forced growth of one may ruin the relationship completely. Given all of this, it is easy to see why people get nervous about interfaces and why the process of setting one up, or updating an existing one, can be expensive and time consuming.

But it doesn’t have to be. To understand why, it is helpful to first discuss how we arrived at our current situation.

Interfaces today are developed to serve a very specific purpose – for example: this POS needs to post a charge to that PMS. To effect this interface, one must purchase interface software, and annual support, from both companies. Once installed, these interfaces create a static and unlinked copy of important data in both systems. This requires more management, more effort to keep data in sync, and complex reporting to provide useful insights which include important data from each system. Even worse, these interfaces are one-to-one, meaning if you want to notify three different systems when a particular event occurs, you need three different interfaces, each one suffering from the same limitations described above. And it isn’t just changes to an actual interface, but also changing out an interfaced application, which then requires changing out every interface to that application. All of this makes change difficult and expensive.

But why are we still living in that interfacing world? During the HFTP Annual Convention’s “State of the Industry: Technology” session, the question was asked, “Are the issues around our industry’s lack of innovation the fault of our vendors failing to innovate, or are we, as hospitality professionals, to blame for not pushing them to innovate?” I think it is both. Clearly, we look to our established vendors to create the things we tell them we need, and even things we don’t yet know we need, but no vendor is ever going to be able to do everything for everyone as fast as the industry wants or needs them to.

So how do we fix this? First, we need to stop caring about message formats, and stop installing only static one-to-one interfaces. Second, we need to change the way we think about how applications are built.

The use of an Enterprise Service Bus (ESB) solves the one-to-one problem by allowing systems to “publish” and “subscribe” to specific events.  It also solves the problem of requiring a particular message format and means of delivery; it will handle all translations and communication between all connected systems. For example, when a guest checks in, the PMS fires a Guest Check-In message in its preferred format to the ESB. The ESB notices that the Energy Management System and In-Room Entertainment system have subscribed to these events, translates the message into the format those applications prefer, and delivers the message using their preferred means of communication. The applications don’t know or care about each other or what their messages contain. They just know what types of messages they send and receive, and how they send and receive them. The ESB does all the work for you and allows you to hot swap applications without the need to notify any of the other applications with which it interfaces.

But the ESB doesn’t solve the root cause of the interfacing problem, that is, how our applications are designed to interface. Created for a specific purpose, they are built to read and write specific data only, send and receive it in a specific format, and do so only when specific criteria are met. Innovation is still limited by what a particular application allows. This means the ability to plug an application into a service bus is limited as well.

All software developers should be building applications that can be extended by third party developers quickly and easily. This is where startups and third party developers can – and do – provide a huge benefit, and resistance to this model is where both we and our vendors have gone wrong. Both modern web applications and advanced enterprise applications are benefiting from Application Programming Interface (API) driven development. In this model, individual components of the system are not bound to one another, but rather work together by calling pre-defined APIs. Why? Modularization. Building or changing individual elements doesn’t require learning all the details about the underlying architecture – or even the programming language – of the system. You simply need to know the API and develop to it. This speeds development, reduces development cost, and allows for easier, more cost-effective hot-swapping of components. An added benefit to this model is that third party applications can also take advantage of the APIs to further extend the product.

Yes, this requires a fundamental change in the way some software developers do business and how they handle development. But this concept is no longer ‘the future’, it is the ‘here and now’.

There will always be a need for one-off dedicated point-to-point interfaces in very special cases or in smaller environments where an ESB does not make financial sense. But the way we think about interfacing and integration needs to change. Software creators need to take a lesson from the successes of Facebook, Apple and Google; they welcome third party developers who create a much larger and more valuable ecosystem on their platforms. This provides extendibility and rapid development of new functionalities these tech-based giants might not have the time or desire to create themselves.

As technology professionals in our industry, we should push for this, and embrace an open interfacing model, removing the barriers encountered by many startups who want to make a difference in our industry. A vibrant startup community not only helps speed innovation, but also adds value to the established software providers by extending their products – making them more beneficial to current and potential customers. The larger ERP systems out there have figured this out, as have the newer platform-based applications. It’s time our larger software vendors do the same by adopting – and supporting – a more open integrated world.


Author Lyle Worthington

More posts by Lyle Worthington

Leave a Reply

Lyle Worthington