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.
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:
Zusätzlich werden zwei besonders interessante Quellsystem-Fälle separat behandelt:
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!