Gestatten, Ihre Datenbank
Zugegeben, der Begriff Datenbank wird in der letzten Zeit im Tourismus ziemlich inflationär verwendet. Nachdem die Branche jetzt erkannt hat, dass man sich in erster Linie um die Daten kümmern muss, kommen die Datenbanken immer stärker in das Zentrum des Handelns. Jetzt gibt es auf einmal ganz viele davon und jede Tourismusdestination hat auch weit mehr als nur Eine. Doch was ist denn nun DIE Datenbank? Im folgenden Beitrag versuchen wir, herauszufinden, ob es DIE eine Datenbank wirklich gibt.
Hier zunächst einmal die Definition auf Wikipedia:
Eine Datenbank, auch Datenbanksystem genannt, ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe einer Datenbank ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen, bedarfsgerechten Darstellungsformen für Benutzer und Anwendungsprogramme bereitzustellen.
Im Tourismus gibt es viele historisch gewachsene Strukturen in denen Daten entstehen und verwaltet werden, z.B. eine Veranstaltungsdatenbank, eine POI-Datenbank (Points of Interest), eine Datenbank für Unterkünfte, usw. Diese Systeme haben sich oft aus einfacher Datenhaltung für einzelne Websites entwickelt. Manchmal haben sie sich auch zu komplexeren Anwendungen, wie Buchungssystemen hin entwickelt. In der Regel sind die Datenbanken aber Dateninseln (auch Datensilos genannt) die mit den anderen Systemen nicht korrespondieren.
Für touristische Internetseiten werden oftmals diese Daten in einem Web-CMS (Content Management System) zusammengeführt, es entsteht also ein System, in welchem die Inhalte aus den verschiedenen System gezogen werden, um sie auf einer Webseite in den unterschiedlichen Rubriken darzustellen: Veranstaltungen, Ausflugsziele (POIs), Unterkünfte, usw.
Bei der Zusammenführung von Informationen aus verschiedenen Systemen für eine Webseite gibt es folgende Möglichkeiten:
(in aufsteigender Richtung, was Aufwand und Ergebnis anbelangt)
- iFrame: Module von den verschiedenen Fremdsystemen werden komplett in eine Webseite integriert. Das geschieht in der einfachsten Version per iFrame. Dabei ist praktisch gesehen ein Loch (wie ein Fensterrahmen) in der eigentlichen Seite (z.B. Unterkünfte) und in das Loch wird eine Seite von einem Buchungssystem eingebaut, mit der man direkt suchen, filtern und buchen kann. Optisch sieht es so aus, als würden beide Systeme aus einem Guss kommen, in Wirklichkeit kennen sie sich aber nicht.
- API: Das Einbauen einer fremden Anwendung in eine Webseite per Javascript API ist technisch schon ein wenig fortgeschrittener. Dabei können mit etwas mehr Aufwand und Know-How die beiden verschiedenen Systeme Webseite und Buchungslösung so miteinander verbunden werden, dass es z.B. eine URL-Struktur gibt, bei der in der Webseite auch die Unterseiten der Buchungslösung abgebildet werden können. Das ist die Voraussetzung für eine durchgängige Navigation mit Breadcrumb und Suchmaschinenindexierung
- Integration auf Datenbasis: Die Daten aus dem Fremdsystem werden direkt als strukturierte Rohdaten abgeholt und in der Datenbank der Webseite gespeichert. Die Anzeige der einzelnen Inhalte erfolgt dann ohne Aufruf eines Fremdsystems. Die Voraussetzung für eine gleichwertige Anzeige ist die komplette Ausmodellierung aller Datentypen mit allen Funktionaltäten und mit allen Datenfeldern. Für den Betrieb ist es erforderlich, dass die Daten regelmäßig aktualisiert werden. Damit kann erreicht werden, dass es sich in einer statischen Webseite tatsächlich anfühlt wie aus einem Guss.
- Mit Webservices: Herausforderungen für eine echte Anwendung (also eine Seite mit mehr Funktionalität als statische Daten anzuzeigen) sind sämtliche Life-Informationen, wie z.B. Zimmerkontingente, Preise, Zustände, aktuelle Meldungen, Kommentare, usw. Große Plattformen haben die Ressourcen, Anbindungen von Systemen mit Live-Informationen auch performant anzubinden und die Daten zu integrieren. Für eine einzelne Website würde so ein Aufwand sicherlich das Budget deutlich übersteigen.
- Gesamtlösung: Aus Sicht einer Tourismusdestination sollte das Bestreben sein, eine Komplettlösung zu bekommen, mit der alle Daten in einer Datenbank verwaltet werden. Damit sind über die oben beschriebenen Lösungswege hinaus noch folgende Vorteile zu erwarten:
– geringere Kosten
– weniger Schnittstellen und daraus resultierend weniger Fehlerquellen
– keine redundante Datenpflege und höhere Datenqualität
– Content-Verlinkungen (s. separater Artikel)
– Voraussetzung für alle zukünftigen Assistenzsysteme: Alle Daten in einer Datenstruktur
– Aufbau einer Community mit Leads, Bewertungen, Kommentaren, Likes, usw. von Einwohnern und Gästen
– zentrales datenbasiertes Reporting von Content-Reichweite, Content-Benutzung und Useraktivitäten in der Region
Wenn man nun die touristische Landschaft anschaut, was es alles für Destinations-Kunden für Möglichkeiten an (Komplett-) Datenbanksystemen gibt, dann zeichnet sich derzeit folgendes Bild ab:
- Mit den vorhandenen Systemen weitermachen und diese bestmöglich über Schnittstellen und Einbindung in die Webseiten und Apps zu nutzen.
- Eine eigene Lösung aufbauen mit dem Zusammenbau von frei verfügbaren (Open Source) Tools. Dazu ist einiges an Fach- und Programmier-Know-How notwendig.
- Eine fertige Datenbanklösung lizenzieren, in welcher alle Daten zusammengeführt werden und auf welcher alle Datendistributionskanäle aufgebaut werden (Webseiten, Apps, Chatbots,…) Dazu ist ein nicht unerhebliches Budget notwendig und das System muss auch permanent erneuert werden, um auf dem aktuellen Stand der Technik zu bleiben.
- Ein fertiges Gesamtsystem lizenzieren und schrittweise alles in einem System zusammenführen. Die Gesamtlösung (von Outdooractive z.B.) ist tatsächlich aus einem Guss und mit allen oben beschriebenen Vorteilen ausgestattet.
Open oder proprietär?
Die Daten sind der gesammelte Schatz einer Destination. Die Software ist das nicht. Software ist vergänglich und muss alle drei bis vier Jahre erneuert werden. Sie ist auch immer nur so gut, wie der Entwickler, der die Anwendung aus der Software baut.
Das Argument, dass man am besten auf Open Source-Software aufbaut, weil dann beim Wechsel der Web-Agentur jeder andere an der Software einfach weiterarbeiten kann, ist reine Theorie. In der Theorie ist das zwar richtig, aber in der Praxis ist es viel einfacher die Daten in eine neue Software zu übernehmen.
Die extreme Open Data Bewegung, die das komplette Heil in CC 0-Lizenzen (Creative Commons Lizenz frei von allen Rechten) des Contents sieht, wird am Ende auch nur zu einem Teil Recht bekommen. Natürlich wird es Daten geben, die man mit CC-Lizenzen zur einfachst-möglichen Verwendung für Jedermann bereitstellt, aber das wird halt nur ein Teil der Daten sein. Live-Daten, Preise, Userdaten, Kommentare oder aggregierte Daten aus anderen Quellen, usw. werden das nicht sein. Insofern wird auf jeden Fall eine hybride Welt entstehen, in der ein Teil der Datenbank Open Data sein wird.
Wichtig ist, dass die Daten aus der Datenbank immer dem Mandanten gehören. Er entscheidet, unter welchen Lizenzen er seine Daten veröffentlicht und welche Rechte er für die Datennutzung bzw. – bearbeitung freigibt. Er darf seine Daten auch jederzeit löschen, an anderer Stelle abspeichern oder sie an andere Kanäle weitergeben.
Eine Datenbank sein Eigen zu nennen, ist im heutigen Zeitalter auch eher zu relativieren: Man nutzt (in der Regel) eine Software (gegen Lizenz oder Open Source), die man mit (meist externen) Entwicklern oder durch Beauftragung einer externen Firma auf fremden Webservern unter Umständen noch in der Cloud (also vielleicht in fremden Ländern) betreibt. Unter dem Gesichtspunkt ist es vielleicht doch ratsamer, sich auf den „eigenen“ Inhalt der Datenbank zu konzentrieren.
Was ist jetzt anders? Für und Wider?
Outdooractive wurde in der Vergangenheit oft als geschlossenes proprietäres System gesehen, weil ein Dritter für die Nutzung der API, um Daten aus der Plattform herauszuholen, immer eine Lizenz erwerben musste. Die Lizenz war zwar nie für die Nutzung der Daten, sondern für die Nutzung der Software und den Aufwand, aber wir erkennen heute, dass man das ganz leicht so verstehen konnte. Es gibt bereits Kunden, bei denen die Destination die API Lizenz für die Datendistribution bezahlt und der Empfänger den Service kostenlos nutzen kann. Wir werden diesen Weg konsequent weiter gehen und Daten-Download-Seiten für die kostenlose Bereitstellung der Daten der Kunden für Jedermann entwickeln. Ebenso werden wir die Daten, die in der Plattform als Open Data deklariert sind, in einem plattformweiten Downloadbereich als gesammelten Datenfeed anbieten. Dadurch muss dann eine weltweit agierende Plattform nicht mehr viele Downloadseiten bei vielen Destinationen besuchen, sondern es wird noch einfacher, einen relevanten Datensatz bereit zu stellen und damit Reichweite zu bekommen (gemeinsam sind wir stärker).
Outdooractive wurde auch oft als unlauter angesehen, weil mit der Eingabe von Daten in die Plattform auch eine Nutzungslizenz für die Daten an anderer Stelle verpflichtend war. Dieses Modell ist heute die Grundlage der Datendistribution auf alle Ausgabekanäle. Die Freigabe von Daten unter eine CC-Lizenz ist in der Outdooractive Plattform nur noch einen Schritt weiter.
Outdooractive wurde in der Vergangenheit auch oft dafür kritisiert, dass wir die Daten unserer Kunden an anderer Stelle verwenden und damit auch noch eigene Businessmodell dazu schalten, vor allem auf outdooractive.com, auf dreamango.com und adac-skiguide.de. Mittlerweile hat sich dieser Punkt stark gedreht, denn die Kunden sehen den Vorteil der zusätzlichen Reichweitenkanäle und um den Betrieb der Kanäle zu finanzieren, sind auch zusätzliche Einnahmen notwendig.
Wir trennen noch stärker zwischen Daten und Software. Der gesamte Datenschatz der Kunden wird per Download angeboten, so dass sich jeder Kunde, so oft er möchte, eine Kopie der Daten ziehen kann und diese auf einer eigenen Festplatte abspeichern kann. Das empfehlen wir auch jedem Kunden, um die Sicherheit zu haben, jederzeit mit seinen Daten weitermachen zu können, egal was mit Outdooractive auch passiert.