Eine praktische Einführung in die MACH-Architektur und "Composable Hospitality

If you haven’t heard the acronym yet, the forces of digital transformation in hospitality will certainly lead you to hear about and consider a MACH architecture for your hotel group's digital ecosystem. For accommodation businesses and their tardiness to innovate, it’s still a matter of “IF” they adopt it. For other industries like retail or banking, it’s rather a question of “WHEN”.

The rise of this term comes from eCommerce companies realizing that their monolith systems couldn’t keep up with digital customer expectations. All-in-one suites, which were the only viable options for them before the rise of cloud technology, stopped being the safest and most scalable option once the industry started booming at a fast pace with new factors coming into play: increasing data regulations & restrictions, growing user experience expectations, the necessity for omnichannel sales and more. Players like commercetools or Contentful saw an opportunity and emerged as market leaders in their respective fields.

Why mention these factors? Because you can recognize the same patterns in the accommodation space, with legacy PMSs making most forward-thinking hoteliers run away. Legacy and monolithic systems come with so-called technical debt (bad or obsolete software development) and all their elements being tightly connected and dependent on each other, which hinders 3rd party integrations and change.  This is where property management needs to move from technology-centric to platform-centric.

So what is MACH architecture?

MACH stands for Microservices, API-first, Cloud-native, and Headless, and to fully grasp its pros and cons, we need to look at each aspect individually. Still, to provide a general idea, it’s fair to say that it focuses on composability that allows you to shape your entire IT ecosystem in line with your business needs and characteristics. 

M for Microservices

The first letter of MACH implies “microservices”. What does that mean concretely? In its simplest form, it means that separated applications (aka microservices) within the property management platform, as an example, are independently developed, deployed, and managed. A single microservice is thought to perform a single function such as, in this case, availability/rates/inventory, finance, payments, and potentially more depending on the nature of the platform. 

If we take a helicopter view and look at it from a wider hotel tech stack perspective going beyond property management functions, each 3rd party application around the PMS, such as a channel manager, guest portal or revenue management system, is also a microservice of its own.

Simplified view of Vagabond Club’s microservices architecture

These micro-applications communicate and exchange data, forming a complete application, platform or tech ecosystem, but remain separate items with distinct API points. The beauty and main benefit of this is that a malfunction in one micro-application should not disrupt the entire application. Another way to look at this would be that you can swap one microservice or application with another if you are not satisfied, without causing any issues or having to bring changes to another service in the ecosystem. (e.g. changing your RMS if you would like to try another one).

A for API-first

Most modern PMS you will find on the market today are all cloud-based and accessible from any browser, and generally offer a packaged experience or solution.

Most often, if not in all cases, these companies add APIs on top of their platform. This can help in areas of automation or integration, and enables you to access some of the underlying functionality of the software BUT, and this is the tipping point, not all of it.

 Apaleo’s 233 API triggers, actions & searches are exposed & available to automate workflows thanks to API-first

An API-first approach, on the other hand, flips this paradigm around. API-first architecture puts APIs at the core of the foundation, instead of pre-built solutions or experiences (which only fit the client aka software that it was intended for). 

Example of automation: Send out Apaleo's Payment Link via Microsoft 365 Email

API-first ensures that ALL of the functionality and logic inside the platform is accessible for use through the APIs. The main benefit of it is the unlimited flexibility to make the platform behave the way you want it to rather than being dictated by the opinion of the company developing it. In flexibility, you can think of, for example, extending the PMS to your needs as an accommodation provider with a specific concept.

C for Cloud-native

For several years now, "cloud" has been an overused and overlooked term in the hospitality industry with many players appropriating it. In reality, only several solutions are cloud by design.

Cloud-native means that the development and delivery happen in a scalable cloud. The term refers to software hosted in the cloud with no availability for an on-premise option. 

This model doesn't need any installation or maintenance as updates and version upgrades happen seamlessly without customers’ involvement, downtime, licensing costs, or any other fees. Cloud infrastructure provides sophisticated scaling capabilities to meet growing demands that occur over time. 

H for Headless

Opposite to the three terminologies introduced before, headless is rather a potential result, or better said, a benefit of these three technical capabilities.

Example of StayKooooK developing an “operational head” on top of Apaleo APIs to offer a lean & easy-to use interface to its staff

A headless architecture is the fact of decoupling the frontend and backend of the platform, providing the ability to create personalized user interfaces and experiences. This type of architecture creates a limitless array of possibilities in terms of customizations, enabling businesses to build a platform that perfectly aligns with their concept and needs. As an example, hotel chains with high technology ambitions and the right skillset could imagine, adding, removing or altering particular pieces of the PMS' user interface to create one, that is unique to their operations.

A new concept for the accommodation industry

With Apaleo’s aligned product principles with MACH and its headless possibilities, a new and disruptive concept is coming to life for our industry: composable hospitality.

Composable hospitality (def.): Composable hospitality is a term for software architecture, which separates the UI (frontend) from the business logic (backend), and provides the possibility to choose the best-of-breed technologies to build a flexible hospitality stack. The software communicates via API, and the particular solutions can be replaced without impacting other parts of the ecosystem.

Stay tuned…