Um es vorwegzunehmen, die SAP Datasphere alleine ist (noch?) kein vollständiger Ersatz für ein bestehendes On-Premise SAP BW, hat aber schon eine Vielzahl interessanter und durchaus verwendbarer Bestandteile hierzu. Tatsächlich ist die Entwicklung von Cloud-Produkten das strategische Ziel der SAP.

Mit der SAP Datasphere hat die SAP ein neues Cloud-Produkt an den Start gebracht.

Zusammen mit der SAP Analytics Cloud (SAC) und der SAP HANA Cloud ist so ein neues universelles Business Intelligence Werkzeug entstanden, das durchaus eine nähere Betrachtung verdient.

Die SAP stellt umfangreiche Migrationstools bereits, um ein On-Premise BW in die BW-Bridge zu migrieren. Ist das Quell-BW bereits ein BW/4 HANA ist die Migration recht elegant durchführbar. Für ältere Objekttypen wie Cubes, DSOs, Multiprovider etc. gilt das Gleiche wie bei einer Migration auf ein BW/4: Möglicherweise sind manuelle Vor- und Nacharbeiten erforderlich. Die Installation der BW-Bridge erfolgt einfach durch Zubuchen des entsprechenden Service.

Aber es gibt auch gravierende Unterschiede: Der gravierendste ist, dass die BW-Bridge keinen OLAP beinhaltet, es können also keinerlei analytische Anwendungen entwickelt (oder migriert) werden. AdHoc Analysen, Querys (auch als Datenquellen) oder analytische Berechtigungen sind daher nicht möglich. Auch eine Rückverbindung, also der Bau eines Composite Providers über BW-Bridge-ADSOs und On-Premise Providern auf dem On-Premise BW ist nicht möglich. Obwohl die BW-Bridge zwar innerhalb der Plattform läuft, ist auch eine Smart Data Access Datenanbindung nicht möglich. Modelle, die sich nativer HANA-Objekte wie Calculation Views bedienen, lassen sich nicht in der BW-Bridge abbilden.

Während die SAP BW-Bridge sich aus Entwicklersicht als ein BW-System innerhalb Eclipse darstellt, stellt sich die BW Bridge aus Sicht der SAP Datasphere als „Space“ dar. Die Bridge-InfoProvider, also insbesondere die Tabellen der aktiven Daten, können anderen Spaces lesend zur Verfügung gestellt werden. Hierauf setzt dann falls noch notwendig der „normale“ ETL-Prozess von SAP Datasphere auf.

Hauptfunktionalität von SAP Datasphere ist die Datenakquisition aus verschiedenen Datenquellen, Transformation und Speicherung von Daten in der zugrunde liegenden HANA.

Neben einem eher IT-getriebenen Ansatz zum ETL-Prozess, dem Staging und der Definition grundlegender Transformation, ermöglicht SAP Datasphere auch dem Informationskonsumenten also dem Fachbereich eine Art Self-Service, um eigene Business Modelle darauf basierend zu entwickeln.

Bestimmte Funktionalitäten sind auf andere Produkte ausgelagert (weitere Details später im Text):

Bei einigen der folgenden Eigenschaften von SAP Datasphere ist zu erkennen, dass bei der Produktentwicklung Ideen der HANA-DB aufgegriffen wurden, z.T. erweitert und mit leichter bedienbaren Konzepten für SAP Datasphere nutzbar gemacht wurden. Überhaupt ist SAP Datasphere deutlich verwandter mit einem SQL-BI als mit dem SAP-BW.

SAP Datasphere ist in sogenannten „Spaces“ organisiert (DB-Schemata). Zwischen den Spaces können Freigaben realisiert werden, um so Daten aus einem Space in einem anderen Space zu konsumieren. Spaces gehen über die reinen Ordnungsmöglichkeiten von InfoAreas hinaus, Spaces voneinander zunächst isoliert. Auch können Quotas, also maximale Speicherverbräuche und Prioritäten pro Space eingestellt werden, besonders bei für Anwender freigegebenen Spaces ist dies sinnvoll.

