[ Falls Sie es verpasst haben, lesen Sie Teil 1: Die nicht skalierbare Datenplattform ]

Viele Datenplattformen werden heute von unten nach oben aufgebaut. Zunächst werden Daten gesammelt, die „später nützlich sein könnten“, und dann werden nach und nach Lösungen zusammengeflickt, wenn Bedarf entsteht. Dieser Ansatz führt unweigerlich zu einer fragmentierten Implementierung, steigenden Kosten und technischen Schulden. Die Entwicklung von Datensystemen erfordert spezielles Fachwissen in den Bereichen Datenmodellierung, verteilte Systeme, Sicherheit und Compliance. Die meisten Unternehmen können sich in der Anfangszeit einfach keine dedizierten Dateninfrastrukturteams leisten und müssen ihre Datensysteme im Laufe ihres Wachstums aufbauen und anpassen.

Die Weiterentwicklung bestehender Systeme kann jedoch recht anspruchsvoll sein. Teams müssen sich oft zwischen langwierigen Migrationen mit der Wartung mehrerer doppelter Systeme oder einer kostspieligen vollständigen Systemumstellung entscheiden. Die Entscheidung von Netscape, seine Browser-Engine 1997 neu zu schreiben, kostete das Unternehmen sein Browsergeschäft und seine Marktdominanz an den Internet Explorer, da es mit den schnellen Funktionsfreigaben des Internet Explorers nicht konkurrieren konnte, was schließlich zu einem Rückgang seines Marktanteils führte. Viele Unternehmen beginnen mit benutzerdefinierten Lösungen und migrieren im Zuge ihres Wachstums zu Anbieterplattformen. Doch selbst in einem Umfang, in dem sich Unternehmen Anbieterplattformen leisten können, passen diese möglicherweise immer noch nicht zu ihren Anwendungsfällen, und interne Benutzer müssen sich an neue Arbeitsabläufe anpassen. Viele Unternehmen entwickeln im Zuge ihrer weiteren Skalierung letztendlich benutzerdefinierte Lösungen auf Anbieterplattformen. Interne Infrastrukturteams müssen nun ihre ursprünglichen Systeme warten, Anbieterplattformen betreiben und benutzerdefinierte Implementierungen auf diesen Plattformen unterstützen – während sie gleichzeitig Benutzer in verschiedenen Tools schulen und Sicherheit und Integrationen über mehrere Systeme hinweg handhaben. Aufgrund mangelnder Planung und organischen Fortschritts im Zuge der Unternehmensskalierung wird eine ursprünglich billigere Lösung deutlich teurer und komplexer im Betrieb.

Die Entwicklung von Datenplattformen, die mit dem Unternehmenswachstum skalierbar sind, ist heute einfacher als je zuvor. Im letzten Jahrzehnt haben viele Organisationen klare Muster bei der Datennutzung entwickelt: Produktteams benötigen Daten zum Nutzerverhalten, Marketingteams verfolgen die Kampagnenleistung, Finanzteams überwachen Umsatzkennzahlen und Sicherheitsteams analysieren Bedrohungsmuster. Diese gängigen Anwendungsfälle sind hinsichtlich der benötigten Daten und der benötigten Zeit gut etabliert. Anstatt Anforderungen durch kostspielige Migrationen und Nachrüstung von Anbieterlösungen zu ermitteln, ist es möglich, eine Datenplattform zu erstellen, die hinsichtlich Kosten und Betriebseffizienz nachhaltig skalierbar ist.

Entwerfen von Datenplattformen

Im Kern kann eine Datenplattform durch zwei grundlegende Komponenten definiert werden: welche Daten Sie benötigen (Datenmodelle) und wie schnell Sie sie benötigen (Latenzanforderungen). Selbst bei einem lose definierten Anwendungsfall können wir durch das Verständnis dieser beiden Komponenten systematisch Datenerfassungsmechanismen und Infrastrukturanforderungen ableiten.

Nehmen wir beispielsweise die Betrugsrisikoerkennung. Zur Betrugsrisikoerkennung sind in der Regel drei Datenkomponenten erforderlich: Identitäts-, Transaktions- und Fallmanagement.

Jede Datenkomponente kann basierend auf den Latenzanforderungen einer Infrastruktur zugeordnet werden. Identitäts- und Transaktionsüberprüfung erfordern Stream-Verarbeitung für Betrugserkennung in Echtzeit, Datenbankverarbeitung übernimmt laufende Überwachung und Warnungen und Data Lakes unterstützen länger andauernde Aufgaben wie Musteranalyse und Modelltraining.

Datenmodelle

Ein Datenmodell definiert, wie Daten organisiert und standardisiert werden sollen. Es gibt eine Reihe von Feldern und deren Eigenschaften an – das Format, den Typ und die Regeln für jedes Feld. Die Schemata ermöglichen die Datenermittlung, während Definitionen einzelner Felder Governance-Richtlinien und Compliance-Anforderungen bestimmen.

