Agile Vorgehensweisen und Organisationen sind seit geraumer Zeit sehr präsent in den Medien und werden bei der Softwareentwicklung schon länger eingesetzt.
Das Ergebnis agiler Softwareentwicklung begegnet uns täglich bei der Nutzung von Amazon, Spotify aber auch SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Cloud-Lösungen wie der SAP Analytics CloudDer Begriff Cloud stammt aus dem Englischen, zu deutsch “Wolke”….. Die kurze Dauer bis neue Features verfügbar sind prägen die Erwartung von Anwendern auch an andere Softwarelösungen.
Inhaltsverzeichnis
1. Nachteile der klassischen Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Entwicklung
2. Agile Grundsätze und Prinzipien
3. Erfolgsfaktoren eines agilen Data Warehouse
4. Agiles Design eines SAP BW/4HANASAP BW/4HANA ist die aktuelle Data Warehouse Lösung basierend auf… basierte DWH
5. Fazit
Weniger stark verbreitet sind agile MethodenWas sind agile Methoden?Agile Methoden kommen aus dem Bereich der… der Softwareentwicklung bei der Entwicklung von SAP Data-Warehouse-Lösungen. Es wird argumentiert, dass es im Data Management Bereich nicht möglich sei, kleine nutzbare Produktinkrements zu entwickeln, und agile Entwicklungsmethoden daher grundsätzlich nicht in Frage kommen.
In diesem Beitrag möchten wir darlegen, warum Methoden der agilen Softwareentwicklung auch im Data Warehouse sinnvoll und möglich sind. Hierbei konzentrieren wir uns auf das SAP BW/4HANA und stellen heraus welche Eigenschaften wichtig sind für ein agiles Design des Data Warehouse. In weiteren Blogreihen werden wir den Fokus insb. auch auf den SAP HANA SQL Data Warehouse Ansatz setzen.
Nachteile der klassischen Data-Warehouse-Entwicklung
Viele Data-Warehouse-Lösungen werden nach Methoden entwickelt, die sich im Kern an klassischen Wasserfallvorgehen orientieren – wenn auch teilweise aufgelockert durch iterative Ansätze.
Grafik 01: “Nachteiler” klassischer SAP-BW-Entwicklung
Die Welt, in der BI-Systeme in einem Business Blueprint exakt vorab beschrieben worden sind, um diese dann über mehrere Monate zu entwickeln, ist vorbei. Im Zweifel hat sich die Anforderung seit Erstellung des Blueprints schon wieder verändert und die Anwender erhalten ein Feature, welches nicht benötigt wird – dann gilt der Satz “Works as designed”. Dies hilft aber weder der IT noch den Fachbereichen weiter. Mag es in sehr reglementierten Märkten wie bei Banken erforderlich sein durch umfangreiche Konzepte die Einhaltung von Regularien nachzuweisen, dürfte dies für viele Firmen nicht notwendig sein. Die Gefahr ist, dass Lösungen nicht bedarfsgerecht sind und daher nicht genutzt werden. Ein qualifiziertes Feedback und Nutzungserlebnis gibt es frühestens nach dem Testen bzw. nach der produktiven Nutzung. Häufig wird es erst dadurch möglich die Anforderung zu formulieren. Klassische Methoden sind hier am Ende.
In der Vergangenheit sind Wasserfallansätze zudem begünstigt worden durch eine Technologie, bei der nachträgliche Änderungen schwer umsetzbar waren. Insbesondere im SAP BW Umfeld war es in der Vergangenheit immer ein Problem, wenn größere Datenmodelländerungen durchgeführt werden sollten. Oberstes Ziel war es, eine hohe Stabilität und Qualität sicherzustellen. Die strukturierten Daten aus den operativen ERP-Systemen wurden schichtenweise aufbereitet und redundant gespeichert als Grundlage für die Konsumierung durch BI Frontend-Werkzeuge. Ein in der SAP BW Welt weit verbreiteter Architekturansatz für die systemische Abbildung ist das Schichtenmodell LSA (layered scalable architecture).
Durch die schichtenweise Aufbereitung von Daten im Rahmen des LSA Konzepts kann eine hohe Stabilität und Qualität sichergestellt werden. Auf der anderen Seite entstehen jedoch durch Persistierung der Daten in mehreren Schichten zahlreiche Redundanzen. Dies, und der (in alten SAP-BW-Systemen verbreitete) sehr wissenschaftliche Ansatz einer vollständigen Top-Down-Modellierung, führen zu einer monolitischen Architektur. Anpassungswünsche führen schnell zu hohen Entwicklungsaufwänden. Das System ist damit weder flexibel gegenüber Datenmodellanpassungen, noch unterstützt es inkrementelle Weiterentwicklungen. Auch war das BW – vor HANA – nicht gerade bekannt dafür, sehr feingranulare Massendaten effizient zu verarbeiten. In Konsequenz musste Anforderungsgetrieben genau geplant werden, welche Detailtiefe an Daten erforderlich ist, und welche Aggregationen entlang des Datenflusses erfolgen müssen. In Konsequenz heißt dies, dass bei klassischen SAP BW Ansätzen eine Entwicklung ohne vorherige umfangreiche Planung des Datenmodells und Vorarbeiten (z.B. Massenhafte Erstellung von InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,…) nicht möglich ist.
Es sind Systeme gewachsen, welche eine hohe Qualität und Stabilität besitzen. Gleichzeitig haben die Systeme jedoch Probleme flexibel und schnell auf geänderte Anforderungen zu reagieren. Nach unserer Erfahrung entstehen für SAP-BW-Systeme nach langjährigem Betrieb Schwierigkeiten. Die unflexible Datenmodellierung führt zu langen Entwicklungszeiten sowie steigendem Wartungsaufwand und Kosten. Dies sorgt schnell für fehlende Akzeptanz bei Anwendern und begünstigt lokale Fachbereichslösungen als Ausweg aus der Unflexibilität.
Agile Grundsätze und Prinzipien
In der Softwareentwicklung sehr bekannt ist das “Manifest für agile Softwareentwicklung”, welches zu dem Siegeszug von agilen Methoden beigetragen hat. Ausgangspunkt der weiteren Überlegungen unseres Beitrags soll die Vergegenwärtigung der Werte und Prinzipien des agilen Manifests sein, welche wir leicht angepasst haben, um einen Bezug zu Data Warehousing und BI herzustellen.
Zentral ist, dass der Nutzen für Anwender im Fokus steht. Durch iterative, inkrementelle Entwicklungsprozesse sollen die Qualität und der Nutzen für Anwender erhöht werden. Den “Kunden” des Data Warehouse sollen schnell nutzbare Features / Produktinkrements bereitgestellt werden. Zum einen sollen Anwender möglichst frühzeitig einen Nutzen haben, zum anderen soll das Feedback frühzeitig in die Weiterentwicklung der nächsten Iteration einfließen.
In der agilen Softwareentwicklung weit verbreitet ist die Methode DevOpsWas ist DevOps? Der Begriff DevOps setzt sich aus den…. In diesem Zusammenhang wird häufig plakativ von der Fähigkeit gesprochen 10 Releases pro Tag durchzuführen. Natürlich möchte niemand im DWH-Kontext 10 Releases pro Tag durchführen. Der Aufwand eines Releases – von der Planung bis zum Deployment – soll aber minimiert werden. Eine bekannte Analogie ist die Spülmaschine, welche nur noch 3 Minuten für einen Waschgang benötigt – trotzdem wird man keine 100 Spülgänge durchführen. Die Planung und der Aufwand für einen Spülvorgang werden verringert. Früheres Feedback von Anwendern ist möglich, kann schneller in der nächsten Iteration berücksichtigt & wiederum bereitgestellt werden. Es ergibt sich ein Kreislauf. Fehlentwicklungen lassen sich besser vermeiden. Der Nutzen der Anwender steigt, weil sich IT-Lösungen näher an dem Bedarf orientieren.
Grafik 02: Agile Data Warehousing
Grafik 03: Agile Prinzipien der Data Warehouse Entwicklung
Spätestens jetzt wird deutlich, dass wir über mehr reden als eine Modernisierung von IT-Systemen. Agilität ergibt sich aus der erfolgreichen Synthese von agilem Mindset, Prozessen & Methoden sowie passenden technischen Lösungen.
Der Fokus dieses Beitrags liegt weniger in den kulturellen oder organisatorischen Aspekten. Wir möchten Aspekte hervorheben, die für ein “agiles Design” von SAP BW Systemen wichtig sind.
Erfolgsfaktoren eines agilen Data Warehouse
Aus den genannten Werten und Prinzipien folgt recht schnell, dass Data-Warehouse-Systeme nicht (mehr) in großen Releases geplant und verändert werden sollten. Stattdessen verändert sich das Data Warehouse inkrementell, d.h. evolutionär. Das Feedback von Anwendern wird schneller erlangt und kann im nächsten Inkrement berücksichtigt werden. Damit werden Grundgedanken des agilen Manifests berücksichtigt. Das Data Warehouse kann näher am Nutzer orientiert entwickelt werden.
Damit ein Data Warehouse diese Art der Entwicklung ermöglicht, muss das Design des Data Warehouse bestimmte Voraussetzungen erfüllen. Für die Umsetzung eines solchen “agilen Data Warehouse” mit SAP BW sehen wir drei Erfolgsfaktoren.
Anforderungsgerechte Entwicklung
In der Vergangenheit wurden SAP-BW-Lösungen häufig breiter entwickelt als es für eine vorliegende Anforderung notwendig gewesen ist. Auch wenn ein Anwender nur drei Felder aus einer Quelle benötigt, wurden auch die übrigen 97 Felder in das SAP BW integriert. Dies folgt dem Motto “Was man hat, das hat man”. Data-Warehouse-Lösungen sollten möglichst so entwickelt werden, dass viele noch unbekannte Fragestellungen beantwortbar sind. Nachträgliche Datenmodelländerungen in klassischen SAP-BW-Systemen waren lange nur unter hohem Aufwand durchführbar. Daher wurde der Aufwand lieber gleich investiert. Der Nachteil dieser Vorgehensweise ist, dass Anwender so unnötig lange warten und das Feedback zu einer Entwicklung ebenfalls lange dauern wird. Der ganze Prozess einer Entwicklung wird verlangsamt. In der Praxis ist es zudem selten vorgekommen, dass die 97 Extrafelder auch wirklich benötigt worden sind.
Stattdessen sollte die Entwicklung des Data Warehouse anforderungsgerecht durchgeführt werden, d.h. dass sich die Planung und Umsetzung an der eigentlichen Anforderung orientiert und nicht unnötig aufgebläht wird. Anwender sollen möglichst schnell nutzbare Features erhalten. Alle darüber hinaus gehenden Entwicklungen werden nur durchgeführt, wenn keine zeitlichen Verzögerungen zu erwarten sind. Verschwendungen von Zeit und Geld sind zu vermeiden.
Einfaches Refactoring
Der Verzicht auf eine wochenlange Planung nimmt bewusst in Kauf, dass sich bestehende Datenmodelle im Zeitverlauf verändern werden. Damit dies zu keinen größeren Problemen im Betrieb des Data Warehouse führt, muss das technische Design des Data Warehouse ein einfaches Refactoring ermöglichen. Ansonsten wird eine anforderungsgerechte DWH Entwicklung behindert.
Die richtige Architektur
Die Architektur & Governance-Vorgaben müssen einen Spagat machen. Es muss zentrale Richtlinien für die Entwicklung geben damit Qualitätsstandards eingehalten werden und nicht jeder Entwickler nach seinen persönlichen Vorlieben das Data Warehouse entwickelt (z.B. Namenskonventionen, Layer-Architektur, etc.). Ansonsten ist das System nicht dauerhaft betriebsfähig. Gleichzeitig muss die Architektur genug Freiräume einräumen, damit das Data Warehouse bedarfsgerecht entwickelt werden kann und nicht dogmatisch. Ein aus heutiger Sicht negatives Beispiel wäre eine verpflichtende schichtenweise Aufbereitung wie bei dem LSA-Architektur-Ansatz, welcher in klassischen non-HANA SAP-BW-Systemen weit verbreitet ist.
Agiles Design eines SAP-BW/4HANA-basierten Data Warehouse
Wie kann das SAP BW/4HANA die Erfolgsfaktoren erfüllen? Worauf kommt es an? Wir sehen vier Dinge, die bei dem Design eines SAP-BW/4HANA-basierten Data Warehouse wichtig sind und die Grundlage für eine agile Entwicklung bilden.
Architektur
Von zentraler Bedeutung ist die Wahl der Architektur. SAP empfiehlt für SAP BW on HANA- bzw. BW/4HANA-Systeme eine Architektur die sich an der LSA++ orientiert. Dieser neue Schichten-Ansatz zeichnet sich besonders durch den Fokus auf virtuelle Objekte aus. VirtualisierungMit Virtualisierung kann man dedizierte Server in kleinere virtuelle Server… bedeutet, dass weniger Kopien von Daten zwischen Architekturschichten notwendig sind, wodurch die Architektur einfacher, kleiner und schneller wird. Die Data-Warehouse-Architektur soll so möglichst schlank und einfach gestaltet werden. Treiber des Data-Warehouse-Service-Levels und der notwendigen Schichten sind die Business Anforderungen. Das Data Warehouse wird bedarfsgerecht entwickelt. Weitere Details zu einem modernen und flexiblen Data Warehouse finden Sie hier.
Grafik 04: Unser Architekturkonzept orientiert an SAP LSA++
Feldbasierte Modellierung
Erstmals mit SAP BW on HANA ist es möglich InfoProvider feldbasiert zu entwickeln. Durch diese bottom-up Modellierung werden Entwicklungen beschleunigt, weil vor einer Datenintegration & Analyse nicht bereits die Semantik beschrieben sein muss. Durch die Möglichkeit zur teilautomatisierten Erstellung von Datenmodellen und Datenflüssen (aDSO / openODS View) wird die Entwicklung zusätzlich beschleunigt. Bereits nach wenigen “Klicks” sind so erste Analysen möglich. Anwender können dadurch sehr schnell erste (einfache) Sichtungen von Daten durchführen – häufig bereits nach wenigen Minuten.
Die Anreicherung feldbasierter Datenmodelle um Stammdaten kann einfach über den Composite Provider erfolgen. Durch die feldbasierte Modellierung und virtuelle Assoziierung von Stammdaten kann ein SAP BW wesentlich schneller und bedarfsgerechter entwickelt werden. Der Flaschenhals eines BW Projekts, die massenhafte InfoObject Erstellung, wird optional. Insofern kann die feldbasierte Modellierung ein erheblicher Projektbeschleuniger sein.
Sollte nachträglich der Bedarf bestehen Felder gegen InfoObjects zu tauschen, ist dies durch Remodellierungsjobs möglich.
Dimension Satellites & Snowflaking
Navigationsattribute von InfoObjects können Analysen von Bewegungsdaten erheblich aufwerten. In SAP-BW-Systemen ohne SAP HANA musste zur Nutzung von Navigationsattributen eine Einstellung in Data Store Objekten bzw. InfoCubes erfolgen. Längere Aktivierungen der Objekte war die Folge. Die Flexibilität und Einfachheit der Anpassung war in der “vor HANA” Zeit eingeschränkt.
Mit Einführung des Composite Providers ist eine vollständige Entkoppelung von Semantik und Persistenz möglich (flexible dynamic star schema). Stammdaten (egal ob virtuell durch OpenODS Views oder persistent durch InfoObjects repräsentiert) können im Composite Provider rein virtuell “assoziiert” werden. Es reichen Einstellungen am Composite Provider aus für die virtuelle Anreicherung von Transaktionsdaten. Die Flexibilität wird zusätzlich vergrößert durch die Möglichkeit mehr als ein InfoObject bzw. openODS View mit einem Feld in den Transaktionsdaten zu assoziieren. Zu einem Feld “Auftrag” lassen sich bspw. ein OpenODSView “Auftrag Attribute technisch virtuell” und ein InfoObject “Auftrag Attribute fachlich persistent” gleichzeitig assoziieren. Die Flexibilität weiter erhöht wird durch den Einsatz transitiven Attributen (Snowflaking).
Grafik 05: Tansitive Attribute (Snowflaking)
Das flexible dynamic Star Schema ist zunächst nur eine technische Eigenschaft des SAP BW. In “Zusammenarbeit” mit Designentscheidungen erweitert sich die Flexibilität des BW Systems erheblich. Zwei Aspekte sind hervorzuheben. Die feldbasierte Modellierung (zuvor bereits erläutert) sowie die Modellierung von Dimension Satellites.
Grafik 06: Assoziierung im Composite Provider
Die Datenmodellierung im SAP BW verändert sich durch diese neuen Möglichkeiten. In klassischen Systemen mussten Stammdaten – auch wenn sie Ihren Ursprung in unterschiedlichen Tabellen & Systemen haben – konsolidiert werden in ein InfoObject, wenn man nicht die Transaktionsdaten erweitern wollte. Dies hat zu großen unflexiblen InfoObjects geführt. Nun ist es möglich, Stammdaten entkoppelt und modular als Dimension Satellites zu modellieren. Ein Satellit kann hierbei bspw. jeweils eine Quelltabelle in einem Quellsystem repräsentieren. Dadurch erhält man kleinere, physisch unabhängige flexiblere Einheiten, die unabhängig voneinander und unabhängig von persistierten Bewegungsdaten verändert werden können. Auch ist das Modell iterativ erweiterbar um weitere Satelliten, die fallweise persistent (InfoObject) oder virtuell (openODS View) abgebildet werden können.
Manchmal ist es zielführend zentrale Business Entitäten in einem Objekt abzubilden, statt vieler einzelner InfoObjects bzw. open ODS Views. In diesen Fällen kann ein virtueller Join der Satelliten mit Hilfe eines Calculation Views erfolgen und Bereitstellung im SAP BW über einen openODS View. Durch die rein virtuelle Abbildung der Business Entität verliert man keine Flexibilität, kann aber zusätzlich bei Bedarf Stammdatenlogiken abbilden.
Grafik 07: Dimension Satellites / Virtuelle Stammdatenmodelle
Satelliten für Bewegungsdaten und Virtualisierung von Datenflüssen
Was für Stammdaten gilt (Dimension Satellites), sollte auch für Bewegungsdaten geprüft werden. Wenn Business Logiken und Joins persistiert werden in neuen aDSO verliert man immer Flexibilität und Entwicklungsgeschwindigkeit. Ein einfacheres Refactoring von Datenmodellen ist möglich, wenn Business Logiken und Joins entweder…
- Virtuell über HANA Calculation Views oder Composite Provider abgebildet werden oder
- möglichst gekapselt in Data Marts. Dabei werden nur zusätzlichen Informationen aus Berechnungen gespeichert, nicht aber nochmal die Daten aller beteiligten Info-Provider. Diese können etwa über einen Composite Provider verbunden werden.
Grafik 08: Satelliten-Konzept Bewegungsdaten
Die doppelte Haltung von Daten ist zu vermeiden. Es gilt der Grundsatz „Virtualization as much as possible, persistence only where really needed”. Änderungen lassen sich durch dieses Design schnell und flexibel durchführen. Im Falle der vollständigen Virtualisierung, sehen Anwender unmittelbar die Auswirkungen von Datenmodellanpassungen. Ein Refactoring ist ebenfalls leicht möglich, weil keine bzw. kaum Einschränkungen durch persistierte Datentabellen bestehen. Ein Beispiel für ein sehr virtualisiertes SAP BW/4HANA finden Sie hier.
In der Praxis wird es selbstverständlich Fälle geben, in denen dieses Prinzip nicht anwendbar ist. Naheliegend sind bspw. Performancegründe oder die (breite) Historisierung von Daten. Am Ende ist es eine Abwägung, die im konkreten Einzelfall zu treffen ist. Wir plädieren aber für eine “Vorfahrt” für den flexibleren Modellierungsansatz.
Fazit
Lange Entwicklungszyklen, unflexible Datenmodelle, sehr hohe Kosten des Betriebs sowie eine fehlende Anwenderorientierung sind verbreitete Kritikpunkte an SAP-BW-Systemen. Technisch bietet SAP BW/4HANA im Vergleich zu bisherigen (nonHANA) SAP-BW-Systemen viel mehr Möglichkeiten ein Data Warehouse bedarfsgerecht und nutzerorientiert zu entwickeln. Notwendig ist ein konsequent “agiles Design” von SAP-BW/4HANA-Systemen. Um die Potentiale einer agilen Modellierung mit SAP BW/4HANA aufzuzeigen, werden wir in einem der kommenden Beiträge, anhand eines Beispiels aufzeigen wie ein SAP BW/4HANA modelliert werden kann, um sich schnell & einfach an Veränderungen anzupassen. Neben dem Design des SAP BW muss bewusst sein, dass auch der Entwicklungsprozess und die Organisationskultur Agilität erlauben müssen. Wir sehen die Chance Entwicklungszyklen deutlich zu verkürzen und die Akzeptanz von SAP-BW-Systemen zu verbessern.
Grafik 09: Bedarfsgerechte Weiterentwicklung mit BW/4HANA
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
