SharePoint Kompendium - Bd. 11: Big Data, BI, Office 365

redaktion@windowsdeveloper.de

Self-Service Business Travel leicht gemacht

Wenn man eine Reise tut ...

Rüdiger Gros

Als wir uns vor etwas mehr als einem Jahr daran gemacht haben, ein Self-Service-Reiseportal für Geschäftsreisende zu entwickeln, war die Grundidee einfach: Geschäftsreisende haben Termine bei Geschäftspartnern, zu denen sie pünktlich erscheinen wollen. Die Reiseplanung und Buchung vom Ausgangspunkt zum Meeting (Door-to-Door) sollen einfach und schnell möglich und auch mobil nutzbar sein.

Die Businessanforderung

Wer selbst Geschäftsreisen buchen muss, kennt den enormen Aufwand, um in diversen Portalen die An- und Abreise sowie eventuelle Übernachtungen kostengünstig und mit möglichst wenig Zeitverschwendung zu finden und zu buchen (Abb. 1). Aber auch Agenturen und Assistenten haben ebenfalls die Anforderung, den Rechercheaufwand und die Ergebnisqualität zu optimieren.

Abb. 1: Selbst eine einfache Recherche erfordert dutzende von Schritten und Iterationen

In Unternehmen kommt natürlich hinzu, dass Geschäftsreisen an vor- und nachgelagerte Prozesse und Systeme gekoppelt sind, die ebenfalls möglichst kostengünstig und effizient bedient und ausgewertet werden sollen, um durch Datenanalysen Potenziale ermitteln zu können.

Das Anwenderproblem

Befragungen potenzieller Anwender haben gezeigt, dass Anwender nicht nur vom enormen Zeitaufwand einer Reiseplanung genervt sind, sondern auch von der Komplexität. Da die Portale bei der Suche den Vorgänger oder Nachfolger des aktuellen Reiseschritts nicht kennen, liefert jedes Portal jeweils hunderte von theoretischen Möglichkeiten pro Streckenabschnitt, die sich aber in Kombination mit den möglichen Vorgänger- oder Nachfolgerstrecken bis zum Ziel meistens als unbrauchbar erweisen. Selbst wenn man mögliche Kombinationen aller Reiseschritte finden konnte, weiß man noch lange nicht, ob die gefundene Kombination günstig oder teuer ist.

Die UX-Herausforderung

Um die Benutzerführung zu optimieren, muss man deshalb überlegen

welchen Hauptzweck man tatsächlich erfüllt

welche Informationen dem Benutzer zum Zeitpunkt der Suche vorliegen

welche Informationen die Datenquellen benötigen

welche Regeln und Reihenfolgen zur Filterung der Teilergebnisse der jeweiligen Datenquellen angewendet werden sollen

Der Benutzer weiß also alles über das Meeting, aber nichts über die Reise (Tabelle 1).

Tabelle 1: Minimalinformationen zur Reiseplanung

Die Eingabe der Suchparameter erfolgt deshalb mit den Dingen, die der User kennt. Bei Start und Ziel genügt es, Firmennamen oder öffentliche Einrichtungen anzugeben, so führt z. B. eine solche Eingabe zu einem gültigen Ergebnis (Abb. 2).

Abb. 2: Bei der Adresseingabe reichen auch Firmennamen oder öffentliche Orte

Das Ergebnis unserer Untersuchungen ist dadurch ein sehr einfacher UX-Workflow. Um weitere Szenarien abzubilden, stehen dem Benutzer abhängig von seiner Fragestellung jeweils optimale UX-Workflows zur Verfügung.

Das fachliche Engineering zur Ermittlung des besten UX-Workflows erfordert Interviews, Erfahrung, Versuche und UX-Experten, die verstehen, wie Benutzer arbeiten und die verschiedene Alternativen testen, bis das Ergebnis der Mehrheit der Benutzer gefällt.

Die Datenherausforderung

