GUESTS, STRANGERS, ENEMIES

Hospitality is an ancient business, but a nuanced, almost oxymoronic one as well: the term derives from the Latin roots hospes/hostis, meaning (ironically enough) both guest, stranger, and enemy. In the French acceptation of the term, un hôtel is a building that provides care, rather than accommodation, and here is why semantically distant concepts such as HOSpital, HOSpitality, and HOStility, sound so phonetically similar.

13 CENTURIES OF HOSPITALITY

According to the Guinness Book of World Records, the first (real) hotel was opened in the 8th Century while, for most of the Middle Ages, religious monasteries and abbeys played the role of alternative accommodation ante litteram. Hospitality, as we know it today, however, is a relatively new and fragmented industry: it was not until the 15th Century that inns were required to keep guests' registries, and the original star-rating classification only dates back to the 1950s. Thomas Cook, a name today infamously known for the failure of the company by the same name, by the 1800s was just a man driven by his (heavenly) faith in a Baptist God, and his (more earthly) urge to arrange travels in exchange for money.

A DATA INDUSTRY

Yet the need to centralize, connect and manage the massive amount of data that our industry produces every day* is as old as Caesar himself. Make no mistake: our industry is no (longer) a people industry, but a data industry and the first attempts to manage this massive volume of information appeared as early as WWII, with Don-Draper-ish-named technologies such as the Reservec, the Deltamatic, the Apollo, and the Reservisor. What happened over the last few decades is recent history, and, if you want to get needy greedy with all the detail, make sure you read Dennis Schaal's 40,000-word-Bible-on-the-topic, or the less intimidating e three-part-article by Jason Price (Part I, Part II, Part III).

* To put things into perspective: at any given time, airlines process the data equivalent of three million books

THRU' THESE ARCHITECTS' EYES: WHERE DO WE GO NOW?

Flash-forward to 2019 and an oversaturated industry: currently, HotelTechReport lists some 70 different software categories, spanning from A (analytics) to W (website live chats). Since all these platforms need to coexist and seamlessly interact, it's no surprise that, over the last few years, much attention has been put in software architectures. When, at the end of the '90s, I started working in hotels, the term architecture had more to do with the actual construction of buildings than with the underlying hotel tech stack. Two decades later, by contrast, encountering technical terms such as cloud-native, micro-service, or open APIs in the tag of any PMS' brochure is quite common. But what does it exactly mean for the industry?

INNOVATION, OVERCONFIDENCE, SPECULATION

Remember the dotcom bubble of the '90s? It was driven by market confidence (at best) or market speculation (more likely), with venture capitalists eager to throw money at whatever company with a .com suffix in its name. In 2002, finance professors Cooper, Dimitrov, and Raghavendra Rau published an intriguing study titled "A rose.com by any other name": the paper analyzes the "striking positive stock price reaction to the announcement of corporate name changes to Internet‐related dotcom names." "A mere association with the Internet," the authors wrote, "seems enough to provide a firm with a large and permanent value increase." As history has a funny way of repeating itself, it is not so far fetched to foresee a similar bubble in the cloud/microservice/open API's tech world today. Skeptical? According to Phocuswright's annual State of Startups Report, a striking $19.7 billion have been raised by travel startups over just one decade, so my question stands: are we innovators, overconfident, or just greedy speculators?

STRATEGIES AGAINST ARCHITECTURE

Over the last decade, software started evolving from their traditional, monolithic architectures to more flexible approaches, made possible by (amongst other things) APIs' adoption. In an old article, I described Application Programming Interfaces as "a way for applications or programs to connect and communicate fluidly with each other." And I still stand behind this definition. It is an oversimplification, of course, but, as author Malcolm Gladwell elegantly puts it, "If you're in the business of translating ideas in the academic realm to a general audience, you have to simplify." The downside of oversimplification, however, is that it can be (and often is) used to confuse the general audience even more: understanding how APIs work can be challenging for the average hotelier, and vendors know how to exploit this lack of tech-savviness. Pars Pro Toto, the Latins (again) would say, allowing articulated concepts, such as open API architecture, to be randomly used out of context in shady sales pitches. So what do we mean with open API, and why does it look like the proverbial oasis in the desert?

