Über unsMediaKontaktImpressum
Stefan Brock 23. Februar 2021

Von der Daten-Anarchie zur Daten-Wertschöpfung

Designprinzipien datenzentrischer IT-Architekturen

Eine datenzentrische Architektur entkoppelt die Daten von der heterogenen Applikations-Umgebung, sodass sie einheitlich bewirtschaftet werden können. Dieser Beitrag stellt wesentliche Prinzipien eines Bebauungsplans und ein Fallbeispiel vor.

Die Europäische Kommission geht davon aus, dass künftig der Großteil der Daten in Bereichen entsteht, in denen Europa stark ist (etwa bei industriellen Anwendungen) – daher stünden den hiesigen Unternehmen "in der Datenwirtschaft der Zukunft alle Möglichkeiten offen" [1]. Allein in der Automobilindustrie liegt das Potenzial für die Monetarisierung von Daten laut der Unternehmensberatung McKinsey bis 2030 weltweit bei 450 bis 750 Milliarden Dollar [2]. Die Initiative GAIA-X zielt darauf ab, solche Wertschöpfungs-Potenziale zu heben, indem ein firmenübergreifender, datenschutzkonformer und souveräner Austausch von Daten ermöglicht wird [3]. Dafür müssen allerdings auch in den teilnehmenden Firmen selbst die Voraussetzungen geschaffen werden.

API-Mandat vs. Daten-Anarchie

Wie das geht, das haben die Cloud-Größen vorexerziert. Ihr Vorteil: Sie konnten ihre IT-Architekturen von Anfang an datenzentrisch auslegen. So gab beispielsweise Jeff Bezos bereits 2002 in seinem bekannten API-Mandat vor, dass ab sofort im Hause Amazon jeglicher Datenaustausch zwischen Apps und Services über Service-Interfaces stattzufinden habe – ausnahmslos und unabhängig von den genutzten Technologien –, und wer sich nicht daran halte, der werde gefeuert [4].

Ganz anders dagegen die Situation in der großen Mehrzahl der Unternehmen. Dort hat sich zumeist ein Zoo von Datensilos angesammelt, die durch eine Vielzahl von Skripten, Schnittstellen und Punkt-zu-Punkt-Verbindungen mehr schlecht als recht zusammengehalten werden. Auf lange Sicht sind solche Spaghetti-Architekturen nicht nur teurer, sondern ein ernsthaftes Hindernis für die Datenwertschöpfungs-Strategie eines Unternehmens. Die Datenqualität ist oft erbärmlich, und große Teile der Daten liegen brach. Laut einer globalen Umfrage von IDC und Seagate nutzen Unternehmen nur ein Drittel der ihnen verfügbaren Daten [5]. Nötig ist deshalb der Umstieg auf eine unternehmensweite datenzentrische IT-Architektur – nach dem Vorbild der Cloud-Giganten, aber eben unter den erschwerten Bedingungen historisch gewachsener IT-Landschaften.

Bebauungsplan für datenzentrische Architekturen

Die wichtigsten Merkmale der Zielarchitektur lassen sich einfach zusammenfassen. Im Kern entkoppelt sie die Daten von den sie erzeugenden Applikationen, indem sie über eine zentrale Datendrehscheibe (Data Hub) kanalisiert werden. Diese nutzt Data-Streaming-Technologien wie Kafka oder MapR, ergänzt um Datenspeicherung auf der Basis relationaler, NoSQL- und Graph-Datenbanken sowie einen Data Lake (in der Regel mit Hadoop). Jede Applikation fungiert als "Produzent" von Daten für den Data Hub, jede Abfrage ist "Konsument" des umfassenden, verteilten Datenbestands. All das ist eingebettet in einen übergreifenden Kontrollrahmen (Data Governance Framework).

Die folgenden Designprinzipien beschreiben zunächst wesentliche Eckpunkte des Bebauungsplans einer solchen Architektur. Der Umsetzung stehen in der Praxis allerdings organisatorische, kulturelle und unternehmenspolitische Hindernisse entgegen – ein fiktives Fallbeispiel zeigt, wie diese überwunden werden können.

Designprinzip 1: Alle Daten laufen als Event-Stream über den Data Hub

