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:

      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

---

Скачать книгу