In den letzten Jahrzehnten hat sich Client-Server-Architektur für die Reisetechnologie als der weltweit vorherrschende IT-Standard etabliert. Doch wenngleich diese Methode die Grundbedürfnisse der Branche seit vielen Jahren befriedigt, ist sie zugleich für ineffiziente, schlecht skalierbare Systemen verantwortlich, denen es an Agilität mangelt, die heutzutage im sich schnell veränderlichen Reise- und Tourismusgeschäft erforderlich ist. Während Verbraucher und Unternehmen genau wie die übrige Gesellschaft Transformations- und Entwicklungsprozesse vollziehen bzw. diesen unterliegen, hinkt die Infrastruktur technologisch mindestens ein Jahrzehnt hinterher, sodass es Unternehmer schwerhaben, die richtigen Geschäftsentscheidungen zu treffen.
Diese traditionelle Form der Architektur wird auch als „monolithische“ Architektur bezeichnet. Glücklicherweise gibt es jedoch einen Weg nach vorn: „Microservice“-PMS-Architektur für Hotels. Ein Hotel-PMS (Hotel-Property Management-System) ermöglicht Skalierbarkeit, Nachhaltigkeit und Sicherheit und schickt sich an, die Zukunft der Reisetechnologieinfrastruktur zu dominieren. In diesem Artikel beschäftigen wir uns umfassend mit der Microservice-PMS-Architektur für Hotels und der Frage, warum hier die Zukunft für die Reisetechnologiearchitektur liegt. Um jedoch Microservices verstehen zu können, müssen wir erst begreifen, was diese nicht ist: Client-Server-Architektur.
Was ist unter Client-Server-Architektur zu verstehen?
Es wird geschätzt, dass mehr als 90 % der Hotels gegenwärtig Legacy-Anwendungsinfrastruktur einsetzen. Das bedeutet, dass 9 von 10 Häusern gegenwärtig Systeme nutzen, die in den 80er und 90er Jahren konzipiert und entwickelt wurden, und zwar auf Grundlage des damaligen Standards: Client-Server-Architektur.
Die Hotels verwenden heute immer noch Client-Server-Architektur, weil sie weiterhin in der ursprünglich vorgesehenen Weise funktioniert. Zudem kann die digitale Transformation von Unternehmen der Umstieg auf eine neue Technologie ein einschüchterndes Unterfangen sein und darüber hinaus gab es lange Jahre nicht viele Alternativen.
Tatsächlich betrifft das Problem nicht allein die Reise- und Tourismusbranche. Der Blick auf den in den letzten vier Jahrzehnten praktisch von jedem Unternehmen verwendeten Tech-Stack bedeutet, dass man überall auf die gleiche Architektur stößt:
- Ein Server: Eine komplexe, teure physische Vorrichtung, die eine Datenbank speichert (d. h. Oracle, Microsoft, standortbasiert, File-Sharing usw.)
- Mehrere verschiedene Clients: Anwender-PC (die für gewöhnlich auf Windows, bzw. davor DOS und terminalbasierten Eingaben, wie GDS, laufen)
- Anwendungen: Direkt auf den Clients installierte Clients, die mit der Server-Datenbank kommunizieren.
In der Client-Server-Architektur haben Sie einerseits Datenspeicherung in einer zentralen Datenbank (für gewöhnlich regionaler Natur, wie etwa eine SQL), die auf einem physischen Server gespeichert ist, und andererseits mehrere verschiedene Anwenderoberflächen (UI), Windows-/DOS-basierte Anwendungen, die mit dem Server kommunizieren. Das Hauptproblem dieser Architektur ist, dass die Geschäftslogik beide Bereiche in ihrem Wesen bestimmt. In der Datenbank beispielsweise findet man für gewöhnlich nicht nur Datenspeicherung, sondern häufig sogar Programmierung. Bis in die späten 90er Jahre waren Server sowohl für die Datenbankspeicherung als auch für die Ausführung bestimmter Teile der Geschäftslogik verantwortlich. Das mag wie ein triviales, semantisches Problem klingen, hat aber zahlreiche negative Implikationen.
Wenn zum Beispiel ein Geschäftsprozess auf der Datenbank schneller als auf dem Client lief, platzierten die Entwickler die Geschäftslogik teilweise direkt in die Datenbank oder in die UI-Schicht, anstatt dem konventionellen Verfahren folgen, bei dem ein ständiger Austausch zwischen Client und Datenbank erfolgt. So wurden schwerfällige Mischsysteme mit großer Fehleranfälligkeit geschaffen.
Neue Plattformen, alte Architektur
Software wurde jahrelang basierend auf Client-Server-Infrastruktur geschrieben und entwickelt, doch in den früheren 00er-Jahren wuchs angesichts des Aufstiegs des Internets und der gewachsenen Erwartungen von Kunden und Unternehmen zunehmend der Druck, nach einer besseren Lösung zu suchen. Doch trotz der zunehmenden Verbreitung von HTML-Frontend-Internetanwendungen schufen nicht wenige Entwickler auch weiterhin Software mithilfe des gleichen obsoleten Verfahrens und veränderten lediglich das Erscheinungsbild von Anwendungen, während die bisherige Client-Server-Architektur hinter der Oberfläche nicht angerührt wurde.
Erst zum Ende der 00er Jahre begriff die Entwicklerszene angesichts des unaufhaltbaren Anstiegs von Internetkonnektivität und der wachsenden Zahl von Internetnutzern, dass die Anwendungen immer umfangreicher wurden, sodass die Client-Server-Architektur nicht länger damit fertigwerden würde. Darüber hinaus standen aufgrund der Ausbreitung neuer und verschiedenartiger Browser und Geräte, alle mit den unterschiedlichsten Spezifikationen, die Entwicklern vor dem Problem, dass sie es nicht mehr nur mit einer sondern einer Vielzahl an Benutzeroberflächen zu tun hatten.
Branchenführer, wie Google, Amazon und Netflix, verstanden diese Verschiebung schnell und begannen für die Gewährleistung von Stabilität und Skalierbarkeit mit der Zerlegung des Prozesses, mit dem die Daten verarbeitet, genutzt und verwaltet wurden, und stellten so sicher, dass ihre Darstellungsschichten und ihre Geschäftslogik klar voneinander getrennt waren – eine von vielen weitsichtigen Maßnahmen, die die Voraussetzung für den Erfolg dieser Unternehmen schufen.
Three-Tier- im Vergleich zur Client-Server-Architektur
Die Lösung von Google und weiteren Branchenführer war simpel und zugleich brillant. Sie bestand erstens in der Verkleinerung der Verantwortung des Servers, der sich nun allein auf die Datenspeicherung konzentrierte, zudem in der Steigerung der Datenverarbeitungskapazität der Server (zur praktisch in Echtzeit erfolgenden Erhebung und Analyse von Terabytes an Daten) und abschließend in der Reduzierung der Geschäftslogikverantwortlichkeiten der Server.
Dieses neue Konzept markierte die Geburt dessen, was wir heute als Three-Tier-Architektur kennen, die aus drei unabhängigen Teilen besteht: ein vollständiges Followend-Datenspeicher-/Datenabrufsystem (transparent, schnell und stabil), einer Geschäftslogik (die ihre Funktionalitäten durch spezifizierte API (Programmierschnittstellen) offenbart) und einer Darstellungsschicht (der Frontend-Benutzeroberfläche).
Eine Microservice-Architektur gliedert Funktionalitäten auf, während monolithische Systeme diese zentralisieren. Mit anderen Worten: Microservice-Architekturen gliedern potenzielle Probleme auf, während monolithische Systeme diese zentralisieren.
Der Aufbau und die Pflege von Software als unabhängige Module auf separaten Plattformen war ein revolutionäres und revolutionäres Konzept, das Lichtjahre von der in den 80–90er Jahren üblichen Standardarchitektur entfernt war. Skalierbare Software mit der Ausspaltung aller Funktionen eines Systems in viele verschiedene Pakete mit zusammengesetzter Funktionalität macht die Softwareentwicklung leichter in der Durchführung im Vergleich zu der Herausforderung, alles auf einer großen, klobigen Plattform entwickeln zu müssen.
Dieses neue Herangehen wird als „Microservice-Architektur“ bezeichnet, während man in Bezug auf das alte Verfahren von einer „monolithischen Architektur“ spricht.
„Monolithische Anwendungen können erfolgreich sein, aber viele Leute finden den Umgang damit zunehmend frustrierend.“
„Monolithische Anwendungen können erfolgreich sein, aber viele Leute finden den Umgang damit zunehmend frustrierend.“
— Martin Fowler
Das Hauptproblem mit der monolithischen Architektur im Vergleich zur Microservice-Architektur besteht darin, dass es praktisch unmöglich ist, sowohl für Technologieanbieter als auch für Endanwender zu skalieren. Das Hinzufügen einer neuen, einfachen Funktion zu einer bestehenden Anwendung kann im schlimmsten Fall das ganze System zusammenbrechen lassen oder im besten Fall sehr viel Zeit für die Entwicklung in Anspruch nehmen, was zu höheren Kosten für alle beteiligten Seiten führt.
Von der monolithischen hin zur Microservice-Architektur
Hotelgäste haben bestimmte Erwartungen. So wollen sie sich über ihre Mobiltelefone einchecken können oder das Abendessen per App bestellen. Und Hotels würden solche Leistungen und die Digitalisierung der Gastronomie liebend gern anbieten, da für die Reise- und Tourismusbranche die Kundenzufriedenheit von fundamentaler Bedeutung ist. Allerdings sind Hotels allzu oft vor allem deshalb nicht in der Lage, ihren Gästen derartige Leistungen zu bieten. Die digitale Transformation der Unternehmen scheitert oft, weil ihre veralteten Systeme nicht über die Fähigkeit zur Integration neuer Funktionen als jeweils einer Extraschicht der Personalisierung verfügen, die in die Datenbank oder in die Client-Anwendung einprogrammiert werden müsste. Hotelsoftware besteht in den meisten Fällen aus einem großen, chaotischen Code-Klotz, in dem jede Zeile so stark von der anderen anhängig ist, dass es fast unmöglich ist, Neuerung vorzunehmen, ohne dass man das ganze System niederreißt. Das erklärt, warum die Branche nicht in der Lage ist, sich an neue Marktbedürfnisse anzupassen.
Mit dem Microservices-Ansatz hingegen können Sie viele verschiedene kleine Hotel-PMS-Programme einsetzen, die einerseits voneinander vollkommen unabhängig, jedoch durch die in die API geschriebenen Regeln miteinander verknüpft sind. Daher kann, solange die API-Regeln befolgt werden, ein auf Microservice-Architektur-basiertes System unbegrenzt unterhalten und verbessert werden, ohne dass das Risiko besteht, dass jede Aktualisierung das gesamte System zerschlägt. In Hinblick auf dessen Betrieb wird das Risiko eines durch Programmierfehler ausgelösten Dominoeffekts durch die der Microservice-Architektur eigenen Dezentralisierung beschränkt – wenn eine Anwendung nach einer Aktualisierung zusammenbricht, ist nicht gleich die gesamte Struktur betroffen. Das gesamte Ökosystem gewinnt so an Widerstandsfähigkeit und es ist einfacher, Fehler zu isolieren bzw. mit Systemausfällen fertig zu werden.
Die Rolle der API
Die gestiegene Adaptionsrate von API in der Hotelbranche hat eine entscheidende Rolle bei dem Umstieg von der monolithischen hin zur Microservice-PMS-Architektur für Hotels gespielt. API sind entscheidend für diesen flexibleren, dezentralisierten Ansatz, da sie das Programmieren vereinfachen und die Möglichkeit von Interkonnektivität erhöhen.
Diese Unabhängigkeit gewährt Entwicklern die Freiheit, programmieren zu können, ohne dass sie die Programmiersprache, die für das Kernsystem verwendet wird, bis ins letzte Detail verstehen müssen. Programmierer, die an der Integration einer singulären Funktion aus einer externen Anwendung arbeiten, müssen zum Beispiel nicht das gesamte Dateisystem, die Programmierungsstruktur und die Programmiersprache verstehen. Sie können sich einfach darauf konzentrieren, spezifische Informationen einzuholen, die für die Lösung eines spezifischen Problems erforderlich sind. Microservices gliedern Funktionalitäten auf, während monolithische Systeme diese zentralisieren.
Microservice -Architektur für Hotel-PMS und Datenschutz
Es vergeht kaum ein Tag ohne Nachrichten über Datenschutzverstöße. Die Reise- und Tourismusbranche ist durch Datenschutzverstöße besonders gefährdet. Das liegt vor allem daran, dass (anders als in den meisten Branchen) sie enorme Datenmengen zu den Kunden erheben muss und der Wert dieser Daten in Korrelation zu der Fähigkeit des Hotels steht, Leistungen für diese Kunden zu erbringen.
Auf dem Schwarzmarkt werden Daten, die einer identifizierbaren Person zugeordnet sind, zum Preis von jeweils 1 US-Dollar verkauft, jedoch – nach den Worten von Justin Lie, dem CEO von CashShield – „verfünffacht sich ihr Wert mit jeder hinzugefügten verbundenen Information“. Fügen Sie eine Mobiltelefonnummer, eine persönliche E-Mail-Adresse und das Geburtsdatum zu den ursprünglich gestohlenen Daten hinzu und der Wert klettert auf astronomische 125 US-Dollar.
Eine universelle Content-Management-Lösung
Die Gruppe wandte sich dann dem zu, was manche als den heiligen Gral des Content-Managements im Gastgewerbe betrachten: Eine universelle Content-Management-Lösung, die die einzige Quelle für alle Inhalte auf allen Plattformen wäre, die ein bestimmtes Hotel nutzt. Wie würde dies aussehen, welche Hindernisse gibt es, und was ist derzeit verfügbar?
Natalie Kimball: Wir [Shiji] müssen als Technologieanbieter berichten, welche Datenpunkte es gibt. Durch HTMG, wurden so viele Datenpunkte gesammelt. Wir haben bereits die Daten. Wir brauchen jemanden, der die Verantwortung übernimmt und sagt: “So wird es funktionieren”. Und dazu brauchen wir die Hilfe von GDS und von allen Beteiligten. Vielleicht müssen Wyndham, Hilton und Marriott irgendwann sagen: “Wir müssen aufhören, in dieses Hamsterrad stecken zu bleiben.”
Warum sollten die Anbieter aufstehen und sagen: “Okay, ja, wir machen das”, wenn es keinen Anreiz von kommerzieller Seite gibt? Vielleicht muss der Anstoß von einem großen Anbieter kommen, der über genügend finanzieller Mittel verfügt, um anfangs in die Sache zu investieren. Und wenn sie ein kommerzielles Modell entwickeln, das Einnahmen generiert, wird man anfangen, die Kosten zu decken. Aber es kann sein, dass es anfangs einen Verlust geben wird, damit wir es für die Branche anpassen können.
Gianna Rivera: Viele unserer Unternehmen denken über die verschiedenen Inhaltskanäle auf individuelle Weise nach. Ich glaube nicht, dass das nur für das eine oder andere Unternehmen gilt. Wir müssen dazu beitragen, dass diese Gespräche zu einem einheitlichen Denkprozess führen und dass sie verstehen, dass es im eigentlichen Sinne um Inhalte geht.
Hochwertige visuelle Inhalte
Zum Abschluss des Gesprächs diskutierte die Gruppe darüber, dass nicht alle Inhalte gleich sind, und tauschte einige Ideen darüber aus, wie hochwertige Inhalte tatsächlich aussehen.
Sarah Fults: Eine der größten Herausforderungen ist, dass man sein Hotel für das Fotoshooting vorbereiten muss. Für diejenigen von uns, die eine hohe Auslastung haben, kann es sehr schwierig sein, einen Termin für ein Fotoshooting für ein Hotel zu finden. Das ist die größte Herausforderung: Die Zeit zu finden, den Raum einzurichten und sicherzustellen, dass man überhaupt das Wissen dazu hat. Welche Blickwinkel? Von was sollte man das Bild machen? Wie kann man das im Rahmen des Budgets machen? Wie viele Jahre dauert es, bis man das nächste Fotoshooting machen muss?
Natalie Kimball: Es ist eine aufwendige aber wichtige Investition. Und jeder Geschäftsführer wird sich fragen: “Was ist mein Return on Investment?” Selbst wenn die Auslastung um 2 % steigt, ist das nicht genug.
Inhalte sind ein Verkaufsförderungsinstrument, und die OTAs haben uns das bewiesen. Es gibt einen Grund, warum jeder von ihnen Badezimmerfotos verlangt.
Ich glaube, es geht darum, dass ein Hotel nicht mehr darüber nachdenken muss, welches Foto wichtig ist und wie man es bekommt. Es geht um die Automatisierung. Und haben wir dann das Recht, das Foto auf jedem Kanal zu verwenden, der Zugang zu dieser Hosting-Plattform hat?
Man muss kein Genie sein, um zu verstehen, warum Datenbanken von Hotels sprichwörtliche Goldminen für Hacker sind, speichern sie doch ein vollständigeres, genaueres individuelles Profil als beispielsweise ein Webblog oder eine Gaming App. Hotels erheben äußerst wertvolle Daten, wie etwa Telefonnummern, Kreditkarteninformationen und, was am wichtigsten ist, Reisepassdaten. In den USA ist es mit einem gestohlenen Reisepass möglich, praktisch überall online eine Sozialversicherungsnummer zu beantragen und sich anschließend Kreditkarten ausstellen zu lassen oder Darlehen aufzunehmen.
Die Schwierigkeit besteht darin, dass, da die Kernstruktur für Hotelsoftware in den meisten Fällen vor Jahrzehnten vor dem Siegeszug des Internets programmiert wurde, solche Systeme schlichtweg nicht in der Lage sind, sich selbst gegen Online-Cyberangriffe zu verteidigen. Der französische Philosoph Paul Virilio sagte einmal: „Wer das Schiff erfindet, erfindet auch den Schiffsbruch.“ Damals in den 80ern und bis lange in die 90er Jahre hinein, als kaum jemand einen Internetzugang hatte, dachte kaum jemand an Hackerangriffe über das Internet. Daher sind so viele Softwaresysteme in Hotels schutzlos, wenn Datenverlust auftritt.
Heute können dank der Microservice-PMS-Architektur für Hotels Programmierer personenbezogene Daten von anderen Daten separieren und auf Grundlage der auszuführenden, spezifischen Aufgabe entsprechend den Erfordernissen für diese verschiedenen Datensätze unterschiedliche Designs zu entwickeln.
Diese Flexibilität, wann immer möglich nur mit nicht personenbezogenen Daten zu arbeiten, bedeutet für Microservices-Software einen unschätzbaren Vorteil insbesondere im Zusammenhang mit Beschränkungen der Datenspeicherung in bestimmten Ländern, die die lokale Speicherung der Daten ihrer Staatsbürger gesetzlich vorschreiben. In monolithischen Architekturen werden Daten häufig unkontrolliert verteilt. Das führt zu Problemen, wenn z. B. die personenbezogenen Daten russischer Kunden, wie gesetzlich vorgeschrieben, in ihrem Wohnsitz gespeichert werden sollen. Für die Geschäftstätigkeit mit russischen Partnern müsste das gesamte System umgesiedelt werden, und die Daten ließen sich dann nur durch Caching abrufen, was zu einem schwierigen (und kostspieligen) Teufelskreis von Komplexität führt.
Unternehmen, wie Amazon und Netflix, haben frühzeitig Microservices-Architekturen geschaffen und ihre hohe Skalierbarkeit ist vor allem auf die Tatsache zurückzuführen, dass ihre Anwendungen als ein Bausatz von Microservices und nicht als ein großer Code-Klotz entwickelt und eingesetzt werden.
Cloudbasierte Lösungen: Flexibilität zum Schnäppchenpreis
Vielfach missverstanden (nicht zuletzt aufgrund wissentlich verzerrter Darstellungen der IT-Unternehmen), besteht der Hauptvorteil der „Cloud“ weniger darin, dass man eine Anwendung über einen Browser ausführen kann, sondern vielmehr in den möglichen Kosteneinsparungen bzw. in den günstigeren Gesamtbetriebskosten. Die direkten und indirekten Kosten für den Einsatz eines Systems in der Cloud sind einfach deutlich niedriger als für den Erhalt einer Legacy-Plattform.
Erstens müssen Hotels für den Einsatz einer Hotel Management Software, bzw. eines Hotel PMS keine teure Hardware erwerben (direkte Kosten). Weiterhin können Hotels durch Outsourcing von dem Fachwissen und den Ressourcen des Dienstleisters profitieren, falls und wenn etwas schiefgeht, statt dann für Support und Wartung allein auf die unternehmenseigenen Experten zurückgreifen zu müssen (indirekte Kosten). Die Dienstanbieter Cloud-basierter Lösungen garantieren häufig längere Betriebszeiten als dies bei selbstverwalteten Legacy-Systemen der Fall ist, sodass sich das Risiko potenzieller Einnahmeverluste dadurch drastisch reduziert. Des Weiteren vereinfacht sich die Fusionierung verschiedener Technologien dank der Microservices-Architekturen im exponentiellen Umfang.
Kurz gesagt, Cloudlösungen (Hotel-PMS und POS-Lösungen) ermöglichen Skalierbarkeit, Wachstum und Nachhaltigkeit für Unternehmen jeder Größe, da sie die Notwendigkeit kostspieliger Vorabinvestitionen (Hardware, Einrichtung von Rechenzentrenkapazitäten, Installationskosten usw.) minimieren und den Lebenszyklus der Anwendungen verlängern.
Das Wachstum der Microservice-PMS-Architektur für Hotels
Es ist keine Überraschung, dass in den vergangenen Jahren erfolgreiche Unternehmen, wie etwa Netflix, Google und Amazon sich zugunsten vom Microservices zunehmend von monolithischen Architekturen verabschiedet haben. Angesichts neuer Datenschutzgesetze, verschiedenartiger Vorschriften, schnellerer Technologien, disruptiver Zahlungssysteme und sich ständig vergrößernder Vertriebssysteme ist es offensichtlich, dass der monolithische Ansatz hierbei nicht Schritt halten kann.
Zudem verlieren Entwickler durch die Nutzung des Plug-and-Play-Ansatzes keine Zeit mehr damit, Probleme lösen zu müssen, die bereits jemand anderes gelöst hat. Die zahlreichen Implikationen aus der zunehmenden Implementierung von Microservice-PMS und weiterer IT-Architektur für Hotels können manch einem überwältigend erscheinen. Jedoch sollte jedes Unternehmen ungeachtet seiner Größe in der Lage sein, jedes auf dem Markt verfügbare Tool zu wählen und es ohne Reibungsverluste mit anderen Instrumenten verbinden zu können – so wie sie beispielsweise Anwendungen auf ihrem privaten Smartphone installieren. Für Hotels könnte das auch nur die Änderung einfacher Prozesse, wie etwa die Reihenfolge, in der die Zimmer gereinigt oder gewartet werden, bedeuten.
Die digitale Transformation von Unternehmen und der Einsatz von Technologie sollten die Geschäftsprozesse vereinfachen und den Kunden und Gästen Vorteile bringen. Und in Bezug auf Hotels sollten Strategien niemals durch die Beschränkungen der bestehenden IT-Infrastrukturen bestimmt werden, sondern von deren Flexibilität profitieren können. Es ist an der Zeit für die Reise- und Tourismusbranche, sich aktiv Innovation, Nachhaltigkeit und Skalierbarkeit von Microservice-Architektur zu eigen zu machen.
