Betrifft einen standardisierten, schichtartigen Aufbau von Anwendungen innerhalb von SAW BW. Erleichtert die Wartung.
Entwicklungsgeschichte
| Name | Version | Release-Datum |
|---|---|---|
| BIW | 1.0E | 1997 |
| BIW | 1.2A | Oktober 1998 |
| BIW | 1.2B | September 1999 |
| BIW | 2.0A | Februar 2000 |
| BIW | 2.0B | Juni 2000 |
| BIW | 2.1C | Novermber 2000 |
| BW | 3.0A | Oktober 2001 |
| BW | 3.0B | Mai 2002 |
| BW | 3.1 | November 2002 |
| BW | 3.1C | Mai 2003 |
| BW | 3.3 | Oktober 2003 |
| BIW | 3.5 | April 2004 |
| BI | 7 | Juli 2005 |
| BW | 7.3 | Juli 2011 |
| BW | 7.4 | Dezember 2013 |
| BW | 7.5 | Oktober 2015 |
| BW/4HANA | 1.0 | |
| BW/4HANA | 2.0 |
Ich fange das jetzt einmal recht persönlich an: Anfang 2018 bin ich in den Vorruhestand gegangen, habe mich quasi zum Sterben zurückgezogen. Mir ging es damals nicht besonders, dazu kam noch externer und überflüssiger Stress. Hat aber nicht ganz geklappt, das mit dem Sterben, Ursache wurde durch Zufall und Scharfsinn meines Hausarztes gefunden. Eine kurze Operation, Problem behoben. Dann kam Corona, mit Quarantäne und mehr oder weniger Stillstand. Ich habe die Zeit genutzt, meine eigenen Problem zu lösen oder auszusitzen. Das ist Historie. Ich bin nun dabei, wieder in das Thema Data Warehousing, genauer gesagt, BW\4HANA wieder einzusteigen. Aufgehört hatte ich mit Version 74 (eigene Erfahrung und 7.5 Schulung), HANA ist also für mich nicht vollkommen fremd. Die Durchsicht der öffentlich zugänglichen Quellen hat eine Weile gedauert und dauert auch noch an, zumal unterschiedliche Versionen auch getrennt betrachtet werden müssen.
Ich selber kenne hin bis Version 7.5 alle Versionen, auch die Urversion 1.2 war soweit ich das in Erinnerung habe. Die ist allerdings nie gelaufen. Startversuch, Anruf beim Entwickler von SAP, warten auf das Patch. Und dann von vorn, täglich grüßt das Murmeltier. Seit den Anfängen von SAP BW hat sich technologisch einiges getan. Nicht nur, dass die Leistungsfähigkeit der Geräte massiv gesteigert worden ist, es hat hier einen technologischen Umbruch gegeben, der die Leistungsfähigkeit des OLAP sprunghaft gesteigert hat. Sorry es sind eigentlich zwei Punkt, die aber eigentlich zusammengehören:
- Einführung des InMemory – Computing auf HANA Systemen
- Spaltenorientierte HANA Datenbank.
InMemory ´- Computing hat den offensichtlichen Vorteil, das keine Datenoperationen auf den (verglichen mit dem Arbeitsspeicher) extrem langsamen Festplatten notwendig sind. Allerdings wird nun auch mehr Arbeitsspeicher benötigt, der letztendlich auch verwaltet werden muss. Die Frage der Persistenz steht auch hoch auf der Problemliste. Gehört hier aber nicht zum Thema. Es geht mir um die Auswirkungen dieses Technologiewechsels, die bei meinem Ausscheiden in Schritten schon in Teilen ersichtlich waren. Sichtbares Kernelement dieses Wandels ist die Änderung in der zugrundeliegenden Basisarchitektur einer Anwendung im BW. Aus meiner Sicht verlief die Dreistufig:
- Klingonisch
- Layered Scalable Architecture
- Layered Scalable Architecture ++
Klingonisch
Die Formulierung ist nicht ganz ernst gemeint, passt aber zu einem Teil der Realität. Architekturvorgaben von SAP mit dem Layered Scalable Architecture (LSA) kamen erst ab 2007. Bis dahin konnte jeder machen, wie er für richtig hielt. Ein Schritt zurück: Natürlich kann man auch heute noch unter Umgehung der LSA etwas implementieren, muss sich dann aber die Frage nach dem Warum gefallen lassen. Da bestehende Anwendungen wegen einer Architekturvorgabe nicht automatisch geändert worden sind, haben diese Anwendungen den Support noch eine Weile beschäftigt.
Neben den fehlenden Vorgaben, war auch die geringe Leistungsfähigkeit der Hardware in Verbindung mit großen Datenmengen etwas, das einen kreativen Umgang mit den Daten zur Folge hatte. Ist mal schön, wenn ein alter Mann in seinen Erinnerungen schwelgt, bringt mich hier aber nicht weiter. Nur so viel, es wurden viele der Transformationen die heute im Bereich EDW Transformationen liegen bereits bei der Extraktion im Quellsystem durchgeführt. Macht unter dem Aspekt der Leistungsfähigkeit der damaligen System durchaus Sinn, schlägt allerdings auf die Wartungsfähigkeit, weil bei der Suche nach Fehlern immer mindestens zwei System betrachtet werden mussten, für die auch entsprechende Berechtigungen notwendig waren.
Layered Scalable Architecture (LSA)
Eingeführt wurde die Layered Scalable Architektur (LSA, zu deutsch: Skalierbare Schichtenarchitektur) um 2007. Es gab zu diesem Zeitpunkt eine ganze Reihe von Modellierungselementen mit zum Teil recht spezifischen Anwendungen. Auf Basis dieser Elemente ist die Schichtenarchitektur entwickelt worden.
Generell besteht LSA aus zwei unterschiedlichen Bereichen:
- der Architected-Data-Mart-Schicht, einer Sicht aus Richtung Reporting, also Anwendung und
- der Enterprise-Data-Warehouse-Schicht, die die Anwendung aus Richtung der eingehenden Daten behandelt.
Die Bearbeitung der Daten erfolgt also zweistufig, zunächst werden die eingehenden Daten bereinigt und aufeinander abgestimmt. Erst im zweiten Schritt werden dann die Daten für das Reporting oder die Weitergabe an Drittsysteme angepasst.
Enterprise-Data-Warehouse-Schicht
Die Enterprise-Data-Warehouse-Schicht besteht aus vier Elementen
- der Data-Acquisition-Schicht
- der Quality & Harmonization-Schicht
- der Data-Propagaiton-Schicht und
- dem Corporate Memory.
Sinn dieser Schicht die aus den Quellen eingehenden Daten um diese zu harmonisieren die Qualität sicherzustellen.
Data-Aquisition-Schicht
Die Data-Aquisition-Schicht ist die erste persistente Schicht der Daten aus den Datenquellen. In den ersten Versionen war hier eine Verbuchung über die PSA technisch Notwendig. Ab Version 3.3 (?) konnte die PSA als Speicher für die Datenpakete verwendet werden, Notwendig war dieses nicht.
Quality & Harmonization-Schicht
Daten können aus einer Vielzahl von Quellen stammen. Diese können durchaus nach unterschiedlichen Kriterien operativ geführt werden und das Customizing kann entsprechend angepasst sein. Als Beispiel fällt mir hierzu unterschiedliche Gesetzgebungen in verschiedenen Staaten ein.
Data-Propagation-Schicht
Die Data-Propagation-Schicht stellt die bereinigten und aufeinander abgestimmten Daten für die Weitergabe an das Reporting bereit.
Corporate Memory
Das Corporate Memory ist ein spezieller Speicherbereich, in dem die aus den Quellen eingehenden Daten unabhängig von einer Verarbeitung gespeichert werden können. Das Corporate Memory ermöglicht dadurch eine Datenhistorie, aus der der Datenbestand im Reporting unabhängig von der Quelle wieder hergestellt werden kann.
Architected-Data-Mart-Schicht
mit den Schichten
- Business-Transformation-Schicht
- Reporting-Schicht
- Visualization-Schicht
- Operational Data Store
Sinn dieser Schicht ist es, Daten für das Reporting aufzubereiten. Für das Reporting kann es durchaus notwendig sein, Daten aus mehren Quellen, z. B. Stammdaten, anzureichern.
Business-Transformation-Schicht
In der Business-Transformation-Sicht werden die Daten entsprechend der Geschäftslogik transformiert. Die bereinigten und harmonisierten Daten werden aus der Data-Propagation-Schicht in die Reporting-Schicht überführt. Ob hier noch Änderungen an den Daten notwendig sind, entscheidet der Anwendungsfall. Hier können noch ergänzende Daten benötigt.
Reporting-Schicht
In der Reporting-Schicht werden die Daten für das Reporting bereitgehalten. Üblicherweise geschah dieses in Systemen bis 7.5 mit InfoCubes.
Visualization-Schicht
In der Business-Transformation-Sicht werden die Daten entsprechend der Geschäftslogik transformiert. Die bereinigten und harmonisierten Daten werden aus der Data-Propagation-Schicht in die Reporting-Schicht überführt. Ob hier noch Änderungen an den Daten notwendig sind, entscheidet der Anwendungsfall. Hier können noch ergänzende Daten benötigt.
Operational Data Store
Layered Scalable Architecture (LSA++)
BW virtuelle Data-Mart-Schicht
Reaktion auf vereinfachte Architektur eines SAP BW – Systems auf Basis HANA. Modellierungselemente der Versionen bis 7.5 sind durch universellere Elemente ersetzt worden. Vom Prinzip her ist die LSA vollständig in der LSA++ enthalten. Ohne Gewähr auf Vollständigkeit:
- DateStore-Objekt (advanced) ersetzt den alten DSO, InfoCube, Hybridprovider, PSA
- DatenTransferProzess und Transformation ersetzt InfoPackages und Fortschreibungsregeln.
Data-Acquisition-Schicht
Die Funktion der Data-Acquisition-Schicht ist wie in der LSA. Die Daten werden aus der Quelle übernommen und in darauf spezialisierte DSOa gespeichert.
EDW Transformations
Funkton wie Quality & Harmonization-Schicht in der LSA. Anpassungen und die Harmonisierung der Daten wird hier mittels Transformation durchgeführt.
EDW Propagation Schicht
Funktion wie Data-Propagation-Schicht in der LSA.
Was ich jetzt aus meiner arg theoretischen Sicht nicht unbedingt sagen kann, ist ob hier Persistenz mittelst DSOa notwendig ist oder ob eine InfoSource ausreicht. Ein Reporting ist in diesem Fall nicht möglich.
Business Transformations
Funktion entspricht der Business-Transformation-Schicht in der LSA
Architected Data Marts
Entspricht der Reporting und Visualization-Schicht aus dem LSA.
Wird realisiert durch DSOa und Multiprovider.
Flexible Data Marts / BW Workspace
BW Workspace ist eine spezielle Funkton eines SAP Warehouses um Daten lokal zu laden und zusammen mit den übrigen Daten auszuwerten.