SAP BW/4HANASAP BW/4HANA ist die aktuelle Data Warehouse Lösung basierend auf… ist seit 2016 auf dem Markt. SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… BW/4HANA bringt viele Veränderungen und Vorteile in den Bereichen Architektur, Agilität, Performance und Modellierung.
Sollen die Potentiale von SAP BW/4HANA ausgeschöpft werden, ist es wichtig eine moderne und flexible Architektur implementiert zu haben. Die Einführung von SAP BW/4HANA sollte sich nach unserer Einschätzung daher nicht auf die technische Migration bestehender historisch gewachsener SAP BW Systeme beschränken. Mit unserem Beitrag möchten wir unsere Idee einer modernen und flexiblen SAP-BW/4HANA-Architektur skizzieren.
Probleme mit SAP BW – Kennen Sie das?
Durch unsere langjährige Erfahrung mit SAP-BW-Systemen wissen wir, dass vor allem nach langjährigem Betrieb eines BW häufig Schwierigkeiten auftreten können. Vielleicht kommt Ihnen eines dieser Probleme bekannt vor:
- Lange Antwortzeiten für Berichte
- Zunehmende Ladezeiten führen zu Wartezeiten
- Redundante Datenhaltung
- Unflexible Datenmodellierung
- Lange Entwicklungszeiten
- Steigender Wartungsaufwand und Kosten
- Fehlende Akzeptanz
- “Schatten-IT”-Lösungen neben dem SAP BW
Beschleunigt wird dieser Trend dadurch, dass sich die Anforderungen an ein modernes Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… verändert bzw. erheblich erweitert haben. Während es früher vorwiegend die Errichtung eines Single-Point-of-Truth bei hoher Qualität und Stabilität war, rücken nun die Integration neuer Daten (IoT / Social / Geo …), Erwartung kürzerer Release-Zyklen sowie Agilität und Flexibilität in den Fokus. Operativen Systeme, wie S/4 HANA bringen zudem zunehmend integrierte analytische Fähigkeiten mit.
SAP BW Datenmodelle sind in der Vergangenheit häufig nach der sog. Layered-Scalable-Architecture (LSA) aufgebaut worden. Im Kern setzt LSA auf eine redundante layerbasierte Modellierung. Die Idee dahinter ist, dass durch die schichtenweise Aufbereitung von Daten Ihr analytischer Wert steigt. Reporting ist daher nur auf der obersten Schicht erlaubt. Dadurch bietet diese LSA-Architektur eine sehr hohe Stabilität, welche jedoch ebenfalls der größte Nachteil dieses Ansatzes ist. Durch die hohe Stabilität entsteht so auch gleichzeitig eine hohe Inflexibilität, welche Anpassungen schnell sehr aufwendig gestaltet. Agile und iterative Entwicklungen sind kaum zu bewältigen. Zudem wird vernachlässigt, dass in vielen Fällen quellsystemorientierte Daten einen analytischen Wert haben können. SAP S/4 HANA etwa bietet einem Datawarehouse bereits fertige analytische Modelle an. Das Dogma einer verpflichtenden redundante Datenhaltung in Schichten macht hier einfach keinen Sinn.
Aus diesem Grund sind wir überzeugt, dass die technische Migration von LSA-Datenmodellen nicht dafür sorgen wird, dass nachhaltig die zuvor genannten Probleme überwunden werden können.
Neue Grundsätze für die SAP-BW-Architektur
Für das Design von SAP BW Systemen sind neue Design-Grundsätze notwendig, die Basis für einen neuen Architektur-Entwurf sind. Alle Überlegungen zur Architektur müssen sich messen lassen an diesen Designprinzipien. Für die Architektur eines SAP BW/4HANA Data Warehouse haben wir vier zentrale Prinzipien aufgestellt, die wir im Folgenden gerne erläutern möchten.
Einfach
Die Data-Warehouse-Architektur soll möglichst schlank und einfach gestaltet werden. Treiber des Data Warehouse Service Levels sind die Business Anforderungen, keine dogmatischen Designvorgaben. Dies bedeutet:
- Reduktion der verpflichtenden Schichten auf zwei für die Datenakquisition und Bereitstellung.
- InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,… werden nur verwendet, wenn es notwendig oder sinnvoll ist – grundsätzlich wird feldbasiert modelliert
Agil
Die Architektur soll agile Methoden durch technische Mittel und ein “evolutionär gutes Data-Warehouse-Design” unterstützen.
Business Logiken und Joins sollen möglichst nicht in großen Objekten konsolidiert persistiert werden. Die Modellierung soll dagegen via einfach erweiterbare modulare Satelliten durchgeführt werden. Logiken sollen entweder virtuell durchgeführt werden oder ebenfalls möglichst gekapselt in Data Marts abgelegt werden. Doppelte Datenhaltung ist zu vermeiden. Es gilt der Grundsatz „Virtualization as much as possible, persistence only where really needed”
Offen
Das SAP BW muss ich integrieren in analytische Plattform von Unternehmen. Die Architektur muss damit offen sein im Hinblick auf:
- Integration mit Big Data und Advanced Analytics
- Bereitstellung von Daten an Non SAP BI Tools
- Bereitstellung von Daten an andere Applikationen
- SAP HANA Mixed Architekturen
Flexibel
Die Zeit der LSA-Architekturen bei der es generische allgemeingültige Vorgaben für die Entwicklung gegeben hat sind vorbei. Ein enges Regelwerk mit dogmatischen Vorgaben wird nicht mehr funktionieren. Das Konzept von SAP für LSA++ bietet einen flexibleren bedarfsgerechten Weg. Gefragt ist eine flexible modulare “Blaupause”, welche flexibel an Bedürfnisse von Unternehmen anpassbar ist.
ISR Referenzarchitektur – orientiert an LSA+++
Aus diesem Grund haben wir als ISR für unsere Kundenprojekte einen sog. Modellierungsleitfaden entwickelt, der sich an den o.g. Prinzipien orientiert.
Unser ISR-Architekturmodell beschreibt nicht den einen Weg, der immer einzuhalten ist, sondern einen Baukasten, welcher flexibel auf die Bedürfnisse von Kunden angepasst werden kann, in dem empfohlene Modellierungsvarianten und Szenarien beschrieben werden. Enthalten sind zudem wiederverwendbare “Bausteine” für spezifische Problemlösungen (Historisierung, Stammdaten-Modellierung, …) als “Good Practice” – abgeleitet aus der Praxiserfahrung. Wir orientieren unseren Architekturentwurf dabei sehr stark an dem von SAP empfohlenen LSA++ Architekturansatz. Im Folgenden erläutern wir die grundsätzlichen Ideen und das Design unseres Architekturentwurfs.
Jede Kundensituation ist anders – daher lässt unsere Blaupause sehr viele Wege der Modellierung offen, enthält im Detail aber Empfehlungen aus der Praxis. So erlaubt der Architekturentwurf ein weitgehend virtualisiertes Data Warehouse genauso wie klassischere Ansätze.
Die erste verpflichtende Schicht in der Architektur ist der Acquisition Layer. Daten werden (im Regelfall) nicht gespeichert. Der Layer ist eine reine Integrationsschicht und gliedert sich in drei Bereiche (getrennt nach Art der Datenintegration). Eine Datenhaltung findet auf diesem Layer nicht statt. Im Wesentlichen enthält der Bereich nur die Data Sources und Quellsystemanbindung.
In der RAW Area werden die Rohdaten aus den Quellsystemen quellsystemorientiert gespeichert. Eine Integration über mehrere Quellsysteme findet nicht statt. Genauso wird auch keine Business Logik oder Harmonisierung der Daten durchgeführt. Jedoch kann es notwendig sein, technische Anpassungen (Datentypen, Ergänzung Load Timestamps o.ä.) durchzuführen. InfoObjects werden nur verwendet, wenn dies sinnvoll ist (Business Content, Performance, usw.), d.h. es wird grundsätzlich feldbasiert modelliert.
Business Logiken werden in dem Bereich “Business Integrated” implementiert. Es finden die eigentliche “Integrationsarbeit” statt. Persistenzen in diesem Bereich dabei möglichst vermieden werden. Es gilt der Grundsatz Virtualization first. Verarbeitungslogiken können sowohl mit Hilfe von SAP BW Transformationen als auch HANA Calculation Views umgesetzt werden. In der Praxis werden abhängig von der Datenmenge natürlich nicht sämtliche Logiken virtuell ablaufen können. Logiken können in Data Marts persistiert werden.
Data
Marts
werden verwendet, um fallspezifisch Persistenzen zu bilden. Dies kann etwa
aufgrund von Performanceaspekten erfolgen oder wenn ein Use Case dies
erfordert. Ein weit verbreitetes Beispiel sind Historien aber auch aDSO für die
Planung.
Für die Modellierung von übergreifenden, wiederverwendbaren Stammdaten haben wir uns aufgrund Ihres übergreifenden Charakters für den eigenen Bereich Master Data Area entschieden. Je nach Anwendungsfall werden fachlich definierte Business Objekte durch InfoObjects, sog. logische “Link-InfoObjects” oder openODS Views bzw. Calculation Views gebildet. Für die Modellierung von Stammdaten, Ablage und Integration mit Bewegungsdaten gibt es mehrere Entwurfsmuster (persistent <> virtuell, agil <> stabil), welche wir anhand der Kriterien Performance, Offenheit, Flexibilität, Einfachheit und Aufwand bewertet haben. Insofern gibt es nicht die eine richtige Modellierung. Fallweise muss geprüft werden welches Szenario sinnvoll ist.
Schließlich werden die Daten im Rahmen des Virtual Layer an BI-Tools und Dritt-Applikationen (OutHub) bereitgestellt. Der Layer enthält nur virtuelle Objekte, wie z.B. Composite Provider im SAP BW oder Calculation Views in SAP HANA.
Was ist die richtige Antwort für Sie?
Klassische Antwort des Beraters: “Es kommt drauf an”
Auf hoher Abstraktionsebene wird die grundsätzliche SAP BW Architektur – sofern orientiert an LSA++ – ähnlich dem ISR Muster aussehen. Entscheidend ist die konkrete Ausgestaltung der Architektur in einem auf die jeweilige Situation zugeschnittenen Solution Design. Diese Designvorgaben definieren Modellierungsvorgaben, zeigen Entwurfsmuster für die eigenen Use Cases auf, definieren eine Verteilung zwischen SAP BW und HANA SQL etc.
Mit SAP BW/4 HANA sind viele Formen der Datenmodellierung denkbar (siehe Abbildung unten). Unser Kunde, die BwFuhrparkService hat sich bspw. für eine sehr stark virtualisierte BW/4 HANA Architektur entschieden. Die Ausgangssituation bei der BwFuhrpark war ähnlich wie eingangs beschrieben. In diesem Fall konnten durch einen konsequent neuen Architekturansatz viele Vorteile gewonnen werden (z.B. deutliche Reduktion der Entwicklungskosten). Mehr Details zu dem Projekt finden Sie hier. Für einen unserer langjährigen Kunde im Bereich Energy war dagegen der Weg sich nah am optimierten BI Content zu orientieren, der Schlüssel zum Erfolg. Hier geht es zur Kundenreferenz.
Die Beispiele zeigen auch, dass es keine allgemeingültige pauschale Definition der Architektur geben kann, die für jede Kundensituation passt. Die Wahrheit wird irgendwo zwischen den dargestellten Architekturvarianten sein und muss für die jeweilige Situation die richtige sein. Die skizzierten Varianten sind lediglich Denkanstöße und nicht wertend gemeint.
Wie finden Sie die passende Architektur?
Mit unserem Beitrag deutlich geworden ist, dass es keine pauschalen Empfehlungen geben kann. Daher können wir nur den Weg (siehe auch Road-2-BW/4HANA) skizzieren, wie die Ziel-Architektur ermittelt werden kann. In der Regel gehen wir für die Definition von Ziel-Architekturen in drei Schritten vor:
Workshop SAP BW/4HANA
In dem Workshop gehen wir auf die Grundlagen zu BW/4HANA, Moderne und Flexible Architekturen, Agiles Data Warehousing sowie Migrationsoptionen ein.
Zentral ist eine auf dieser Basis geführte Diskussion mit Ihnen zu Ihrer Situation und Ihren Anforderungen. I.d.R. entsteht im Laufe des Workshops bereits ein erste Architektur-Idee.Quick Check Ihrer bestehenden Architektur
Positionsbestimmung Ihrer vorhandenen BI-Architektur mit dem Ziel ein gutes Verständnis aufzubauen zu Ihrer aktuellen Situation und Ihren Visionen für BI und Analytics.- Architektur-Empfehlung
Auf Grundlage der gewonnenen Erkenntnisse konkretisieren wir gemeinsam mit Ihnen Ihre Architektur und erstellen ein Solution Design.
Ob und wie intensiv alle Schritte auch für Sie notwendig sind, bestimmen wir gerne in einem kostenlosen Vorgespräch.
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