Objekte der Staging-Ebenen können flexibel in Spaces organisiert werden – hierfür schlägt die SAP lediglich eine Nomenklatur vor.

Eine der zentralen Fähigkeiten von SAP Datasphere ist es, Daten aus externen Systemen in die HANA Datenbank von SAP Datasphere zu schaffen oder nicht (Remote Table bzw. View oder Persistierung dieser virtuellen Objekte). Neben der BW-Bridge gibt es eine Vielzahl weiterer Verbindungsmöglichkeiten. Während ODATA direkt konsumiert werden kann, muss für die Verbindung mit einer On-Premise HANA noch der Data Provisioning Agent zusätzlich installiert werden, der ähnlich dem Cloud-Connector die Schnittstelle zwischen den On-Premise-Systemen und der Cloud realisiert. Die Quelltabellen sind via SAP HANA Federation Framework Smart Data Integration (SDI) oder via Smart Data Access (SDA) als Remote Table innerhalb von SAP Datasphere sichtbar.

Als Quellen können u.a. CDS-Views, ODATA, JSON, EXCEL oder CSV-Files, Datenbank-Tabellen oder auch S-API Datasourcen (Delta hierbei nur mit BW-Bridge) dienen.

Neben dem freien DBeaver gibt es eine ständig wachsende Menge an möglichen Datenquellen (Quelle SAP):

Um Daten (virtuell oder persistent) in einem Space zu transformieren, bietet SAP Datasphere verschiedene Möglichkeiten zur grafischen oder gescripteten semantischen Modellierung des Analytic Models.

Während das schlussendliche Analytic Model im Business Builder erstellt wird, sind dem i.d.R. mehrere Datenmodelle aus verschiedenen Spaces vorgeschaltet, die mittels Data Builder konstruiert wurden.

Im Data Builder können Views und persistente Tabellen modelliert werden. Auch können diese dort administriert werden (Modell Update, Remote Tables Refresh, Datenlöschen oder Neu-Beladen).

Views können auch mittels SQL-Editor erstellt werden, so dass das ganze Spektrum von HANA SQL Script zur Verfügung steht. Eine semantische Modellierung kann in einem ER-Editor entwickelt werden.

Welche Operationen (Joins, Unions, Filter, Berechnungen, Lookups, SQLs etc.) über welche Tabellen und Views durchgeführt und in welchem Ziel View oder welcher Zieltabelle das Ergebnis abgelegt wird, wird im Dataflow Modeller graphisch entwickelt.

In welcher Reihenfolge Quellsystembeladungen (Replikationen oder Refresh von persistierten Remote tables) oder welche Dataflows ausgeführt werden, wird in Task Chains modelliert. Weitere Automatisierungen sind in Python 3 oder auch via Shell Script realisierbar.

Im Business Builder werden nun die tabellenartigen Datenartefakte der Data Models zu einem Analytic Model zusammengefasst, also ein Snow Flake Schema bestehend aus Fakten, Dimensionen, Hierarchien und Texten. Das Business Modell kann entsprechend der Anforderungen die Mengen der Fakten und Dimensionen vereinfachen (also Selektion und Projektion).

Die direkt aus SAP Datasphere aufrufbare SAC kann nun diese Analytic Models darstellen. Hierbei kann SAC direkt auf die Modelle von SAP Datasphere zugreifen und nicht etwa über den Umweg eines zwischengeschalteten Cloud Connectors. SAP Datasphere und SAC sind dann verschiedene Tennants derselben HANA.

Ob die Analytic Models nun von der IT designt werden, oder ob nach entsprechender Datenfreigabe die Fachbereiche hier bereits selbständig tätig werden dürfen oder vielleicht erst in der SAC, ist eine nicht triviale Designentscheidung.

Natürlich gibt es eine ausführliche Benutzerverwaltung und die Möglichkeit, individuelle Rollen und Zugriffsrechte zu verwalten, angelehnt an die HANA-Berechtigungen (inkl. eines Uploads).

