top of page

Unternehmensdaten normalisiert per APIs: Ein realer Use Case



Für Unternehmen mit lokal betriebenen IT-Systemen klingt die Umstellung auf die Cloud oft nach einer Generalüberholung. Daten müssen in die Cloud verschoben, Security- und Governance-Prozesse müssen definiert werden. Ist dies einmal geschehen, lassen sich mit wenig Aufwand Tools erstellen, die den Geschäftsalltag effizienter und flexibler machen. In diesem Artikel erläutern wir am Beispiel unseres Kunden, wie sie das Potenzial ihrer Cloud-Infrastruktur nutzen und davon profitieren können.


Problem: Teure Applikationserstellung und mangelnde Stabilität


Unser langjähriger Kunde – eine Airline – setzte auf ein lokal betriebenes IT-System. Im Allgemeinen löste das System zwar die Probleme des Kunden, war aber ineffektiv. Jedes Mal, wenn ein neues Tool entwickelt oder aktualisiert werden musste, war dies ein grosses und teures Projekt.


So musste das Entwicklungsteam beispielsweise direkt auf die Datenbank zugreifen. Dies umfasste mehrere Schritte: Zugang zu dieser Datenbank erhalten, Firewall öffnen, das Backend schreiben… Wenn das Tool Daten aus mehreren Datenbanken benötigt, müssen diese Verfahren jedes Mal durchgeführt werden. Dabei mussten die Entwickler das Datenbank-Schema gut verstehen. So mussten sie beispielsweise Applikationsinternas kennen, um die Daten korrekt interpretieren zu können. Allzu oft geschahen dabei Fehler, was zu Inkonsistenzen zwischen den Systemen führte.




Ausserdem gab es noch ein weiteres Problem: diese Architektur führte dazu, dass die Abhängigkeiten zwischen den Applikationen extrem gross waren. Brach ein Tool zusammen, haben andere Systeme auch nicht mehr funktioniert.


Lösung: Ein zentralisiertes API


Um diese Probleme zu beheben, hat der Kunde entschieden, das alte System im Jahr 2019 abzulösen. 1stQuad hat dem Kunden geholfen, ein neues System mit einem zentralen API zu erstellen. Alle Schritte, die das Entwicklungsteam für den Zugriff auf die Datenbanken durchlaufen musste, wurden im API dokumentiert. Das bedeutet, dass das API automatisch Prozesse ausführt, die Entwickler bisher manuell durchführen mussten. Dadurch können jetzt neue Business-Applikationen viel schneller und mit wenig involvierten Leuten entwickelt werden, und somit mit wenig Aufwand für den Kunden.

Dieser Ansatz kann auch verschiedene Systeme des Kunden entkoppeln. Dafür setzten wir die sogenannte Microservice-Architektur ein. Dies erhöht die Stabilität des Systems. Wenn nun eines der Tools ausfällt, funktionieren die anderen weiter.


Schauen wir uns mal an, wie Airline-Mitarbeiter von der Applikation profitieren können.


Beispiel: Ein neues Tool für die Alltagsplanung


Sehen wir uns als Beispiel eine Applikation an, die wir nach der Modernisierung der Infrastruktur entwickelt haben. Das Tool kostete den Kunden im Nachhinein ein Vielfaches weniger, als wenn sie es mit der bisherigen Infrastruktur gebaut hätten.


Die Applikation ruft Crew-Planungsdaten von mehreren Systemen über das zentrale API und stellt sie den Mitarbeitern zur Verfügung. Es geht nicht um die eigene Planung (dafür gibt es selbstverständlich eingespielte und doppelt abgesicherte Prozesse), sondern um die Planung der Kollegen. Die Applikation liefert Antworten auf Fragen wie: „Wer ist mit mir auf dem Flug?“, „Wann ist Franziska zurück?“, „Braucht es noch jemanden auf dem Flug in die Malediven?“. Es sind nicht kritische Fragestellungen, aber dennoch helfen die Antworten den Crew Member, sich besser auf den Einsatz vorzubereiten oder Ihren Alltag besser zu planen.


Use Case 1: Flugübersicht


