Daten sind die Grundlage digitaler Innovation. Sie ermöglichen fundierte Entscheidungen, treiben KI-Anwendungen an und schaffen neue Geschäftsmodelle. Doch allzu oft bleiben wertvolle Daten in Silos gefangen – ungenutzt und schwer zugänglich.
Dafür kann es sehr valide Gründe geben: Microservices, Domain-driven Design und ganz allgemein das Prinzip des Information Hidings bzw. der Datenkapselung begründen eine Software-Kultur, in der Daten als verborgenes Heiligtum angesehen werden. Zugriff bekommt nur, wer die Hoheit über sie hat. Und das sind üblicherweise die Applikationen, in deren Kontext sie anfallen oder verarbeitet werden müssen. Diese Applikationen fungieren (mit ihren APIs) in der Folge als buchstäbliche Türsteher, die klar regeln, wer Zugriff bekommt – und worauf. Unterm Strich können wir durch diese Indirektion eigentlich nicht mehr davon sprechen, dass wir Daten zur Verfügung stellen, wenn es doch eigentlich „nur“ um einen Service und dessen API geht, die „zufällig“ über ihre Endpunkte (auch) Zugriff auf verborgene Daten aus dem Anwendungskontext gewährt.
So gesehen fungiert der Service als Barriere, die erst aufgebaut werden muss. Und gerade, wenn wir es mit vielen Daten zu tun haben, die wir eigentlich zur Verfügung stellen wollen, erfordern die Entwicklung und die Bereitstellung von Services für die Integration ganz beträchtliche Ressourcen – ein Ansatz, der nur schwer skaliert. Und so richtig kompliziert wird es, wenn Daten externen Partnern zur Verfügung gestellt werden sollen.
Dabei können Daten doch ganz erheblichen Mehrwert liefern, neue Geschäftsmodelle begründen. Für deren Erfolg sollte die Bereitstellung der Daten möglichst effizient erfolgen. Wie können also Unternehmen den Zugriff auf ihre Daten effizient gewährleisten, sowohl intern als auch für externe Partner? Die Antwort: Datenprodukte und APIs. Im Folgenden zeigen wir, wie eine moderne Architektur, inspiriert vom Data-Mesh-Konzept, die Lücke zwischen Datenprodukten und APIs schließt und so neue Möglichkeiten für datengetriebene Innovationen schafft.
Erster Baustein skalierbarer Datenstrategie: Daten als Produkt denken
Das Konzept des Data Meshs wurde von Zhamak Dehghani geprägt und basiert auf der Erkenntnis, dass zentrale Data Lakes oder Data Warehouses oft nicht die Flexibilität bieten, die moderne Unternehmen benötigen. Stattdessen schlägt Data Mesh eine dezentrale Organisation von Daten vor, bei der die Verantwortung für Daten in die jeweiligen Fachbereiche (Domänen) verlagert wird.
Damit ist die Ausgangssituation für ein Data Mesh ganz ähnlich dem eingangs umrissenen Szenario einer Microservice-Landschaft – mit einer wesentlichen Besonderheit: Ein zentrales Konzept beim Data Mesh ist das Datenprodukt. Statt Daten „lediglich“ als Nebenprodukt der operativen Applikationen zu betrachten (die in dedizierten Datenbanken verborgen werden), rückt das Data Mesh sie in den Mittelpunkt: Daten werden als eigenständige, wertstiftende Einheiten angesehen, sie werden zum Produkt.
Beim Datenprodukt geht es jedoch nicht allein um die Vermarktung einer Datenbank oder eines Datensatzes. Das Produkt umfasst auch Governance-Regeln, Zugriffskontrollen, Qualitätsmetriken und standardisierte Schnittstellen für die Nutzung. All das (und mehr) wird beschrieben im Data Contract, der – anders als der Name suggeriert – kein Vertrag, sondern eine Spezifikation der angebotenen Daten ist, vergleichbar mit der OpenAPI-Spezifikation für APIs. Data Contracts beschreiben also, in welcher Form und Qualität ein Datenprodukt bereitgestellt wird, um eine verlässliche Nutzung zu gewährleisten. Dazu gehören auch Informationen zur Datenstruktur, Aktualisierungsfrequenz und Service Level Agreements (SLAs) für den Datenzugriff.
Dieser Produktansatz schafft Verbindlichkeit und ist entscheidend für den Erfolg datengetriebener Use Cases. Von besonderer Bedeutung dabei sind:
- ~Klare Verantwortlichkeiten (Ownership): Jedes Datenprodukt hat ein dediziertes Team, das für seine Qualität und Verfügbarkeit verantwortlich ist.
- ~Gutes Marketing: Damit Datenprodukte im Unternehmen genutzt werden, müssen sie bekannt und einfach auffindbar sein – sei es über ein internes Datenkatalogsystem oder durch gezielte Kommunikation.
- ~Detaillierte Dokumentation: Ein gut dokumentiertes Datenprodukt erleichtert die Integration und reduziert Support-Anfragen. Dabei kann ein wichtiger Aspekt sein zu beschreiben, wie man an die Daten herankommt. Geht das vielleicht nur über bestimmte vorgegebene Queries? Das muss dokumentiert werden!
Innerhalb eines Unternehmens gibt es vielfältige valide und relevante Use Cases für Datenprodukte. Sie können zum Beispiel für interne Reportings, für Machine-Learning-Modelle oder für operative Echtzeit-Analysen genutzt werden. Entscheidend ist, dass sie nicht nur als technische Assets betrachtet werden, sondern als Produkte mit einem klaren Mehrwert für die Nutzenden. Für maximalen Erfolg sollten Datenprodukte auf genau diesen Mehrwert zugeschnitten und damit use-case-spezifisch sein. Die fachliche Betrachtungsweise bietet noch einen weiteren Vorteil: Datenprodukte können auch von Fachabteilungen definiert werden.
So werden Datenprodukte zum ersten Baustein einer skalierbaren Datenstrategie und dienen zumeist analytischen Zwecken, könnten jedoch auch von Individualsoftware verwendet werden. Doch eine Einschränkung bleibt: Datenprodukte richten sich an unternehmensinterne Konsument*innen, nutzen sie doch Datentechnologie wie beispielsweise SQL als prominenten Vertreter. Derartige Wege bleiben externen Parteien verschlossen, da sie durch die notwendige Öffnung eigentlich interner Systeme und Infrastruktur große Risiken und Herausforderungen mit sich bringen würden. Und manche Systeme oder SaaS-Lösungen erfordern möglicherweise eine HTTP-API für die Integration.
Zweiter Baustein skalierbarer Datenstrategie: APIs als Brücke
Derartige Zugriffe benötigen also eine weitere Abstraktionsschicht – APIs.
Datenprodukte schaffen eine solide Grundlage für die Bereitstellung von Daten. Um sie auch externen Stakeholder*innen verfügbar zu machen, braucht es weitere flexible und standardisierte Möglichkeiten. Hier kommen APIs als öffentliche Schnittstellen ins Spiel. Untermauert werden sie von den klassischen Fähigkeiten des API-Managements: Authentifizierung, Zugriffskontrolle oder auch Monetarisierung – essenziell für die sichere und wirtschaftliche Bereitstellung von Daten. Weiterer großer Mehrwert von API-Management sind Protokoll-Standardisierung und Zugriffsvereinfachung.
APIs bieten darüber hinaus den Vorteil, das Nutzungserlebnis beim Zugriff auf die Daten durch weitere Funktionalitäten zu steigern. Dazu können spezialisierte Filterungs- und Abfragemöglichkeiten oder verschiedene Export-Formate zählen.
Man ahnt es schon: Hierfür ist eine Integration erforderlich, die diese zusätzliche, die Daten ergänzende Funktionalität zur Verfügung stellt. Das bedeutet jedoch nicht automatisch, dass die API als manuell erstellte Schnittstelle zur Integration zu betrachten ist. Wir wollen explizit nicht für jedes Datenprodukt durch klassische API-Entwicklung eine neue, individuelle Lösung entwickeln (und warten). Das ist in den meisten Fällen zu zeitaufwendig und teuer.
Das Ziel ist vielmehr, die Integration effizient, skalierbar und wiederverwendbar zu gestalten. Das Stichwort dabei ist Automatisierung. Als Ausgangspunkt dafür dienen die Gemeinsamkeiten der intern bereitgestellten Datenprodukte, die Spezifikation der API zum Datenprodukt, ergänzt um gegebenenfalls zusätzlich benötigte Konfigurationsparameter, die dementsprechend Teil des Datenprodukts sein können. Daraus können wir automatisiert einen API-Service generieren. So entsteht eine standardisierte Schnittstelle. Der Ansatz reduziert Entwicklungsaufwände drastisch, sorgt aber gleichzeitig für eine konsistente API-Qualität: Entwickler*innen müssen lediglich die Konfigurationsdatei oder API-Spezifikation anpassen, ohne den API-Code selbst schreiben zu müssen.
Fazit: Daten effizient nutzen, statt sie nur zu besitzen
Zusammengefasst kombiniert unser Architekturansatz für eine skalierbare Datenstrategie Datenplattformen mit automatisierter API-Generierung. Die Idee dahinter ist, dass ein Datenprodukt nicht nur die Daten selbst bereitstellt, sondern auch Metadaten und Konfigurationsparameter, die zur automatisierten Erstellung einer API genutzt werden können.
Der Ablauf auf einen Blick:
- ~Ein Datenprodukt wird definiert, inklusive Datenstruktur, Zugriffskontrollen und Qualitätsmetriken.
- ~Eine API wird automatisch aus den Datenprodukten generiert, basierend auf einer zentralen Konfigurationsvorlage.
- ~API-Management übernimmt Governance und Sicherheit, sodass beispielsweise Zugriffsrechte, Abrechnungsmodelle oder Monitoring-Mechanismen integriert sind.
Auf diese Weise verbinden wir die unterstützenden, querschnittlichen Fähigkeiten des API-Managements, flexible und das Nutzungserlebnis steigernde Zusatzfunktionen rund um den Zugriff auf Daten mit eben den Daten selbst, die mit Datenprodukten gezielt auf bestimmte Anwendungsfälle zugeschnitten sind, um maximalen Mehrwert zu schaffen.
Daten sind das Rückgrat der digitalen Wirtschaft. Doch erst durch eine Kombination aus Datenprodukten und APIs wird ihr volles Potenzial entfaltet. Datenprodukte ermöglichen es, Informationen strukturiert und verantwortungsvoll innerhalb eines Unternehmens bereitzustellen. APIs sorgen dafür, dass diese Daten flexibel und effizient in Anwendungen integriert werden können – sowohl intern als auch extern.
Ein Architekturansatz, der auf Automatisierung und Code-Generierung setzt, bietet den entscheidenden Vorteil, APIs nicht als manuell erstellte Einzelprojekte zu betrachten, sondern als skalierbare Schnittstellen, die sich aus Datenprodukten ableiten lassen.
Die Zukunft gehört Organisationen, die Daten nicht nur sammeln, sondern auch intelligent bereitstellen und nutzen.
Data for the People!
