HTNG Web Express - are they missing a trick?

Web Express

HTNG (Hotel Technology Next Generation) are running a workgroup at the moment, developing a new hotel integrations standard which they’ve dubbed Web Express.

The ‘Web’ bit is somewhat redundant but the ‘Express’ bit gives a clue to their intentions, namely to create something that’s quicker than what came before.

Now, what came before is a bunch of slightly obtuse XML-heavy specifications, based around what was called Web Services, this goes back quite a few years now to the time when it was an original idea to get systems to communicate using web technology, in other words based on the HTTP standard that underpins web communication. In that era, we went from the web being purely a place full of websites serving pages to human readers, to a situation where servers could also exchange information to machine readers. And XML was the flavour of the day.

Now, I’m conscious that my tone already suggests I’m somehow denigrating this effort, which I’m not, nor the technology, in fact I played a small part in it myself, as I was a member of the in-room technology workgroup that created the standards in the first place.

At the time, the hospitality industry was desperate for some standardisation and this was probably the number one area where hoteliers wanted tangible outcomes. The incentive wasn’t sufficient for vendors on their own to take this initiative, as each one invariably had their own interface specifications which in some cases became de facto standards. The Micros-Fidelio (now Oracle Hospitality) ‘FIAS’ protocol comes to mind - I’m thinking here of the PMS side of operations rather than the distribution side.

Prior success

On reflection, I would say the HTNG specifications were partially successful. They did indeed deliver quite a few specifications and considered it job done, they then turned their efforts more to other areas.

However, like a lot of industry standards, it did take rather a long while to produce them, even longer to get companies to use them, and of course IT moves very quickly, so no sooner were they starting to be adopted than the technology was out of date.

My last serious effort in the area of hospitality integrations was when I took responsibility for the API Platform for cloud PMS provider Guestline, based in the West Midlands but with an ever expanding international client base (a fine group of people and a lovely part of the country, so a quick shout out to my old colleagues!).

This was only a couple of years ago but what was interesting to see was that the integrations ecosystem was just as diverse and non-standard as I remembered. Adoption of HTNG standards on the distribution side of PMS was universal, these were standards leveraged from OTA (Open Travel Alliance), however on the operational side of PMS it was very patchy and it was still possible to come across plenty of users in 2019 using that old FIAS staple.

But now of course you had all those new players who were expecting to communicate with modern REST APIs, which of course was the technology that replaced XML and SOAP (SOAP is the protocol underpinning Web Services).

This then is the context in which the new HTNG workgroup was created.

Easier and simpler

The ‘express’ in the name doesn’t meant that the interface itself will be physically faster, instead that it will be easier for people to use and therefore quicker to get going with it.

Dmitry Koltunov from ALICE is chairing the group, I believe, and his aim is not only to create a new, easier to use and more modern API (the modern name for a computer interface) but also to create a simpler process for on-boarding.

All of this is laudable, and in fact echoes my own aims at Guestline, where I created a new API Portal and streamlined the vendor on-boarding process, whilst designing a REST API to replace the ageing Web Services interface.

The data model

However - and this is where I think they might be missing a trick - I don’t think the physical interface technology itself is the issue any more, if it ever was. I think the issue is one of data representation, more specifically the data model itself.

This is where an organisation of representatives from all the major hotel groups and all the major hospitality technology vendors can make a difference. Whether the data is in XML or JSON is not so much the issue, nor whether it uses this protocol or that protocol, in any case those battles are a thing of the past as we now all use HTTP as the standard protocol and HTTP verbs as the interface instructions, what matters is the data model.

I’m talking about a consistent, industry standard way to represent hospitality data. I mean, surely a room is a room and a guest is a guest, right? Well, in practice there is huge variety to how these things are represented, especially when you take into account all the special cases. What is the relationship between a guest and a profile? What about a company making a corporate reservation? And a travel agent or other agency making a reservation on a person’s behalf? What about room suites? How do we reference room and hotel attributes?

REST stands for REpresentational State Transfer, and the origin of this is quite frankly difficult to understand, because it was created by an academic for other academics (you can read Roy Fielding’s paper here => REST), but in a nutshell it means that there is an abstract concept call a resource, which is equivalent to a web page or say an image but actually it can be whatever you dream of, these are represented like web page URLs and the protocol provides a simple way to do the equivalent of read, write, update and so on upon those resources.

What this means is that design of an interface now becomes design of resources, which are abstract concepts. Room could be a resource, and guest could be a resource, and reservation could be a resource.

A universal model

The point is that at one time designing an interface meant designing a protocol - this is one of the many things I did when I worked as a Software Manager some years ago now. But now it means something else - the technology has disappeared and we are left with the abstract art of domain modelling. Domain modelling effectively means defining those abstract resources and their relationships.

And that in my opinion should be the focus of any efforts by HTNG to improve interoperability between hotel technology providers and their hotel customers - they should attempt to create a universal domain model for the industry.

This would be independent of technology, so it wouldn’t matter if REST and JSON falls out of favour, since technology is always changing (already GraphQL is changing REST to some extent).

Don’t think this is a trivial exercise, because it isn’t. It’s quite possible that this kind of model doesn’t exist even within individual PMS companies. Which is why it’s so valuable!