IS VENDOR NEUTRALITY ACHIEVABLE? THE MIRAGE OF MARKETPLACES

Tech agnosticism creates the ideal environment for innovation to flourish, and not only in travel. I know it, vendors know it, but hotels often don't. Hoteliers should be able to pick and test their tech stack freely, rather than being bound by their existing technologies. In a perfect world, therefore, our industry (any industry, for that matter) should (and could) be a plug&play one. Wanna try out that cool new RMS? Just subscribe to the free 30-day-trial, plug it into your PMS, and -if you're not happy about it- pick something else and move on. That's the whole premise/promise of marketplaces. "The BookingSuite App Store," you can read on its official website, "makes finding the right hospitality apps quick and easy," but does it? Theoretically yes, but practically?

THE 21-DAY-INTEGRATION PARADOX

A few days ago (meaning October, AD MMXIX), a client of mine received an estimate from their PMS. The document stated (literally): "21 days (8 hours/day) will be needed for installation and configuration." Honest to God, no typos here: twentyone days eight hours a day. At around 100€/hour (and, of course, travel expenses, food, and accommodation NOT included), this implies that installing the updated version of their property management system would cost the hotel 17,000€, and one full month of work. Now, imagine you've just downloaded the Instagram app on your phone, you hear a knock at your door, and it's Mr. Zuckerberg himself, sleeping at your place and eating at your table for the next four weeks, filling the apartment with servers, so that you can upload selfies of you and your cat. And, wait, I almost forgot: billing you almost 20k€ in the process. Yup, that's the mess we got ourselves in, and the worst part is that hotels kinda expect and quietly accept this robbery. We became passive-aggressive-vendors-dependent-junkies. But guess what? It's rehab time.

ENTREPRENEURIAL MYOPIA?

Open API adoption has the potential to create synergistic value across platforms by enabling developers to use data or functionality from other software solutions. It is an elegant way to say that, without APIs, innovation simply stops. So, why is there so much resistance? It's plausible that companies that started operating in the '80s and '90s suffered from some degree of innovator's dilemma, and now they're stuck with unscalable monsters of code. On the other hand, most of these companies already disappeared, and the early adopters that aren't extinct yet (on the contrary, they adapted to a new, Darwinian industry) are so rare that I can probably count them on the fingers of one hand: Oracle (formerly Fidelio), Amadeus (formerly Newmarket), MSI, and just a few more. But for all the others, the countdown to extinction has started. Did they lack the vision to reinvent themselves? Or they simply try to keep afloat until the boat, ultimately, sinks? It is David and Goliath all over again, with innovative startups on one side vs. big corporation on the other. But is it? Well, things are a little more complicated than that, and when it comes to API adoption, there are a lot of gray areas and nuances.

MARKET FRAGMENTATION

One of the main challenges in API adoption relies on our industry software space's fragmentation. If you ever asked yourself how many travel tech vendors are too many travel tech vendors, I have an answer for you: cut the number of travel software in half, and you'll still have an overcrowded industry. In this scenario, supporting all (or even most) of the APIs out there becomes virtually impossible. "The average hotel," Sciant's Travel and Hospitality SVP, Stephen Burke, stated, "often has more than thirty disparate systems, which - in one form or another- need to communicate with each other." Integration, never forget, is not just about SHARING data (that's relatively easy), but about CONNECTING the systems that actually hold the data. This connection does not only provides huge efficiencies of time, money, and efforts but is often key to their very ability to function. The perfect example of this virtuous circle of platform interaction are Revenue Management Systems: "a modern RMS," Burke continued, "is not only consuming historical and current reservations and folios from the PMS, but it also needs accurate data from the rate shopping system, market benchmarking system, flight data, event data, and weather forecast data, to provide the most value." Think about Atomize: they recently broke the news with the launch of the industry-first real-time price optimization feature, which can algorithmically calculate the optimal rate and push it back to the PMS through a two-way connection. Do you see where I'm going with this? No PMS integration, no real-time optimization. That is why outsourcing the more challenging connection tasks to marketplaces and integrators is becoming more and more frequent.

