A universal model for hospitality data

Expressed simply

I don’t want to baffle anyone with unfamiliar terms, so just to be clear ‘domain model’ simply means a way of describing the entities like rooms, profiles and reservations that exist in the hospitality world or domain, and the relationships between them. These can be expressed plainly, for example:

“a property is a general term used to describe a hotel, apartment, cruise ship or other similar hospitality establishment”

and

“a property group is a group of properties belonging to the same brand or owning company”.

You could express this in words, like here, or visually in a diagram where you might have a box marked ‘property’ and a box marked ‘property group’ and a line joining them that says something like “may belong to…”.

Data schema

Or if you prefer, you could describe it in the form of a data schema, rather like the YAML used by the HTNG Express workgroup - this, by the way, is quite human-readable, you don’t need to be too much of a geek to understand it. Here’s a snippet:

    Guest:
      title: Guest
      properties:
        firstname:
          type: string
        lastname:
          type: string
        profileId:
          type: string

The point I want to make here is that how it’s represented isn’t that important, it’s technically simple, what matters is the content.

Content

You see, anyone involved in the industry, or anyone who’s done very much analysis and modelling, will know that these things are not that straightforward.

For example, I had to think carefully about how I described a property group just now. Is it an organisation, or is it a brand within an organisation, or maybe it’s based on geography? Take the Accor Group. They have so many properties in their portfolio that their brands are themselves grouped into categories, with thirteen brands in the Premium segment alone. So if you were modelling the Accor Group then you might want to have brands within brands. But what if say they have three of their Paris properties that share the same PMS and want to be in the same grouping, in that case you might want to link them by geography rather than brand, or maybe both. This is just one small example of how care is needed when designing a domain model if you want it to be universal.

Rewards

But, just think of the rewards!

Imagine that we had a universal definition for reservation as a single packet of data. It would be a simple matter to present it in the format your customer or partner prefers, just as I am writing this article in Pages but can easily export it to PDF, Word or HTML. The power of a universal standard is that whoever I give that data packet to, they can plug it into their own system seamlessly and have the same understanding of what it means.

Limiting constraint

I would suggest that it’s no longer protocols or data format that’s the limiting factor in interoperability, it’s the definition of the data, i.e. its semantic meaning.

Just to properly illustrate this point, let’s take a closer look at that one common piece of hospitality data, the reservation. This is in fact the first domain entity that the HTNG Express workgroup decided to work with, using their agile, bottom-up approach.

I took two other sources of openly documented, publicly available reservation data for the purposes of comparison, the first from Impala and the second from Guestline [disclosure: I wrote the one from Guestline]. I could have taken samples from other sources, such as Hetras or even the current HTNG Web Services standard, but I just happen to have some knowledge of the first two. I’m confident the conclusions would be the same.

Guest comparison

Now, I want to see past the fact that all three are expressed in slightly different ways and look instead at the actual content of the data schema.

I only need to take one small part of the reservation data packet, because the same situation is repeated in every part. If you want to do more of a comparison yourself, just follow the links, all the data is there. Let’s take the example of the guest used at the top of this article, how is this data represented within the reservation packet across the three implementations?

In HTNG Express, we have a ‘principal’ guest, with three fields firstname, lastname and profileId. ‘Additional’ guests are stored in a separate structure. In that case we have firstname and lastname only. Guest preferences are stored in a separate part of the same reservation packet.
In Impala, all guests are referenced together as a set of guest IDs, with no other information in the reservation packet, further information is available through a separate look-up.
In Guestline, all guests associated with the reservation are referenced together, within the reservation, and for each one there is a range of information including name, gender, loyalty ID and a profile reference. Guest preferences are stored in the profile, so a separate look-up will be required to fetch that information.

Now, whilst we could argue about details, the approach is perfectly reasonable and logical in each case. But what’s significant is how already the way the data is structured is significantly divergent between each API. Each party has a different model for representing the same data.

Booking reference comparison

You can see the same thing even with something apparently simple like booking reference:

In HTNG Express there is no single booking reference but a collection of name-value pairs.
In Impala there is an ‘id’, a ‘reference’ and a ‘bookingSetId’.
In Guestline, we have a ‘BookRef’, ‘RoomPickID’, ‘BookRefRoomPickID’ and ‘MultiRoomReference’.

You can just imagine how the differences multiply when you come to the complicated area of room rates!

Conclusion

I’d be interested in what industry experts think, but wouldn’t it be worthwhile for the various parties to sit down together and agree a common way of describing the data, i.e. a universal domain model? I’m not convinced that another API is going to change anything, except to make the integrations landscape even more fractured. I also think that such an initiative has to be led by a PMS company, as they are at the centre of hotel operations, and I suspect that guest services companies, who are on the periphery of the hospitality ecosystem, may not always appreciate all of the complexities of the PMS data model (I say this from experience, having worked for both types of company over the years).