Alle Datenquellen pushen ihre Daten per Event-Stream zum Data Hub. Im Fall von Applikation sind das alle Daten aus dem logischen Datenmodell, bei IoT-Geräten alle lokal gesammelten Statusinformationen. Die Daten werden im Quellformat übertragen, es sollte keine Transformation auf Applikationsebene erfolgen. Das vermeidet Fehler und Informationsverluste. Die Anbindung erfolgt nach dem Prinzip "Connect Once" – pro Datenquelle eine Verbindung. Es gibt diverse Möglichkeiten, um die Daten zu überspielen, darunter das MQTT-Protokoll für IoT, Kafka Connect, CDC (Change Data Capture), Apache NiFi etc. Je näher die Übermittlung am Basisdatenmodell des Produzenten erfolgt, desto schneller und günstiger lässt sich die Integration realisieren. Wie die Datenquellen (Produzenten), so kommunizieren auch die abfragenden Apps und Services (Konsumenten) nur über den Data Hub. Dies vermeidet, dass man bei jeder neuen Anfrage nach zusätzlichen Informationen die Interfaces neu justieren muss.

Designprinzip 2: Alle Produzenten veröffentlichen Metadaten

Um die Daten langfristig nutzen zu können, werden alle Daten, die über den Hub laufen, dokumentiert. Dies umfasst mindestens die relevanten Metadaten der Semantik und Klassifizierung. Mit zunehmender Reife beinhalten die Metadaten weitere Informations-Flags wie: DSGVO-relevant, DSGVO-Informationsanforderung, DSGVO-Löschung, automatisch gesammelt, manuell gesammelt, Echtzeitinformationen, periodisch gesammelte Informationen, Vertrauenslevel usw. Eine Governance-Anwendung sammelt diese Metadaten und verwaltet die Datenverschlüsselung und -zugriffe.

Oft enthalten Streams aus einer Quelle Daten unterschiedlicher Sicherheitseinstufung (C1 bis C4, also öffentliche, interne, vertrauliche und geheime Daten). Deshalb ist es notwendig, für jede der Klassifizierungsstufen einen thematischen Kontext (Topic) zu erzeugen und Schlüssel abhängig von der Zuordnung zwischen den Teilnehmern auszutauschen. So können nur jene Abonnenten, die für diese Sicherheitsstufe zugelassen sind, die jeweiligen Daten einsehen. Als ersten Schritt oder Minimum Viable Product können diese Metadateninformationen mit einem rollenbasierten Zugriff für Applikationen kombiniert werden. Damit wird der Zugriff auf Topic-Ebene geregelt. In einer höheren Reifegradstufe lässt sich dies um Informationen aus dem Identity-&-Access-Management auch für den Zugriff über Microservices erweitern.

Designprinzip 3: Jedes Interface ist Teil der CMDB und wird überwacht

Der Data Hub erfordert höchste Verfügbarkeit. Plattformen wie Kafka und MapR sind für solche strikten Anforderungen gebaut, doch möglicherweise nicht alle Konnektoren. NiFi könnte zum Beispiel nur auf einem Knoten laufen, was Hochverfügbarkeitsanforderungen widerspricht – und selbst bei Kafka kommt es vor, dass ein Interface nicht funktioniert wie gewünscht. Umso wichtiger ist es, dass jedes einzelne Interface ein CI in der CMDB darstellt. Zudem gilt es, jedes Interface zu überwachen und ihm spezifische KPIs zuzuordnen. Diese erstellt die IT zunächst manuell, in einer höheren Reifegradstufe lassen sich die Schwellenwerte über maschinelles Lernen (ML) generieren.

Designprinzip 4: Alle Interfaces lassen sich verwalten

Die Umgebung wird sich wahrscheinlich laufend und schnell ändern. Die Architektur muss mit diesen Veränderungen Schritt halten. Changes an produzierenden oder konsumierenden Interfaces müssen reibungslos und kontrolliert erfolgen. Dazu muss die IT alle Interfaces verwalten können, und das Betriebsteam muss im Alltag einfache Interaktionen mit einem einzigen Klick durchführen können. Basisfunktionen wie "Stopp" oder "Neustart" sollten deshalb von Anfang an integriert sein und dem Service Desk und Second-Level Support zur Verfügung stehen.

Designprinzip 5: Die IT pflegt ein Enterprise-Data-Model mit Datenkatalog und Metadatenmanagement