OPEN ≠ FREE

Now, there's a semantic issue with the term open when it comes to APIs, since it is not synonymous with free. For most of the '80s and'90s, without proper, standard, shared protocols, proprietary interfaces proliferated, leading the industry into a dangerous, precarious position. As properly articulated by HAPI Cloud's CEO, Luis Segredo, most software solutions DO, in fact, provide open APIs, yet these APIs do not conform to any standard, resulting in a "need of custom development and, consequentially, certification charges." Open does not mean free, and that's a pretty fair statement. Yet the access to API could (and should) be available to everyone. The upfront cost is, to paraphrase Martin Soler, almost "a detail," as the main costs will likely hide in plain sight: just think about the certification of the API usage. APIs (open or not) demand resources, as they need to be updated, appropriately documented, and continuously debugged. Unless two systems - say a PMS and a housekeeping platform - speak the exact same language, to make them communicate to each other, one party still will have to code, even if the systems both offer open APIs. The bottom line is: If two systems are exchanging data, then someone had to write an interface. Moreover, APIs consume resources on the server infrastructure, and either there's a limited amount of them or they cost money. It's not just writing the code that costs money, it's also running the integration. So, if APIs should not be free (and I agree with that), at least there should be a (fair) price tag on them, as overpricing API access -in the end- just kills innovation and harms the whole industry.

HEY, DADDY-O, I DON'T WANT TO GO DOWN TO THE BASEMENT: THE CURSE OF LEGACY SYSTEMS

But, wait, there's more: on-premise deployment of most vendors' technologies makes integrating different solutions via APIs even more challenging (and, in some cases, impossible), so there is no proverbial easy way out here either. That being said, the problem with closed APIs starts even before the open/free semantic ambiguity or the rise of cloud-native systems. The central problem is that APIs have been mostly unavailable in our industry (mainly because of legacy technologies, never forget), and, when they did exist, providers did their best to restrict access by putting hyper-complicated (yet, quite weak) reasons why disruptors couldn't get access.

THE QUEST FOR STANDARDS

Truth to be told, over the years, there have been some (partially) successful efforts to agree on industry standards: just think about the great work done by associations such as Open Travel Alliance or HTNG. Douglas Rice, Founder and CEO Emeritus of the latter, highlights how HTNG was responsible for (among many other things), the creation of many standards that are still nearly universally adopted by major PMS, SPA, golf, and activity vendors to this very day. Yet, ultimately, this is the typical DVD vs. LaserDisc situation: standards are mainly settled by market needs, rather than by superior technologies. In any industry, specific standards do ultimately prevail because they guarantee the best commercial advantages for both developers and end-users. Simple as that. Nevertheless, standards ARE needed, now more than ever. API adoption can enable superior architectures, yet all of the software would have to be designed to use them consistently, or we'll end up with even more data discrepancies. By removing barriers to API adoption, we could create a more innovative industry, as most ideas today remain at their larval state simply because connecting to a PMS is still an expensive, complicated, and lengthy process. And, even though (understandably) vendors develop their code in response to customers' needs, rather than by following shared guidelines, integrations could (and should) not be so damn challenging.

THE DAYS OF LEONARDO DA VINCI ARE OVER, OR ARE THEY?

This leads us to another central node: which vendor is in charge of what? During a conversation I had with Rice, he asked me a Zen Master's question: should it be the PMS or the housekeeping system that manages the housekeeping status of guest rooms? Twenty minutes of mindfulness later, the enigma still rang in my ears: true, most PMSs offer the feature, yet it's usually a basic version, to the point that some hoteliers with more sophisticated needs may prefer buying a standalone housekeeping system with advanced capabilities. And, exactly like in Zen practice, there is no right or wrong answer here. The obstacle simply relies on the lack of a mutual "agreement" upon which software (PMS or housekeeping system) ultimately "owns" the room status (occupied, vacant, clean, dirty, etc.) and, consequentially, which one is allowed to change it and override it if and when needed. This communication breakdown can create a vicious circle, where one system tries to change the room status while the other disagrees. The problem here (and I completely agree with Rice on this one) is often due "the monolithic architecture of the PMS vendors, and their business desire to sell an inferior module to captive customers rather than to let them choose the best-of-breed." So, in the abovementioned example, if the two systems fail to agree on how to manage room status, the PMS vendor with inferior functionalities may -paradoxically- end up winning the argument, because the API, even though implemented and functioning, will not deliver the value of true integration.

