Datasphere Referenzarchitektur - Überblick & Ausblick

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.

Die Schlüsselkomponenten

Quellen und Inbound Integration

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.

Konsumenten & Outbound Integration

Der Datasphere-Outbound-Prozess kann in vier Hauptkategorien eingeteilt werden:

• ODBC: Die einfachste, aber zuverlässigste und universellste Technik. Drittanbieteranwendungen und Clients können Datasphere-Daten aus der zugrunde liegenden HANA-Datenbank abrufen. ODBC unterstützt jedoch keine anwendungsschichtspezifischen Konzepte wie Semantik, Assoziationen, DACs oder nicht-relationale Objekte wie analytische Modelle.
• OData/Nativ: Native Verbindungen, wie z. B. SAC und Excel-Add-in, sind in Bezug auf die Datenverarbeitung das non plus ultra und unterstützen alle Funktionalitäten. OData ist theoretisch fast gleichauf, aber es fehlt an guten Out-of-the-Box-Lösungen (z.B. Power BI + Datasphere OData Einschränkungen).
• Premium Outbound Integration: Ermöglicht Replikationsflüssen die Daten in verschiedene Zielsysteme zu pushen. Diese Methode ist mit hohen Zusatzkosten verbunden.
• Andere: Jedes Szenario (z.B. REST), das nicht von den anderen drei Kategorien abgedeckt wird, muss mit Hilfe einer Middleware implementiert werden.

Einfache Layer-Architektur

Für den Layer-Aufbau verfolgen wir einen minimalen Ansatz mit drei Layern:

Inbound Layer (IL):

• Dateningestion aus verschiedenen Quellen
• meist 1-1 mit leichten Erweiterungen wie einem Quellsystemfeld oder einem Ladezeitfeld
• obligatorische Persistenzschicht (lokale/remote Tabellen)

Propagation Layer (PL):

• Harmonisierungen zwischen verschiedenen Quellen
• semantische Anreicherung & Datenzugriffskontrollen finden spätestens hier statt
• enthält den Großteil der komplexen Businesslogik und Transformationen
• optionale zweite Persistenzschicht (View Persistenz) je nach Performance-Auswirkung

Reporting Layer (RL):

• ermöglicht den Datenkonsum als Zugriffsschicht für Reporting-Clients und -Konsumenten
• begrenzte Modellierung (nur laufzeitrelevante Logik) und keine Persistenz
• der verwendete Objekttyp hängt vom Konsumentensystem ab (Analytic Model oder exposed View)

Sehen Sie sich die Aufzeichnung unseres Webinars
"SAP Datasphere and the Databricks Lakehouse Approach - How to build a Future-Proof Data Platform" an!

Space-Konzept: "Weniger ist mehr"

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:

• Beinhaltet einen zentralen IT-Space mit Datenmodellen für das zentrale Reporting und IT-verwaltete Datenprodukte,
• einige spezielle Spaces mit dem BW Bridge Inbound Space (der eine technische Voraussetzung für ein BW Bridge System ist) und einem ODBC Consumption Space (der ein notwendiger Workaround für eine Vielzahl von ODBC Anwendungsfällen ist),
• sowie mehrere Business Spaces, die unterschiedliche Self-Service-Reifegrade darstellen und dementsprechend eine unterschiedliche Integrationstiefe in die Simple Layer Architecture aufweisen, u.a. durch das sharen von Objekten aus der entsprechenden Layer der zentralen IT-Space.

Self Service Reifegradmodell

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.

Datasphere Referenzarchitektur -  Unser Fazit

Durch die Kombination dieser Kernideen von:

• einer einfachen Layer-Architektur,
• einem "weniger ist mehr"-Ansatz für ein Space-Konzept,
• eine Self-Service-Strategie, die die Reifegrade der Benutzerbasis berücksichtigt
• und wie verschiedene Arten von vor- und nachgelagerten Systemen mit der Kernarchitektur interagieren,

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!