Während die Quelldaten der Produzenten so nah wie möglich am Quellformat in den Hub gelangen, sollte das Konsumieren der Daten in einem standardisierten Format, dem Unternehmensdatenmodell (Enterprise Data Model, EDM), erfolgen. Die IT-Abteilung definiert, veröffentlicht und pflegt dazu ein zentrales EDM. Jede EDM-Einheit wird in einem dedizierten Topic im Data Hub realisiert. Für jedes Topic sind Regeln zu definieren, wer wie darauf zugreifen kann. Die Verwaltung der Zugriffskontrolle und der Richtlinien erfolgt über das Metadatenmanagement. Dieses arbeitet eng mit dem Enterprise-Architecture-Management, den Rollen des Datenmanagements und der Data-Hub-Entwicklung zusammen, unterstützt durch Governance-Funktionen. Die IT-Organisation baut auf dieser Basis einen Datenkatalog für Datenabonnements (Subscriptions) auf. Es muss klare Verantwortlichkeiten für das Datenmanagement geben, einschließlich der zugehörigen Rollen: Data Owners definieren, wie Daten vorgehalten und verwendet werden; Data Stewarts verwalten die Daten nach den Vorgaben der Data Owner und verantworten die Datenqualität und die Festlegung, welche Daten zu löschen sind.

Designprinzip 6: Der Benutzer steht im Mittelpunkt – dafür sind Datenkatalog-Elemente über Microservice-basierte APIs und Micro-UIs verfügbar

Die IT stellt den Datenkatalog für Applikationen, Benutzer und gegebenenfalls Partner bereit. Für Apps stehen die Daten "as a Service" über APIs zur Verfügung, für Benutzer und Partner mittels rollenspezifischer User-Interfaces ("Micro-UIs"). APIs auf der Basis von Microservices und Containertechnologie erlauben die schnelle Entwicklung benutzerzentrierter Apps, die dem Anwender genau jene Informationen liefern, die er benötigt. Das entlastet die Belegschaft im Alltag. Die Apps sind bei höherem Reifegrad nicht nur auf die spezifische Rolle, sondern auch auf Regionen und Kulturen zugeschnitten.

Designprinzip 7: Die Dokumentation ist relevant, konkret, verständlich und leicht zugänglich

Agilität und Governance brauchen Transparenz. Daher ist es ratsam, relevante Informationen in einem Wiki zu dokumentieren, auf das alle zuständigen Mitarbeiter zugreifen können. Zum Inhalt zählen Architekturprinzipien, Best Practices, Ausnahmen von den Regeln und deren Gründe, Protokolle aus dem Architektur-Board, Datenmodelle und insbesondere das EDM, auf dem der Datenkatalog basiert. Sind Quellcode-Komponenten Architekturbestandteil, muss es einen Link in das Code-Repository geben. Architekturkomponenten werden als Best Practices im Architektur-Wiki referenziert. Betriebskonzepte, Testkonzepte, Codierungsregeln und Testdatenmanagement müssen ebenso dokumentiert und zugänglich sein. Dies erleichtert die Zusammenarbeit, unterstützt die kontinuierliche Verbesserung der Umgebung, fördert die Agilität und optimiert Servicebereitstellung und -betrieb.

Designprinzip 8: Die Entwicklung erfolgt mit Test-driven Development und Continuous Delivery

Eine zuverlässige CI/CD-Pipeline mit automatisiertem Testing beschleunigt die Weiterentwicklung der Datenarchitektur, erhöht die Servicequalität und schafft die Basis für agile Entwicklung und DevOps. Mit der wachsenden Anzahl von Testfällen wird auch die Sammlung von Testdaten zunehmen. Diese sind wie der Code selbst in Versionen zu pflegen und ermöglichen damit in einem höheren Reifegrad Performance- und Regressionstests.

Designprinzip 9: Ein "digitaler Zwilling" des Datenbestands bildet die Basis für sämtliche Einsatzfälle der Datennutzung

Die Einführung einer datenzentrischen Architektur dient letztlich dem Ziel, einen "digitalen Zwilling" des gesamten Datenbestands eines Unternehmens oder Ökosystems zu erstellen. Datenkatalogisierung und Metadatenmanagement sämtlicher Daten sorgen für Transparenz und schaffen die Grundlage dafür, die Datenqualität kontinuierlich zu steigern. Das zentrale Datenmanagement macht neben den Datenquellen auch den Wert jeder Quelle und überlappende Datenfeeds erkenntlich. Damit können für sämtliche Einsatzfälle die geeigneten Daten gefunden und analysiert werden – bei höherem Reifegrad mittels ML. Darauf aufbauend unterstützt ein Servicekatalog die Datenwertschöpfung, indem er Daten und Analysen unterschiedlichen Zielgruppen über passende Apps zugänglich macht.

Der Weg zur Datenwertschöpfung

