SAP BW/4HANA Architekturtypen

Mit SAP BW/4HANA propagiert SAP auch verschiedene Architekturtypen, welche neue Möglichkeiten mit BW/4HANA im Vergleich zum klassischen SAP BW aufzeigen sollen. Weitgehend sind die Architekturtypen bereits für SAP BW on HANA realisierbar.

Vielleicht ist dies ein schlechter Zeitpunkt, über BW/4HANA 1.0-Architektur zu schreiben, wo sich doch BW/4HANA 2.0 aktuell ankündigt. Zum 25.02.2019 ist das neue Release angekündigt!

Nun gut, ein neues Produkt oder Major-Release von SAP ist natürlich immer das beste, tollste, schönste, schnellste, einfachste, …. wie von jedem anderen halt auch. Bisher etablierte Prinzipien verlieren selten ihre Gültigkeit.

Hier ein Überblick mit Kurzbeschreibung:

sEDW – Simplified EDW (Vereinfachtes Enterprise Data Warehouse)

Das vereinfachte EDW orientiert sich als Architekturtyp an der LSA++. Die Prinzipien und die technische Umsetzung werden bereits in der SAP Hilfe recht ausführlich beschrieben.

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Referenziert auf die LSA++
  • Geringe Agilität
  • Hoher konzeptioneller Aufwand (Big Design Upfront)
  • Projektmodus: Wasserfallmodell
  • Umsetzung vollständig durch die IT
  • Typischer Konvertierungspfad von BW on Any DB ist In-Place oder Remote-Konvertierung
  • Modellierungsart ist Top-Down

Im BW/4HANA zeichnet sich das sEDW durch optionales Staging aus. Durch Operational Data Provisioning (ODP) wird die PSA quasi ins Quellsystem verschoben. InfoCubes sind nicht mehr existent. Star Schemas werden virtuell durch CompositeProvider realisiert (Dynamic Star Schema).

InfoObjects werden nach wie vor und typischerweise auch noch aus der Historie heraus eingesetzt.

 

fEDW – Flexible EDW (Flexibles Enterprise Data Warehouse)

Das fEDW ergänzt das sEDW um neue Möglichkeiten:

  • OpenODS-Layer/Raw DWH (feldbasiert)
  • Replication Layer (SLT/SDI)
  • Remote Integration (SDA)
  • Transformations (HANA Calculation Views)

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Referenziert auf die LSA++
  • Mittlere Agilität
  • Hoher konzeptioneller Aufwand (Big Design Upfront)
  • Projektmodus: Wasserfallmodell
  • Umsetzung vollständig durch die IT
  • Typischer Konvertierungspfad von BW on Any DB ist Remote- oder Shell-Konvertierung
  • Modellierungsart ist Top-Down und Bottom-Up möglich

Somit ist durch die Hinzunahme neuer Technischer Möglichkeiten eine höhere Agilität im bisherigen Data Warehouse möglich. Von einem klassischen SAP BW kommend, kann dies als nächster Evolutionsschritt gesehen werden, um Mehrwerte aus der Konvertierung zu generieren.

 

EDP – Enterprise Data Platform

Der Ansatz EDP wird auch als Data Warehouse on demand beschrieben und stellt den versuch dar, mit SAP-Mitteln eine Datenplattform für maximale Agilität aufzubauen. Dabei liegt der Schwerpunkt in der HANA Plattform.

Virtuelle Integration (Logical Data Warehouse) oder Real-time Replikation ist die bevorzugte Art, Daten bereitzustellen. Die Daten kommen im optimalen Fall aus einem Data Lake der in Kundenszenarien auch schon mal als Corporate Memory 2.0 benannt wird.

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Datenhaltung nach Bedarf
  • Sehr hohe Agilität
  • Nur der nötigste konzeptionelle Aufwand (Sufficient Design Upfront)
  • Projektmodus: evolutionär, inkrementell
  • Umsetzung business-getrieben
  • Typischerweise wird hier Greenfield gestartet, um sich frei zu machen, von evtl. vorhandenen Strukturen und Einschränkungen
  • Modellierungsart ist Bottom-Up (Self-Service, feldbasiert, schnelle Ergebnisse)

Dieser Ansatz steht genau im Gegensatz zu klassischen Enterprise Data Warehouse-Implementierungen. Der schnelle, kurzfristige Nutzen steht im Vordergrund, in der Hoffnung, mit einem agilen, leicht anpassbaren System mit der Zeit und wachsendem Reifegrad auch die notwendige Integration und Harmonisierung leisten zu können.

 

aDWH – Agile Data Warehouse (Agiles Data Warehouse)

Dem aDWH kann man sich von zwei Seiten nähern. Aus Sicht einer EDP kann es ein Stabilisierungsschritt sein, indem zur Historisierung, Versionierung und Qualitätssicherung eine persistente Schicht (OpenODS-Layer/Raw DWH) im BW/4HANA eingeführt wird.

Auch der Weg vom klassischen SAP BW schließt die Evolution in diese Richtung nicht aus.

Dieser Architekturyp zeichnet sich durch folgende Eigenschaften aus:

  • Referenziert noch auf die LSA++
  • Hohe Agilität
  • Nur der nötigste konzeptionelle Aufwand (Sufficient Design Upfront)
  • Projektmodus: evolutionär, inkrementell
  • Umsetzung business-getrieben
  • Vom klassischen SAP BW kommend empfiehlt sich die Shell-Konvertierung, um die notwendigen Vereinfachungen vor dem Datenaufbau vornehmen zu können. Greenfield kann hier jedoch ebenso die Option sein.
  • Modellierungsart ist Bottom-Up (Self-Service, feldbasiert, schnelle Ergebnisse)

 

Im Prinzip sind damit, je nach Ausgangsbasis verschiedene evolutionäre Entwicklungen beschrieben. Eine klare Abgrenzung der Architekturtypen ist eher schwierig und wird sich auch in Zukunft am Bedarf und sich verändernder Anforderungen orientieren.

Da SAP Data Hub, zunehmende cloudbasierte Datenquellen, sowie die eigene Bereitstellung als Cloud-Anwendung (Blueberry) sicherlich noch weiter starken Einfluss auf die aktuelle Entwicklung des BW/4HANA haben werden, dürfen wir uns auf weitere Möglichkeiten in der Zukunft freuen.