Update vom 31.10.2024 - Version 1.1:
Da uns zum Thema Datenintegration besonders viele Anfragen erreicht haben, haben wir diesen Bereich signifikant erweitert und detailliert ausgebaut. Diese Neuerungen sind v.a. im Kapitel “Quellen und Inbound Integration” aufgeschlüsselt.
Mit der zunehmenden Popularität von SAP Datasphere auf dem Markt sehen wir eine steigende Nachfrage nach Orientierungshilfen zu Governance-Themen wie Space-Setup, Layer-Architektur und Self-Service-Ansatz. Insbesondere SAP BW-Kunden fragen sich, wie sie eine zukunftssichere BI-Landschaft gestalten können, die die radikal erweiterten Möglichkeiten von Datasphere im Vergleich zu einem traditionellen Data Warehouse nutzt. Nachdem wir mit verschiedenen Unternehmen zusammengearbeitet haben, um Datasphere-Systeme mit unterschiedlichen Schwerpunkten zu begleiten und zu implementieren, haben wir unsere Erkenntnisse in einer umfassenden Datasphere-Referenzarchitektur zusammengefasst.
Diese Architektur stellt eine Sammlung von Best Practices dar und ist modular aufgebaut, so dass Sie die Elemente auswählen können, die Ihren Anforderungen entsprechen und für Ihre Systemlandschaft sinnvoll sind. In diesem Blog möchten wir die einzelnen Komponenten auf hoher Flughöhe erläutern und zueinander in Bezug setzen. In künftigen Beiträgen werden wir die einzelnen Themenbereiche noch detaillierter aufschlüsseln. Außerdem freuen wir uns darauf, zu einem späteren Zeitpunkt unsere Best Practices zu anderen wichtigen Datasphere-Governance-Themen wie Entwicklerrichtlinien und Namenskonventionen, Sicherheitskonzepte auf Objekt- und Zeilenebene sowie ETL- und Datenintegrationsstrategien vorzustellen.
Zunächst betrachten wir die Integrationsmöglichkeiten von SAP Datasphere: Von Quellsystemen über etwaige Middleware und entsprechende Datasphere ETL Objekte bis hin zu den Tabellenarten, in welche diese Datenquellen geladen werden.
Wir haben für jedes Quellsystem auf Basis unserer Projekterfahrungen eine strukturierte Bewertung der Integrationsmöglichkeiten durchgeführt und die empfehlenswerteste Option abgebildet. Dabei ist die mächtigste Integrationsform, nämlich die Nutzung des Replication Flows mit Change Data Capture, visuell oben in der Abbildung angesiedelt. Die schwächste Integration mit generischem Delta via Data Flow ist weiter unten. Die Anbindung via Smart Data Integration (SDI) mit dem Data Provisioning Agent (DPA) als Middleware ist zwischen diesen beiden Optionen zu verorten. Sie bietet zwar auch Change Data Capture und ist damit dem Data Flow vorzuziehen, hat sich aber in der Praxis gegenüber dem Data Intelligence (DI) basierten Replication Flow als weniger zuverlässig erwiesen.
Einige Quellen, wie REST APIs und Event Streaming, können aktuell nur über eine Middleware, wie beispielsweise der SAP Integration Suite bzw. SAP Open Connectors, an die Datasphere angebunden werden.
Die BW Bridge ist als Sonderfall außerhalb dieses Bewertungskonstrukts abgebildet.
Der Datasphere-Outbound-Prozess kann in vier Hauptkategorien eingeteilt werden:
Für den Layer-Aufbau verfolgen wir einen minimalen Ansatz mit drei Layern:
Inbound Layer (IL):
Propagation Layer (PL):
Reporting Layer (RL):
Datasphere-Architekten werden oft mit einer Entscheidung konfrontiert: Sollen wir einen separaten Space für Thema XYZ erstellen oder nicht?
Diese Frage ist natürlich nuanciert, aber um es kurz zu machen - die beiden wichtigsten zu berücksichtigenden Faktoren sind:
Ist ein separater Satz an Berechtigungen auf Objektebene erforderlich?
Muss der Workload separat verwaltet werden?
Wenn die Antwort auf beide Fragen "nein" lautet, empfehlen wir, es einfach zu halten und keine zusätzlichen Spaces einzurichten, da diese in dem Fall wenig Nutzen bringen und den Wartungsaufwand erhöhen.
Nach dem Motto "weniger ist mehr" haben wir eine generische Darstellung der bei unseren Kunden üblichen Space Setups zusammengestellt. Diese sind in zwei Bereiche unterteilt:
Generische Spaces:
Layer-agnostische Spaces, die für Autorisierung, Überwachung und Verwaltung verwendet werden.
Haupt-Spaces:
Um eine effektive Self-Service-Strategie für Ihr Unternehmen zu implementieren, ist es notwendig, Ihre Nutzerbasis zu analysieren. Hier wird ein einfaches Framework vorgestellt, um genau das zu tun. Wir können unsere User z.B. in ihre jeweiligen funktionalen Geschäftsteams gruppieren und drei Reifegrade definieren, in die diese Teams eingeordnet werden. Jedes Team würde seine eigene Version dieser Template Spaces mit den entsprechenden Berechtigungen entsprechend der Einordnung erhalten.
Die "Central Reporting Consumers" arbeiten nicht aktiv im Datasphere-System. Sie sind lediglich daran interessiert, das von der IT gemanagte zentrale Reporting in verschiedenen Frontend-Anwendungen zu konsumieren.
Die "Self Service Modellers" wollen innerhalb von Datasphere arbeiten, um Datenmodelle anzureichern, eigene KPIs zu erstellen und Datenmodelle auf neue Arten zu kombinieren.
Das "Data Product Team" ist für die Bereitstellung ihrer Datenmodelle von A-Z verantwortlich. Lediglich die initiale Integration in den Inbound Layer und die Überwachung der Datenbeladungen wird weiterhin vom zentralen IT-Team übernommen.
Jede Einordnung wird unterschiedlich behandelt. Je höher der Reifegrad, desto mehr Autonomie erhalten sie organisatorisch, desto mehr technische Privilegien erhalten sie im System und desto mehr Verantwortung haben sie, eine Art Datenprodukt für den Rest der Organisation bereitzustellen.
Dieser ganze Prozess ist weniger eine technische Herausforderung innerhalb von Datasphere als vielmehr eine organisatorische und Change-Management-Aufgabe. Es kann sich dabei auch nur um eine Analyse des Status quo handeln, oder es kann Teil einer größeren Strategie zur Datendemokratisierung sein, um ein angestrebtes Ziel in Bezug auf die Self-Service- Möglichkeiten zu erreichen. Je nach Benutzerkreis und Zielen Ihres Unternehmens können auch andere Klassifizierungen und Verantwortlichkeiten als die hier gezeigten erforderlich sein.
In jedem Fall muss die Datasphere-Architektur diese Umstände berücksichtigen.
Durch die Kombination dieser Kernideen von:
bieten wir einen modularen Rahmen, der Ihrem Unternehmen hilft, eine zukunftssichere Datasphere-Implementierung voranzutreiben, die Ihre gesamte Datenstrategie unterstützt.
Bleiben Sie gespannt auf ausführliche Blogs und Deep Dives zu einzelnen Bereichen der Architektur. Teilen Sie uns auch gerne Ihre Gedanken und Fragen mit und sagen Sie uns, über welche Bereiche Sie gerne mehr erfahren würden.
Oder möchsten Sie liebe Fragen direkt klären? Warum nicht auch direkt austauschen, hier geht es zum Kalenderlink: https://www.nextlytics.com/meetings/irvin-rodin
Wir freuen uns auf den Austausch mit Ihnen!