Suchen: Dass Door-to-Door-Reiseplanung grundsätzlich Daten aus den unterschiedlichsten Datenquellen benötigt, erscheint logisch. Jede Datenquelle hat eigene technische Schnittstellen und liefert zum Teil sehr verschiedene Ergebnistypen. Zur Ermittlung der Gesamtstrecke benötigt man deshalb zunächst alle grundsätzlich möglichen Wege vom Start zum Ziel. Diese theoretischen Alternativen werden in Segmente unterteilt, die die Strecken zwischen Verkehrsknotenpunkten darstellen. Um aus Tausenden von theoretischen Ergebnissen pro Abschnitt am Ende nur die Ergebnisse zu liefern, die für die gesamte Strecke eine Ankunft am Ziel garantiert vor Beginn des Meetings garantieren, werden umfassende Optimierungsalgorithmen angewendet.

Abb. 3: Streckenoptimierung für Door-to-Door-Reisen mit festem Ankunftstermin sind komplex

Da die Ergebnisse keine fixe Struktur haben, werden die Daten technisch im Arbeitsspeicher als XML- bzw. JSON-Struktur verarbeitet und bei Bedarf unstrukturiert in einer In-Memory-NoSQL-Datenbank gespeichert.

Aktualität und Verfügbarkeit sind bei der Preisermittlung entscheidend. Da Livedaten teuer sind und nicht vorhersehbar ist, ob der Benutzer am Ende tatsächlich auch buchen wird, liefern die Optimierungsalgorithmen nicht nur kurze Antwortzeiten für den Benutzer, sondern auch maximal reduzierte Datenabfragen an die Datenprovider. Und da die beschriebenen Vorgänge auf der Plattform von vielen Usern parallel durchgeführt werden, bedeutet das in der Zusammenfassung: Skalierbarkeit, Verfügbarkeit und enorme Datenmengen sind ein Kernthema unserer Plattform.

Buchen: Beim Buchen sind die Anforderungen etwas anders gelagert: Im einfachsten Fall haben wir einen Selbstbucher, der für sich selbst eine Reise bucht. Nach der Suche wählt er sich den gewünschten Vorschlag aus den verfügbaren Alternativen (schnellste, günstigste, komfortable Reise) aus, bestätigt die Buchung und markiert die Reise ggf. als Favoriten zur späteren Wiederverwendung.

Im Frontend werden die Buchungsdaten im Buchungsjournal des Benutzers angezeigt. Im Backend werden die Buchungen und Zahlungstransaktionen bei den Ticketprovidern ausgelöst. Die Belege und Tickets werden im Benutzerkontext gespeichert, sodass der Benutzer seine Tickets im Portal und auf seinem Smartphone jederzeit abrufen kann. Da es sich bei diesen Vorgängen um sehr strukturierte Daten mit kaufmännischem Charakter handelt, ist die Speicherung in relationalen Datenbanken einfach. Die Datenablage und Datenabfragen erfolgen grundsätzlich verschlüsselt.

BI und Dashboards

Aus Favoriten (gespeicherte Suchanfragen), Buchungen und anstehenden oder abgeschlossenen Reisen errechnen sich im Dashboard des Benutzers seine persönlichen Reisestatistiken und seine Reiselandkarte.

