Datenprodukte in der SAP BDC: 10 Kerneigenschaften
Wenn Sie als SAP-Architekt, Data Engineer oder SAP-BW-Verantwortlicher heute Datenlandschaften aufbauen, stehen Sie vor einer neuen Realität: Infoobjekte und Composite Provider reichen nicht mehr aus, um Fachbereiche, Databricks-Umgebungen und externe Datenkonsumenten zu bedienen. Die Antwort der SAP BDC auf diese Anforderung sind Datenprodukte. Sie verändern, wie Sie Daten modellieren, teilen und verantworten.
Dieser Artikel erklärt kompakt und technisch fundiert, was ein Datenprodukt ausmacht, welche Kerneigenschaften es erfüllen muss und wie SAP diese über Data Catalog, Object Store und Zero-Copy-Verfahren umsetzt. Erfahren Sie mehr zur Relevanz von Datenprodukten in der SAP-Business-Data-Cloud-Architektur und wo SAP Datasphere, SAP Databricks und SAP BDC Connect konkret zusammenspielen.
Was ist ein Datenprodukt?
Der Begriff Data Product bzw. Datenprodukt ist ein Überbegriff, der auch außerhalb des Kontextes von SAP Business Data Cloud (SAP BDC) Verwendung findet. Je nach Anwendungsgebiet hat er allerdings unterschiedliche Bedeutungen. Im SAP-Bereich ist ein Datenprodukt eine sorgfältig aufbereitete, wiederverwendbare Datenlösung, die so gestaltet ist, dass sie vielfältige Geschäftsanforderungen optimal unterstützt. Es kombiniert qualitätsgesicherte Daten mit klarer Semantik, Governance und definierten Zugriffsmechanismen und wird als konsumierbare Einheit bereitgestellt.
Wie ist der Begriff Data Product entstanden?
Der Begriff wurde erstmals 2012 in dem Artikel »Data Scientist: The Sexiest Job of the 21st Century« von Thomas H. Davenport und D. J. Patil im Harvard Business Review erwähnt. Der Artikel, der in der Fachwelt auf breite Resonanz stieß, beschreibt die Arbeit eines Data Scientists und wie seine Arbeit Mehrwerte generiert. Ein zentraler Punkt ist dabei, wie Daten und deren Mehrwerte zukünftig behandelt bzw. gemessen werden können.
Was ist ein Data Mesh?
Die Begründerin des Konzepts Zhamak Dehghani beschrieb mit dem Begriff Data Mesh eine neue Art, mit Daten zu arbeiten. Sie führte damit nicht nur ein Architekturkonzept ein, sondern beschrieb auch, wie Organisationen dafür aufgebaut werden sollten. In diesem Konzept werden Daten als Produkte betrachtet, die bestimmte Kerneigenschaften besitzen, die wir im Folgenden näher beleuchten.
Welche Kerneigenschaften hat ein Datenprodukt?
Die Kerneigenschaften eines Datenprodukts sind:
- Auffindbar (Discoverable)
- Verständlich (Understandable)
- Adressierbar (Addressable)
- Einheitlicher Zugriff (Natively accessable)
- Mehrwert aus sich selbst (Valuable on its own)
- Datenintegrität (Integrity)
- Interoperabel (Interoperable)
- Gut beschrieben (well described)
- Leicht nutzbar (Easily consumable)
- Sicherheit und Data Governance (Globally secure through Data Governance)
Im Folgenden gehen wir näher auf die einzelnen Eigenschaften ein.
1. Discoverable: Wie werden Datenprodukte sichtbar?
Datenprodukte sollten schnell und ohne große Hürden auffindbar sein. Das bedeutet, dass an zentraler Stelle eine Beschreibung inklusive Metadaten verfügbar gemacht wird. Diese Informationen beinhalten u. a. die Domäne, die Herkunft und die Aktualität der Daten oder auch den Besitzer des Datenproduktes. Die technische Umsetzung des Ganzen kann beispielsweise durch einen Data Catalog erfolgen. Dieser ist in SAP Datasphere schon länger implementiert und wird nun mit der SAP BDC übergreifend zur Verfügung gestellt.
2. Understandable: Wie wird die Semantik des Datenprodukts dokumentiert?
Ein Datenprodukt soll für alle Benutzergruppen verständlich und greifbar sein. Dazu muss es sowohl semantisch als auch syntaktisch beschrieben werden und eine Beschreibung seiner Beziehungen zu anderen Entitäten aufweisen. Dabei können auch Datenbeispiele genutzt werden, um den Anwenderinnen und Anwendern den Mehrwert des Datenproduktes näherzubringen.
Die Herkunft der Daten und ob weitere Datenprodukte genutzt wurden, ist den Data Lineages zu entnehmen. Die Data Lineage wird in der SAP BDC nicht über ein externes Tool dargestellt, sondern durch die bekannten Funktionen aus der SAP Datasphere. Entity-Relationship-Modelle (ER-Modelle) können hierbei einen zusätzlichen Mehrwert schaffen, um die Beziehungen einzelner Daten besser zu beschreiben.
3. Addressable: Warum ist eine stabile Namenskonvention entscheidend?
Ein Datenprodukt muss außerdem eindeutig adressierbar sein. Das bedeutet, dass es stets unter demselben Pfad bzw. derselben Referenz angesprochen werden kann. Sie müssen also davon ausgehen können, dass ein veröffentlichtes Datenprodukt über seinen gesamten Lebenszyklus hinweg unter demselben Namen erreichbar ist. Hierfür ist eine klare und verständliche Namenskonvention erforderlich, um den maximalen Mehrwert aus dem Business-Namen und dem technischen Namen ziehen zu können. Dieses Thema sollte eine zentrale Komponente Ihrer Data-Governance-Strategie sein.
4. Natively Accessible: Wie funktioniert das Sharing in SAP BDC?
Der einfache und einheitliche Zugriff auf ein Datenprodukt ist elementar. Ziel ist es, dass nicht nur versierte IT-User Datenprodukte nutzen, sondern dass jede Benutzergruppe unabhängig von ihrem technischen Verständnis die Datenprodukte schnell und einfach adaptieren kann.
So muss etwa ein Business User ein bereitgestelltes Datenprodukt mit geringem Aufwand um seine Datenprodukte erweitern können, auch wenn es nicht Teil seiner Domäne ist. Innerhalb der SAP BDC wird dies nahtlos mithilfe des Sharing-Konzepts umgesetzt. Die Datenprodukte können über das SAP BDC Cockpit direkt für weitere Domänen bzw. Spaces bereitgestellt werden. Durch den Object Store und die eingesetzten Zero-Copy- bzw. Delta-Share-Verfahren können die Datenprodukte auch einfach über Servicegrenzen hinweg geteilt werden.
Mit SAP BDC Connect wurde eine weitere Schnittstelle implementiert, die auch das Teilen der Daten mit Services außerhalb der SAP BDC ermöglicht. SAP stellt mit dem Sharing-Konzept in der SAP BDC sowie den Zero-Copy- und Delta-Share-Verfahren genau die Möglichkeit bereit, die benötigt wird, um Datenprodukte innerhalb von SAP Datasphere über Space-Grenzen hinweg zu verteilen. Auch die Daten in den einzelnen Services können über den Object Store mit den anderen Services geteilt werden.
5. Valuable on its own: Wann lohnt sich ein Datenprodukt?
Datenprodukte sollen einen Mehrwert aus sich selbst für das Unternehmen generieren können. Ein Datenprodukt, das keinen Mehrwert bietet, sollte demnach auch nicht im System vorgehalten werden. Die regelmäßige Überwachung dieser Eigenschaft ermöglicht eine Reduzierung der genutzten Ressourcen und eine Minimierung des Wartungsaufwands.
Ein typisches Beispiel hierfür sind historische Daten, die regelmäßig überprüft werden sollten. Aufgrund regulatorischer Anforderungen sind Unternehmen teilweise dazu verpflichtet, bestimmte Daten über einen längeren Zeitraum aufzubewahren. Aus der Analyse und Nutzung dieser aufbewahrten Daten lässt sich dann der konkrete geschäftliche Mehrwert ableiten. Allerdings sollte geprüft werden, ob für ein Reporting wirklich Daten aus den vergangenen Jahren benötigt werden.
6. Integrity: Wie wird Datenqualität dauerhaft gesichert?
Eine hohe Datenintegrität ist ein unbedingtes Muss für ein Datenprodukt. Stellen Sie sich vor, Sie bauen Ihr Datenprodukt auf bereits existierenden Datenprodukten auf. Durch die definierten Anforderungen haben Sie eine bestimmte Erwartung an ein verwendetes Datenprodukt. Stellt sich nun eine Inkonsistenz in einer Ihrer Quellen heraus, wird diese sich mit jeder weiteren Verwendung potenzieren. Dies würde sich dann auch auf Ihr Datenprodukt auswirken – ganz nach dem bekannten Sprichwort »Garbage in, Garbage out«. Deshalb spricht man bei Datenprodukten auch von einem Lebenszyklus, und die Qualität der Datenprodukte sollte regelmäßig (am besten automatisiert) geprüft werden.
Ein unterstützendes Hilfsmittel bei der Weiterentwicklung eines Datenproduktes ist die Versionierung. Ebenso sollten Mindestqualitätsstandards für Datenprodukte definiert und als Teil der Datenstrategie und -Governance zentral festgehalten werden. Mithilfe dieses Rahmenwerks können alle Besitzerinnen und Besitzer von Datenprodukten über Domänen hinweg zusammenarbeiten, ohne bei jeder Zusammenarbeit erneut bestimmte grundlegende Diskussionen führen zu müssen.
7. Interoperable: Wie arbeiten SAP BDC und SAP Databricks zusammen?
Für eine domänenübergreifende Zusammenarbeit ist es zwingend nötig, dass Datenprodukte zusammen integriert werden können, also interoperabel sind. Durch die Nutzung der SAP BDC und ihrer technischen Standards ist sichergestellt, dass sich die Datenprodukte über alle Lines of Business und Services innerhalb der SAP BDC gegenseitig konsumieren können. Auch die Catalogs der SAP BDC und von SAP Databricks sind verknüpft, sodass Sie auf die Informationen aller Services Zugriff haben. Dies stellt sicher, dass Sie jedes Datenprodukt verstehen und mit ihm arbeiten können.
8. Well described: Welche Rolle spielt der Data Catalog?
Die Eigenschaft well described bedeutet, dass die Datenprodukte sehr gut beschrieben und entsprechend mit Semantiken angereichert sind, was auch den Punkt understandable wieder aufgreift. Dazu wird der Data Catalog genutzt, in dem beispielsweise auch der Data Provider, der mit der Besitzerin oder dem Besitzer eines Produktes verglichen werden kann, beschrieben wird. Auch die Data Lineage innerhalb der SAP BDC hilft bei der Beschreibung.
9. Easily Consumable: Was macht Datenprodukte alltagstauglich?
Die Eigenschaft leicht nutzbar ist das Äquivalent der Eigenschaft »einheitlicher Zugriff« und greift auch die Adressierbarkeit auf.
10. Globally secure through Data Governance: Wie werden Berechtigungen geregelt?
Die Kerneigenschaft Sicherheit und Data Governance ist durch das bestehende Sicherheitskonzept gegeben. Allerdings sollten Sie auch hier das Sicherheitskonzept vollständig implementieren und bei jedem Datenprodukt die Berechtigungen berücksichtigen. Datenprodukte sollen die Zusammenarbeit ermöglichen, ohne dass eine direkte persönliche Abstimmung erforderlich ist. Die bisher aufgezählten Eigenschaften, wie etwa Interoperabilität, sind dafür unabdingbar.
Da jedoch alle Nutzerinnen und Nutzer Datenprodukte integrieren können, muss sichergestellt werden, dass nur diejenigen Personen bzw. Benutzergruppen Zugriff auf Datenprodukte und deren Daten haben, die ihn benötigen. Dies muss durch ein zentrales Sicherheitskonzept gewährleistet werden. Die SAP BDC stellt in ihren einzelnen Services passgenaue Berechtigungsimplementierungen bereit, um sicherzustellen, dass Sie nur die Daten sehen, die für Sie bestimmt sind. Dafür werden in SAP Datasphere zum Beispiel Data Access Controls genutzt.
Was bedeuten Datenprodukte für Ihre Datenstrategie?
Mit der Einführung der Datenprodukte in der SAP BDC hat SAP einen weiteren Schritt gemacht, um sich der allgemeinen Analytics-Welt zu öffnen. Die Sprache wird damit über Abteilungen hinweg einheitlich, und die Bedeutungen und Diskussionen setzen kein SAP-spezifisches Wissen mehr voraus. Begriffe wie Infoobjekt oder Composite Provider werden vereinfacht und unter dem Begriff Datenprodukt zusammengefasst. Durch die gemeinsame Sprache wird die Zusammenarbeit von IT und Business-Anwenderinnen und Anwendern sowie von SAP- und Nicht-SAP-Anwenderinnen und -Anwendern erleichtert.
Die Texte auf dieser Seite stammen aus dem Buch »SAP Business Data Cloud. Das umfassende Handbuch« von Marcel Beckmann, Stefan Blinkmann, Manuel Essers, Victoria-Sophie Marx und Jessica Christin Schmidtke. Headergrafik: AdobeStock: 1289068787©Konstantin
Noch mehr Wissen rund um SAP
Lesen Sie auch unseren Artikel zur »SAP BTP: Überblick, Services und Einsatzmöglichkeiten«. Wenn Sie sich intensiver mit Künstlicher Intelligenz im SAP-Umfeld beschäftigen möchten, empfehlen wir den Artikel »So gelingt die KI-Integration in SAP-Systeme«. Oder Sie lernen »9 wichtige Regeln zur SAP-Lizenzierung« kennen.
Ein Buch ist ein guter Anfang. Manchmal braucht es mehr: einen Profi, der Fragen zu einem konkreten Projekt beantwortet. Oder den Austausch mit anderen, die vor denselben Herausforderungen stehen.
Entdecken Sie bei Rheinwerk neben Büchern rund um SAP weitere Lernformate: