Praxishandbuch SAP Business Warehouse mit BW/4HANA. Jürgen Noe
Transformation (Umwandlung in Fachbereichsdaten) werden die operativen Daten interpretiert, harmonisiert und meist auch auf weniger Details verdichtet. In der Folge könnte das etwa bedeuten, dass nicht mehr der einzelne Buchhaltungsbeleg betrachtet, sondern z.B. ein Kontensaldo ermittelt wird. Auf dieser Ebene sind darüber hinaus zusätzliche Ableitungs- oder Zuordnungsregeln definiert, nach denen die Daten gegliedert werden. Hier kann man hinterlegen, welche Konten einer Tochtergesellschaft welchen Konten des Gesamtkonzerns zugeordnet sind.
Nach der Business Transformation werden die Daten an die Reporting-Ebene weitergeleitet. Dort stehen sie für das Berichtswesen zur Verfügung. Meist werden die Daten auf der obersten Ebene noch weiter verdichtet, um ein leistungsstarkes Berichtswesen zu ermöglichen. Hier lassen sich letztlich die konsolidierte Bilanz des Konzerns sowie, bei Bedarf, die Bilanzen der Tochtergesellschaft abrufen.
Aus dieser Übersicht wird zum einen deutlich, dass die Daten in einem klassischen Data Warehouse oft redundant gespeichert werden, was viel Speicherplatz erfordert. Zum anderen bietet sich durch den Einsatz eines Data Warehouse die Möglichkeit, auf der Basis von vereinheitlichten und hoch aggregierten Daten zu berichten. Dies entlastet die operativen Systeme.
Basierend auf diesen Annahmen sowie mit zunehmendem Praxiseinsatz wuchs die Erkenntnis, dass Data Warehouses eine spezielle Architektur erfordern, um Insellösungen und Datensilos zu vermeiden.
1.2.2 Corporate Information Factory nach Bill Inmon
Im Jahr 1996 war es Bill Inmon vorbehalten, die Idee einer Corporate Information Factory (CIF) zu veröffentlichen. Sie ist in der vereinfachten Abbildung 1.2 dargestellt.
Abbildung 1.2: Corporate Information Factory
Die Kernidee einer CIF ist, dass Daten aus dem gesamten Unternehmen in einem von Bill Inmon skizzierten Enterprise Data Warehouse (EDW) abgelegt werden und dort nachgelagerten Systemen für Auswertungen zur Verfügung stehen. Im ersten Schritt werden die Daten aus verschiedensten Vorsystemen oder Applikationen extrahiert und in einem Staging-Bereich gespeichert. Hier können sie im nächsten Schritt per Extraktion, Transformation und Laden (ETL) homogenisiert und verdichtet werden, damit sich anschließend weitere Zusammenhänge zwischen ihnen ableiten lassen.
Staging
Die Prozessierung der Daten über Extraktion aus den angeschlossenen Quellsystemen bis hin zur Bereitstellung in Data Marts heißt Staging.
Im Anschluss an das ETL werden die Daten meist in verschiedenen Data Marts des Enterprise Data Warehouse gespeichert. Ein Data Mart kann in diesem Kontext einerseits eine persistente anwendungsspezifische Sicht, andererseits eine für einen bestimmten Organisationsbereich erstellte persistente Sicht auf die Daten sein.
Im Zentrum der CIF steht das Enterprise Data Warehouse, das die Daten an nachgelagerte Systeme liefert. Dies können Decision-Support-Systeme oder sogenannte Departmental Data Marts sein, also abteilungs- oder fachspezifische Data Marts. Die Daten im EDW erfüllen folgende Eigenschaften:
granular
integriert
historisch
1.2.3 Die Referenzarchitektur LSA
Parallel zur Entwicklung der ersten Data Warehouses wuchsen, bedingt durch den Aufstieg von SAP R/3 zum Werkzeug für die unternehmensweite Ressourcenplanung, die Anforderungen an das unternehmensinterne Berichtswesen. Mithilfe des herkömmlichen ERP-Systems waren diese Anforderungen nur noch schwer zu erfüllen.
In der ersten Hälfte des Jahres 1997 ging SAP Business Information Warehouse 1.2A für wenige ausgewählte Kunden an den Start. Bill Inmon hatte dazu mit seiner CIF-Idee architektonisch die Vorarbeit geleistet. Die SAP griff seine Idee auf und nutzte sie für die generelle Strukturierung und Modellierung des eigenen Business Warehouse. Architektonisch war das SAP Business Warehouse bis zur Version 7.5 in die Infrastruktur von SAP NetWeaver integriert. Im Laufe der Zeit entwickelte sich SAP Business Warehouse durch den sogenannten Business Content kontinuierlich weiter, mit dem schnell und einfach betriebliche Prozesse verschiedener Branchen abgebildet werden konnten. Mit der zunehmenden Anzahl an Funktionalitäten und neuen Einsatzgebieten stieg jedoch auch die Komplexität und warf bei den Anwendern Fragen bezüglich der Data-Warehouse-Architektur auf. Die klassische Schichtenarchitektur erwies sich in vielen Belangen als zu starr und wenig flexibel bezüglich Anpassungen und Erweiterungen. Den Fachabteilungen dauerte es oft zu lange, bis eine angeforderte Änderung produktiv gehen konnte.
Mit den Jahren und mit zunehmender Erfahrung im dauerhaften Betrieb eines Warehouse setzte sich die Erkenntnis durch, dass ein Business Warehouse eine zukunftsfähige Architektur benötigt, die mit dem Unternehmen mitwachsen kann. 2009 entwarf SAP eine skalierbare Architektur unter dem Namen Layered Scalable Architecture (LSA), also skalierbare Schichtenarchitektur.
Zentraler Ansatzpunkt war, dass man auch zukünftig in der Lage sein wollte, schnell sowie mit nur wenigen Eingriffen in die existierenden Datenmodelle und Applikationen auf geänderte Anforderungen reagieren zu können.
Abbildung 1.3 stellt die Referenzarchitektur der LSA von SAP in der Übersicht dar.
Abbildung 1.3: LSA-Blöcke (eigene Darstellung)
Die einzelnen Blöcke werden nacheinander durchlaufen, und im Zuge dessen werden die einzelnen Bausteine an den Bedürfnissen und Prozessen des Kunden ausgerichtet. Mit dem Kunden werden innerhalb des Blocks »Bausteine« beispielsweise die Granularität der Schichten definiert und Vorgaben für Datenmodelle sowie Entwicklungsrichtlinien festgelegt. Damit entsteht eine kundenindividuelle LSA, die die Prozesse und die Umgebung des Kunden exakt widerspiegelt. Die LSA bietet somit weit mehr als die reine Schichtenarchitektur des bisherigen Data Warehouse, indem sie alle Prozesse beschreibt, die für den Aufbau sowie für den reibungslosen Betrieb eines Business Warehouse erforderlich sind. Für die Gliederung in einzelne Schichten findet sich in der Referenzarchitektur ein Vorschlag (siehe Abbildung 1.4).
Abbildung 1.4: LSA-Schichtenmodell
Man erkennt hier eine Fünf-Schichten-Architektur. Die Eingangsschicht entspricht dem Staging-Bereich in Bill Inmons CIF (vgl. Abschnitt 1.2.2). Die Ebenen Datenqualitäts- und Harmonisierungsschicht, Datenverteilungsschicht sowie Schicht zu Umwandlung in Fachbereichsdaten entsprechen zusammengenommen grob der ETL aus Bill Inmons CIF. Die oberste Schicht, die Berichtsebene mit den Data Marts der Fachabteilungen, entspricht dem Enterprise Data Warehouse. Das Corporate Memory hält die Daten der Eingangsschicht harmonisiert und in Unternehmensbegrifflichkeiten übersetzt zum Wiederaufbau der Applikationen vor, falls die Daten nicht mehr aus dem Quellsystem geladen werden können. Dies kann der Fall sein, wenn die Daten im Quellsystem aus Datenschutz- oder Archivierungsgründen gelöscht werden mussten.
1.3 Grundlegende Architektur von SAP BW/4HANA
Schon seit Mitte der Siebzigerjahre war das Konzept der spaltenbasierten Datenbanken bekannt, in denen die Daten nicht wie bei herkömmlichen relationalen Datenbanken in Zeilen, sondern in Spalten abgelegt sind. Diese Form der Speicherung eignet sich besonders für Data Warehouses und OLAP-Systeme. Erweitert wurde das Konzept durch sogenannte In-Memory-Datenbanken, wie beispielsweise 1997 durch QlikView.
2007 stellte die SAP ihre erste In-Memory-Lösung unter dem Namen SAP Business Warehouse Accelerator vor. Dabei handelte es sich um zusätzliche Hardware, in der die Daten nicht mehr Zeile für Zeile, sondern in Spalten abgelegt wurden. Mit einem an das BW angeschlossenen Business Warehouse Accelerator konnte die