Die Umsetzung der persönlichen Dashboards eines Users ist im Gesamtprojekt einfach. Anspruchsvoller sind Analysefunktionen für Teams und Unternehmen, in denen nicht nur die tatsächlichen Buchungen in BI-Cubes aufbereitet werden, sondern in denen auch Simulationen mit historischen Daten auf Basis von vorbereiteten Standard-Cubes möglich sind („Was wäre wenn"), um Einsparpotenziale in Zeit, Geld oder anderen Dimensionen ermitteln zu können.

Auch wenn die Datenmengen pro User in aller Regel recht überschaubar sind, addieren sich die Datenvolumen in Unternehmen schnell zu beachtlichen Datenmengen, die sich nur mit skalierbaren Infrastrukturen beherrschen lassen. Ohne Cloud und BI-Funktionen wäre das eher schwierig zu realisieren. Und noch schwerer in akzeptable Preismodelle zu gießen.

Abb. 4: Dashboards helfen, die Übersicht über seine Reisen und Kosten zu behalten

Interne Analysen

Wir selbst analysieren die detaillierte Nutzung, Performance- und Datenlast auf unseren Systemen. Die dazu benötigten Daten summieren sich schnell zu echten Datengebirgen zusammen, die zum Teil in Echtzeit benötigt werden. Auch hier nutzen wir die Power der Cloud und Power-BI für unsere eigenen Analysen auf aggregierten und anonymisierten Daten.

Backend-Technologie

Im Backend gibt es neben der Datenspeicherung und den Algorithmen zur Verarbeitung und Optimierung von Daten vor allen Dingen Schnittstellen zu anderen Systemen.

Abb. 5: Backend-Technologie stark vereinfacht

Datenprovider-Integration: Die Datenlieferanten sind über die bereitgestellten APIs so angebunden, dass wir technisch in der Lage sind, im Notfall durch Konfiguration auf alternative Datenprovider umschalten zu können. Da das nur funktionieren kann, wenn die Implementierung des jeweiligen Fallbacks betriebsbereit ist, bedeutet dies in der Praxis einen erhöhten Pflegeaufwand, da auch für Fallback-Provider alle Änderungen an den Schnittstellen aktuell gehalten werden müssen (inkl. der Nutzungsverträge). Zum Start des Service steht deshalb nur für Flugdaten eine Fallback-Implementierung zur Verfügung.

3rd-Party-API: Unsere eigenen Services stellen wir Entwicklungspartnern mit umfassenden Funktionen zur Verfügung. Um das API nutzen zu können, benötigen Entwickler Zugriffsschlüssel und erhalten im Test-Mode Mock-Daten zurück. Zugriffsschlüssel arbeiten mit einem sicheren Autorisierungs-/Authentisierungsverfahren, das sicherstellt, dass nur autorisierte und authentisierte Datenabfragen von bekannten Quellen möglich sind.

Da wir selbst für Datenabfragen bei unseren Providern Geld bezahlen müssen, ist der Zugriff von Entwicklern auf Echtdaten nur im Rahmen von Nutzungsverträgen möglich.

3rd-Party-Integrationen: Zu Beginn stellen wir Schnittstellen zu SharePoint und Office 365 zur Verfügung, um Daten, Dokumente und Reiserouten für Unternehmen und Benutzer zugreifbar zu machen. Insbesondere die Integration mit Exchange und mit Office 365 Delve sowie die Bereitstellung von Konfigurationen für externe Inhaltstypen und SharePoint Web Parts haben Priorität, um die Automatisierung von Geschäftsprozessen auf der Office-365-Plattform und mit SharePoint-Workflows einfach zu machen.

Zu einem späteren Zeitpunkt werden wir Möglichkeiten zur Automatisierung von Aufgaben mit Zapier und IFTT zur Verfügung stellen.

Frontend-Technologie

Im Frontend werden grundsätzlich nur wenige Daten verarbeitet, die Rechenleistung liefert immer unser Backend. Die Benutzeroberflächen konzentrieren sich auf optimale UX-Workflows und integrieren sich in den natürlichen Arbeitsablauf und die gewohnten Ökosysteme der Endanwender.

Abb. 6: Frontend-Technologien im Überblick

AngularJS: Im Web ist die gesamte Frontend-Logik mit AngularJS umgesetzt, die Struktur und das Styling werden mit HTML5 und CSS3 realisiert. Aktuell findet auch das Rendering auf mobilen Clients vollständig aus der responsive umgesetzten CSS-Steuerung statt, sodass auch Nutzer, die die mobilen Apps nicht installiert haben, von uneingeschränkter mobiler Nutzung profitieren.

Napa-Entwicklung für Office-Add-ins: Die Integration der Funktionalität in SharePoint, Outlook und Office 365 wird mit Napa umgesetzt. Die Entwicklung mit Napa erleichtert den Umgang mit hybriden Umgebungen und insgesamt das Entwicklerleben, da mit einer Umgebung für verschiedene Zielplattformen entwickelt werden