Gut definierte Datenmodelle ermöglichen eine standardisierte Datenerfassung und -verarbeitung im gesamten Unternehmen. Nehmen wir beispielsweise Benutzerdaten: Das Marketing benötigt sie für die Kampagnenverfolgung, der Kundenservice für das Fallmanagement, Produktteams für Verhaltensanalysen und Risikoteams für die Betrugserkennung. Ohne ein gemeinsames Benutzerdatenmodell erstellt jedes Team seine eigene Version von Benutzerprofilen und Tracking-Logik. Die Teams müssen am Ende komplizierte Integrationen erstellen, um Benutzerdaten zwischen Systemen aufzulösen und abzugleichen. Ein gemeinsames Datenmodell, das als einzige Quelle der Wahrheit dient, vereinfacht die Datenerfassung und -implementierung, während einheitliche Standards die Verwaltung von Sicherheit und Compliance wesentlich einfacher machen.

Die Definition umfassender Datenmodelle ist für einzelne Teams oft schwierig, da sie sich normalerweise auf ihre unmittelbaren Bedürfnisse konzentrieren. Marketingteams konzentrieren sich auf kampagnenbezogene Felder, während Risikoteams sich auf Attribute zur Identitätsüberprüfung konzentrieren. Ohne eine ganzheitliche Sicht darauf, wie dieselben Daten verschiedenen Funktionen dienen, erstellen Teams oft unvollständige oder eng fokussierte Datenmodelle, die eine weitere Verarbeitung und Integration zwischen Systemen erfordern.

Zeitliche Anforderungen

Der Zeitbedarf definiert, wie schnell Daten verarbeitet und verfügbar gemacht werden müssen. Die Verarbeitungszeitfenster reichen von Echtzeit (Sekunden) für sofortige Entscheidungen über nahezu Echtzeit (Minuten) für die Überwachung bis hin zur Stapelverarbeitung (Stunden) für Analysen und KI/ML-Anwendungen. Diese Zeitanforderungen entsprechen bestimmten Infrastrukturoptionen – Streaming für Echtzeit, Datenbanken für nahezu Echtzeit und Data Lakes für die Stapelverarbeitung.

Ohne Framework bauen Produktteams häufig redundante Infrastrukturen für ähnliche Anforderungen auf. So verwendet ein Team beispielsweise Kafka, während ein anderes MSK für das Streaming verwendet, oder ein Team entscheidet sich für DynamoDB, während ein anderes Cassandra für Datenbanken verwendet. Dies führt zu unnötiger Komplexität, da die Teams mehrere Systeme mit doppelten Sicherheitskontrollen und Integrationen verwalten.

Durch die Standardisierung von Infrastrukturkomponenten müssen Produktteams keine eigene Infrastruktur mehr bereitstellen und Plattformteams können den Betriebsaufwand reduzieren, da sie weniger Systeme warten müssen. Diese Standardisierung ermöglicht außerdem bessere Sicherheitskontrollen, optimierte Integrationen, vereinfachte Beobachtbarkeit und optimierte Kosten.

Generische Datenplattform

Ein Datenplattform-Architektur-Framework ermöglicht es uns, Datenerfassungsspezifikationen, Infrastrukturanforderungen, Sicherheitskontrollen und Integrationsfunktionen systematisch abzuleiten. Dies geht direkt auf die Komplexitäts- und Kostenspirale ein, mit der viele Organisationen heute konfrontiert sind. Anstatt dass Teams separate Systeme erstellen, die von Plattformteams nur schwer unterstützt werden können, vereinfacht ein konsistentes Framework die Sicherheit, Compliance, Integration und Kostenverwaltung im gesamten Unternehmen.

Ohne eine konsistente Implementierung stehen Plattformteams ständig vor der Entscheidung, ob sie bestehende Systeme warten, kostspielige Migrationen durchführen oder neue Funktionen entwickeln möchten. Plattformteams verbringen die meiste Zeit mit der Wartung unterschiedlicher Systeme und der Abwicklung von Migrationen, anstatt geschäftskritische Funktionen bereitzustellen. Ein Framework-basierter Ansatz ermöglicht es Unternehmen, ihre Datenplattformen ohne störende Migrationen zu skalieren. Kleinere Unternehmen können mit den erforderlichen Komponenten beginnen und diese mit ihrem Wachstum erweitern, und größere Unternehmen können ihre bestehenden Systeme einmalig standardisieren, ohne sie ständig neu schreiben zu müssen.

Als nächstes

In Teil 3 der Serie „One Off to One Data Platform“ besprechen wir, wie dieses Framework auf praktischer Ebene umgesetzt werden kann. Wir untersuchen, wie gängige Datenplattformkomponenten wie Streaming, Datenbanken, Data Warehouse und Data Lake zusammengestellt werden können, um verschiedene Geschäftsanwendungsfälle mit konsistenten Sicherheits- und Compliance-Kontrollen zu unterstützen. Wenn Organisationen wachsen, ermöglicht dieser modulare Ansatz Teams, einzelne Komponenten unabhängig voneinander zu skalieren und gleichzeitig standardisierte Schnittstellen und Kontrollen beizubehalten, wodurch die Notwendigkeit ständiger Migrationen entfällt. Mit einem klaren Datenplattformarchitektur-Framework können Organisationen Datenanwendungen erstellen, die mit ihrem Geschäft wachsen, anstatt es einzuschränken.