Die Applikation liefert einen Überblick über alle Flüge der Airline für einen bestimmten Datumsbereich. Das tönt zwar einfach, berücksichtigt man aber die Realität mit Umleitungen, medizinischen Zwischlandungen und ähnlichem. So erkennt man schnell, dass ein grosser Unterschied zwischen geplanten und den in der Realität durchgeführten Flügen besteht. Erschwerend hinzu kommt, dass während der Planung und der Durchführung der Flüge unterschiedliche Systeme die Datenhoheit haben. Auf dem API ist diese Komplexität versteckt.

Die App bietet den Arbeitnehmern eine zentrale Sicht von:

  • Flugzeugdaten: Flugnummer, Typ des Flugzeuges, Immatrikulationsnummer.

  • Abflugs- und Ankunftsort: von wo nach wo fliegt das Flugzeug.

  • Abflugs- und Ankunftszeit: wann sollte der Flug abfliegen und landen.

  • Besatzung: Positionen und Namen der Mitarbeiter, die auf diesem Flug dabei sind (Chefs, Flight Attendants und Cabin Crew).

Die Crew kann die Suchfunktion nutzen, um Flüge nach diesen Kriterien zu suchen. Da die App Live-Daten enthält, werden jegliche Änderungen direkt verfügbar, sei es eine Flugverspätung oder eine Änderung im Personal.

Die Applikation kann auch Daten aus der Vergangenheit anzeigen, was für die Mitarbeiter im Operation-Center besonders relevant ist. Sie können diese Daten direkt als Excel-Datei exportieren, um Auswertungen zu machen.


Use Case 2: Freunde und Familie der Crew überraschen


Die Fluggesellschaften bieten ihren Mitarbeitern einen Bonus: Wenn jemand von ihrer Familie oder Freunden an Bord ist, wird diese Person mit einem Glas Champagner überrascht. Um diese Überraschung zu organisieren, gab es früher ein manuelles Verfahren, welches in der neuen Lösung digital umgesetzt wurde.


Mit der Applikation wird die Überraschung vollautomatisch organisiert. Die Mitarbeiter können den Namen der zu überraschenden Person und ihre Begleitung angeben. Wenn die Crew im Flugzeug ist, werden sie darüber in der Applikation benachrichtigt. So können die Mitarbeiter sicher sein, dass ihren Lieben Champagner offeriert wird.


API erstellen muss kein riesiges Projekt sein


Das gute an diesem Ansatz ist, dass Sie nicht alles auf einmal machen müssen. Ein API kann schrittweise eingeführt werden und mit der Zeit wachsen.


Zu Beginn ist es wichtig ein paar Grundlegende Fragen zu klären (z.B. Security & Berechtigungen & Nutzergruppen) und Klarheit darüber zu haben, welches System die jeweilige Datenhoheit hat. Häufig ist die Datenhoheit einer Entität über mehrere Systeme verteilt oder sie wechselt im Laufe des Lebenszyklus – so kommt beispielsweise ein Flug zu Beginn aus dem Planungs- und zum Schluss aus dem Operations-System. Sobald diese Übergänge definiert sind, kann das API um die einbezogenen Systeme erweitert werden. Mit diesem Ansatz kann auch ein Legacy System schrittweise abgelöst werden. So kommen gewisse Properties zu Beginn noch aus dem Legacy System und werden mit der Einführung einer neunen Applikation durch diese abgelöst.


Wenn Sie sich überlegen, Ihre IT-Systeme in die Cloud zu bringen, steht 1stQuad Ihnen gerne zur Verfügung. Wir helfen Ihnen, den Business Value der Cloud für Ihren konkreten Fall einzuschätzen, und unterstützen Sie gerne in jeder Phase ihrer Cloud Journey. Wir begleiten Sie beim Übergang zu einer Cloud-Umgebung, bauen eine zuverlässige Cloud-Infrastruktur auf, entwickeln Cloud-basierten Applikationen und beraten Sie zur Integration von Cloud Microservices. Lassen Sie uns wissen, was wir für Sie tun können.

Comments


bottom of page