INTEGRATIONS FOR CA$H

Last point, and let's not be naive here, nor politically correct: providing access to APIs remains still a significant source of revenue for many vendors, so the line between the technically impossible and the commercially unprofitable can become blurred quite quickly. Vendors have relied upon integration fees as a revenue stream for decades, and turning the Status Quo upside down now may be difficult, if not impossible.

PUBLIC VS. PRIVATE

What makes an API truly open? In a word: its accessibility. Public APIs are published, well-documented, it's easy for developers to sign up for a testing sandbox, and (in an ideal world) do not require vendor certification, as they have been originally built to be self-protecting, and internally tested for all the possible evil-terminator-rise-of-the-machines scenarios. Is this the case? Far from it. "Public APIs," apaleo's CMO, Margaret Ady, highlighted, "are awesome, but basically no one offers them: a lot of vendors pitch open APIs, yet you still, somehow, have to pay for access." And the main cause is rarely a technical one, rather a combination of commercial, political, and economic ones. Vendors' greed seems to be a more concrete obstacle to mainstream open API adoption than technical limitations.

WHEN HISTORY REPEATS ITSELF: WHERE WERE WE 15 YEARS AGO?

Ever heard about that company "specialized in providing systems integration and automation solutions for the global hotel and travel industries?" You should have, as that company "has developed reliable and scalable integration solutions for many of the leading hotel companies such as Starwood, Sonesta, Millenium-Copthorne, White Lodging, Holiday Inn, Melrose Hotels, Auberge Resorts, Manhattan East Suites, Arp-Hansen and many others." That's pretty rad, isn't it? So you guess we're talking about some cool, disruptive, startup, right? Wrong. Very wrong. I quoted literally from a Hospitality Net article dating September, the 4th 2002. Twenty-freaking-oh-two: the year when Nokia sold 15 million 6100 phones and Elon Musk officially became a U.S. citizen… We are a decade and a half down the road, yet the hotel technology industry is still facing the same fundamental challenges that NoBarriers (that's the company) was attempting to solve in '02. What problem? As Cendyn's CIO (and former NoBarriers' CIO), Piers Hughes, pragmatically puts it: "that PMS connectivity is key to making any hotel technology work effectively, yet it is still a challenge to achieve it." The bottom line is that, although open APIs are becoming in vogue and new standards and easier messaging methods now exist, fundamentally we are still seeing the same challenges we faced in the early '00s, when start ups like HubX and HBSi were coming on to the market. If you check the Sciant's about us page, you'll be welcomed by the core values of the company: "Sciant develops technical solutions (...)
and forms robust and compliant integrations and interfaces
, for new digital platforms and legacy systems." Sounds familiar? It should, as these guys are fighting the same old battle NoBarriers fought, almost two decades later. Quixotic? Maybe, but the "enemy" has strongly weakened over the years, so I remain (relatively) optimistic.

CONCLUSIONS

The bottom line is that we may never get to a (truly) open industry, and that's fine too. Still, if we could at least reduce the number of commonly used APIs (and this is realistically doable, as long as the dominant vendors enforce their preference on just a few partners, so that their APIs become commonly supported), we could -at least- make the life of tech disruptors and hoteliers easier. The future, to be honest, does not look so grim, and even major vendors are now exposing open APIs as well as new integration platforms that normalize the feeds from multiple PMSs and expose them in an open, modern fashion. Sure, for players such as Oracle, the cost of its core product increased, as the company lost a significant, steady source of income that was integrations, but -in the long term- this may be the best (if not the only) approach to sustain profitability, scalability, and innovation. Is it going to be an easy journey? Of course not, but, to quote a great man: "is simplicity best, or simply the easiest?"