Das folgende Beispiel eines fiktiven globalen Luftfahrt-Logistikunternehmens veranschaulicht das Vorgehen bei der Einführung einer datenzentrischen Architektur. Das Unternehmen hat nach und nach mehrere Firmen übernommen. Das Resultat: eine heterogene Mischung von IT-Landschaften, zugeschnitten auf die Bedürfnisse einzelner Funktionen und/oder einzelner akquirierter Firmen. Applikationen kommunizieren über Punkt-zu-Punkt-Verbindungen, eine einheitliche Datenarchitektur gibt es nicht. Auch eine umfassende Datenanalytik sucht man vergebens: Projekte dazu endeten nach ersten Versuchen, da die Kosten für die Anbindung an zahlreiche Datenquellen zu hoch waren und jede klare Sicht auf die richtigen Quellen fehlte. Das fiktive Beispiel sollte somit IT-Fachleuten aus größeren Unternehmen einigermaßen bekannt vorkommen.

Doch nun die Wende: Mit Unterstützung des Vorstands legt das Unternehmen eine datenzentrische Architektur als Vision fest. Der initiale Business Case besteht darin, einen Data Hub samt Event Streaming und Metadatenmanagement zu realisieren. Die Vorgabe zum Ablauf: Jede Änderung an einem CSV-Austausch führt zur Realisierung einer Kafka-Verbindung. Bereits nach wenigen Monaten fällt auf, dass sich die bisherigen hohen Ausgaben für Interfaces reduzieren. Zugleich erhält die Organisation mit jedem neuen Konnektor einen besseren Einblick in ihre Daten. Allmählich zeigt sich, dass viele externe Schnittstellen überflüssig sind: Das Unternehmen beginnt, unnötige Verträge zu kündigen. Zugleich stellen die Endanwender fest, dass der Datenzugriff nun einfacher ist und die Daten verlässlicher sind.

Als Testballon erstellt die IT einen Data-Cube mit Daten eines Jahres aus einigen Quellen: Sie will verdeutlichen, wie sich Analysen per Data Hub nutzen lassen, um den Vertrieb mit aktuellen Informationen zu versorgen. Die Vertriebsabteilung unterstützt nun die Weiterentwicklung der Architektur. Nachdem die wichtigsten Business-Applikationen mit dem Data Hub verbunden sind, folgt ein PoC, der zeigt, wie benutzerzentrierte Apps den Mitarbeitern auf dem Rollfeld helfen können: Das Bodenpersonal erhält in einer maßgeschneiderten App aktuelle Statusinformationen über den Flug, der zu betreuen ist, ob er Verspätung hat, gerade gelandet ist oder das Gate geändert wurde. Per Chat erhält es Anweisungen vom Vorgesetzten und kann mit Teamkollegen Informationen austauschen. Die Vorteile der neuen App sprechen sich im Unternehmen herum, sodass die IT zahlreiche weitere Forderungen nach solchen Apps erhält.

Für immer mehr Use Cases gibt es somit eine gemeinsame Sprache der Datennutzung. Die Datenqualität steigt weiter, immer mehr Mitarbeiter erhalten benötigte Daten in Echtzeit. Zugleich fällt es dem Management von Quartal zu Quartal leichter, Betriebs- mit Finanzdaten abzugleichen. Als nächsten Schritt plant das Unternehmen, Daten mit Kunden und Partnern zu teilen: Endkunden sollen kostenlose Statusinformationen, Speditionen per Schnittstelle Zugriff auf individuelle Echtzeitdaten erhalten – dies aber gegen Gebühr. Die Monetarisierung von Informationen rückt damit in Reichweite.

Fazit

Sind die Datenbestände einmal per Data Hub mit einheitlichem Datenmanagement und Governance unternehmensweit verknüpft, ist die Grundlage geschaffen, um rasch eine Vielzahl von Anwendungsfällen umzusetzen. Der Weg dorthin ist allerdings nicht einfach und wird angesichts immer komplexer werdender Applikationslandschaften und schnell wachsender Datenbestände auch immer schwieriger. Wie bei allen strategischen IT-Initiativen braucht es Top-Management-Unterstützung und eine solide Governance, um diese Schwierigkeiten zu überwinden – besonderes wichtig sind aber agile Methoden für Architektur-Management, Entwicklung und Betrieb. Denn damit kommen Weg und Ziel in Einklang: Hier wie dort geht es um die Überwindung von Pyramiden und Silos mit dem Ziel, sich weniger mit sich selbst und mehr mit den Kunden zu beschäftigen.

Autor
Das könnte Sie auch interessieren

Neuen Kommentar schreiben

Kommentare (0)