Der Transport erfolgt, indem die Modelle einzelner Spaces exportiert und dann auf z.B. der QS oder Prod importiert werden. Das System merkt zwar, wenn im Ziel Objekte überschrieben werden sollen und führt auch über alle Importe Buch – eine weitere Unterstützung eines ausgefeilten Transportsystems gibt es aktuell nicht. (Die HANA Deployment Infrastructure HDI wird nicht genutzt)

Während die Data Flows aus der SAP Data Intelligence verwendet werden können, ist noch unklar, in welchem Umfang auch die DI in SAP Datasphere eingebunden werden wird (oder was die Nutzung davon dann kosten wird).

Im Unterschied zur SAP BW bekommt man keine Typisierung der Kennzahlen oder Merkmale in Form von InfoObjekten geschenkt: Ob eine Zahl – z.B. namens 0GROSS_VAL in Beleg-, Landes- oder Konzernwährung dargestellt wird oder gar ein Attribut mit der Semantik Telefonnummer ist, muss der Modellierer wissen. Es könnte auch einfach ohne Warnung eine andere, falsche Zuordnung im Reporting gewählt werden. Dass ein Objekt 0MATERIAL eine Farbe hat, und die Merkmale des Materials nicht stattdessen mit Lieferantennummern assoziiert werden sollten, würde – zugegeben überspitzt – auch nicht während der Modellierung sondern erst im Test auffallen.

Auch kann derzeit keine Semantik aus den Quelltabellen übernommen werden, wie man es z.B. von HANA- Calculation Views kennt und der Typ des „Feldes“ recht erfolgreich „automatisch“ bestimmt wird.

Aktuell ist eine Planung (z.B. mit Massendaten-Disaggregation und Verteilung) in SAP Datasphere nicht möglich – hierzu muss auf die Möglichkeiten der SAC zurückgegriffen werden.

Es lassen sich Bestandskennzahlen nicht abbilden.

Die maximale Gesamtgröße von SAP Datasphere ist derzeit auf 4TB beschränkt.

Wahrscheinlich ist dieser Text schon während des Schreibens auf Grund der hohen Innovationsgeschwindigkeit von SAP Datasphere wieder veraltet: SAP Datasphere wird üblicherweise alle zwei Wochen aktualisiert, die BW-Bridge derzeit alle drei Monate. Die größeren (Mindest-) Feature-Updates sind schon für die nächsten 1,5 Jahre vorausgeplant.

Erklärtes strategisches Ziel der SAP ist der Weg in die Cloud.

SAP Analytics Cloud hat bisher noch eine umfangreiche Modeliierung und Transformation der Daten in der Cloud-Datenhaltung gefehlt, dies hat die SAP mit der SAP Datasphere geschaffen und gleichzeitig auch dabei Doppelentwicklungen durch eine klare Aufgabentrennung zwischen SAC und SAP Datasphere vermieden.

SAP Datasphere inklusive der BW-Bridge ermöglicht einen soften Übergang von On-Premise-Systemen in die Cloud, es sind sogar auch eine Vielzahl Hybridansätze (On-Premise und Cloud, beim Staging oder der Modellierung) denkbar, so dass man sich die beste Lösung für ein Datenmodell heraussuchen kann.

Mit der BW-Bridge hat die SAP ein Migrationsszenario geschaffen, das – wäre hier nicht kräftig auf die Entwicklungsbremse gedrückt worden – durchaus als Standalone-Produkt geeignet wäre. Aktuell werden fehlende Features der SAP Datasphere durch die Bridge gefüllt, was dann aber nur als Provisorium gemeint sein kann. SAP Datasphere kann nicht mit SAP BW verglichen werden, dafür sind die Ansätze zu unterschiedlich. Wie sich die SAP Datasphere gegenüber anderen SQL basierten BI-Lösungen behaupten wird, bleibt abzuwarten.

Bei der Wahl Ihrer BI Strategie, bei der Entwicklung eines möglichen Migrationsplans aber bei der Realisierung, kann die Bitech neutral, fachlich und auch technisch unterstützen.