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 hohem Niveau 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 & Konsumenten
Hier geht es vor allem darum, aufzuzeigen, wie und wo das Kerndesign der Datasphere Architektur verschiedene Arten von Quellsystemen sowie konsumierende Systeme berücksichtigen muss.
Zu diesem Zweck werden die Quellsysteme in zwei Haupttypen eingeteilt:
- IT Managed: Typische ERP-Systeme, möglicherweise ein On-Premise-BW-System, das side-by-side mit Datasphere läuft.
- Business Managed: Datei-Uploads oder eigenständige kleine Datenbanken, die von einzelnen Abteilungen verwaltet werden.
Zusätzlich werden zwei besonders interessante Quellsystem-Fälle separat behandelt:
- BW Bridge: Ein spezieller Fall, der eine Migration von einem alten BW-System voraussetzt und die Generierung von Datasphere Objekten auf der Basis von BW-Datenmodellen mit der Entity-Import-Funktion beinhaltet.
- 3rd Party Quellen via Middleware: Deckt Fälle ab, bei denen kein Konnektor für einen bestimmten Quellsystemtyp nativ in Datasphere verfügbar ist. Neben SAP Open Connectors hat sich bei uns der Ansatz bewährt, eine günstige Python Runtime via HANA XSA & HDI zu nutzen, um z.B. REST-APIs zu konsumieren.
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)
Finden Sie heraus welches Produkt sich am besten für Ihre Data-Warehousing-Strategie eignet!
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!
