Praxisreihe agiles SAP HANA SQL Data Warehousing – Teil 1: Agile Development

Beitrag teilen über

Agile Entwicklungsansätze und -methoden prägen die Softwareindustrie seit den späten 1990er Jahren und gehören heute zum Standard der IT-Industrie.

 

Inhaltsverzeichnis

Prozessmodell

      Phase 1: Plan

      Phase 2: Model

      Phase 3: Develop

      Phase 4: Build

      Phase 5: Release

      Phase 6: Deploy

      Phase 7: Operate

      Phase 8: Monito

Fazit

Auch wenn der Bereich des Data Warehousing im Sinne der Adoptionstheorie eher als „late majority“ in Bezug auf diese Innovation anzusehen ist, haben sich auch in dieser Sparte in den letzten Jahren die Entwicklungsansätze stark in Richtung agil verschoben. In dieser Blogreihe wollen wir Ihnen einen Einblick in unsere agile Praxis beim Aufbau eines SAP HANA SQL Data Warehouse geben. In diesem Zusammenhang spielt insbesondere die DevOps-Philosophie eine entscheidende Rolle. Sollten Sie mit diesem Thema noch keine großen Berührungspunkte gehabt haben, haben wir grundlegende Aspekte der DevOps-Philosophie in diesem Blog für Sie zusammengefasst. Weitere einleitende Informationen zum SAP HANA SQL Data Warehousing finden Sie darüber hinaus an dieser Stelle. In diesem ersten Teil unserer Praxisreihe wollen wir Ihnen die einzelnen Phasen der agilen DevOps-Entwicklung des SAP HANA SQL Data Warehouse mit dem spezifischen Tooling anhand eines konkreten Szenarios vorstellen. In den weiteren Blogs werden wir dann genauer in die Kontinuitätsprozesse Continuous Integration (CI), Continuous Delivery (CD), Continuous Testing (CT) und Continuous Feedback einsteigen und unsere Ansätze erläutern.

  • Teil 1: Agile Development
  • Teil 2: Continuous Integration (CI)
  • Teil 3: Continuous Delivery (CD)
  • Teil 4: Continuous Testing (CT)
  • Teil 5: Continuous Feedback

Prozessmodell

Für unser Vorgehen beim agilen SAP HANA SQL Data Warehousing haben wir die klassische DevOps-Schleife entsprechend unserer Arbeitsschritte angepasst, da sie sich im Data-Warehouse-Kontext ein wenig von der Grundkonzeption der Softwareentwicklung abhebt (Grafik 01)Nachfolgend beschreiben wir die acht Phasen der Design- (Dev) und Runtime (Ops). Auf die übergeordneten Kontinuitätsprozesse kommen wir detaillierter in weiteren Blogs der Reihe zu sprechen. In den einzelnen Phasen haben wir unser Vorgehen nach den Elementen einer User Story gegliedert. Eine tabellarische Zusammenfassung findet sich jeweils am Ende eines Abschnitts.  

Grafik 01: DevOps-Prozessmodell SAP HANA SQL Data Warehousing

Das Szenario sieht vor, dass die Business User eines Fachbereichs durch Visualisierungen und Statistiken in Form von Dashboards das Produktportfolio hinsichtlich verschiedener Dimensionen genauer analysieren möchten, um daraus optimierte unternehmerische Entscheidungen ableiten zu können. Da andere Fachbereiche ähnliche Anforderungen haben, soll ein Data Warehouse aufgebaut werden.

Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Business User Produkte in Dashboards analysieren Kosteneffiziente Gestaltung des Produktportfolios
Methodische Form Werkzeuge
Agile Entwicklung (DevOps) SAP HANA SQL Data Warehousing
Tabelle 01: Prozessmodell

Phase 1: Plan

Der Entwicklungsprozess startet mit konzeptionellen Überlegungen der Business User des Fachbereichs gegebenenfalls mit Unterstützung eines Business Analysten. Die relevanten Eigenschaften und Beziehungen der Informationsobjekte und insbesondere die beabsichtigten Auswertungen werden dazu in User Stories, beispielsweise in der Software Jira, aufgenommen und in einem ersten Business Model/Konzeptionellen Datenmodell im SAP PowerDesigner festgehalten. Grafik 02 zeigt ein beispielhaftes Business Model, das die Analyseobjekte (Entitäten) mit ihren Eigenschaften und Beziehung erkennen lässt. Durch das Business Modell ergibt sich eine gemeinsame Kommunikationsbasis, die sowohl für die beauftragende Fachlichkeit als auch für die technischen Umsetzer verständlich ist und so die Grundlage für eine transparente Steuerung des Entwicklungsprozesses schafft. Näheres zu diesem Modellgetriebenen Entwicklungsansatz finden sie in diesem Blog.

Grafik 02: Business Model im SAP PowerDesigner
Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Fachbereich Business Anforderung formulieren Einheitliche Kommunikationsbasis, transparente Steuerung des Entwicklungsprozesses
Methodische Form Werkzeuge
  • User Story / Ticket
  • Business Modellierung
  • Jira
  • SAP PowerDesigner
Tabelle 02: Zusammenfassung Phase 1

Phase 2: Model

Das Business Model wird im nächsten Schritt durch den BI-Architekten in unterschiedlichen Physischen Datenmodellen konkretisiert, um es auf der SAP-HANA-Datenbank implementieren zu können und die technische Definition der Datenverarbeitungsprozesse (ETL, Virtualisierungen, Businesslogiken) für die Entwickler zu spezifizieren. Durch den Modellgetriebenen Ansatz lassen sich viele Artefakte automatisch im SAP PowerDesigner generieren und miteinander verknüpfen (Mapping). Des Weiteren können bestehende Strukturen ausgelesen und wiederverwendet werden (Reverse Engineering). Nach Fertigstellung werden die Modelle aus dem SAP PowerDesigner exportiert und zur Weiterentwicklung in der Entwicklungsumgebung der SAP-HANA-Plattform SAP Web IDE bereitgestellt. Grafik 03 zeigt den Modellierungsprozess mit dem Zusammenspiel der einzelnen Modelle.

Grafik 03: Modellgetriebenes SAP HANA SQL Data Warehousing
Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
BI-Architekt Technische Spezifizierung des Datenmodells Flexibilisierung und Standardisierung des zentralen Datenmodells
Methodische Form Werkzeuge
  • Physische Datenmodellierung
  • Mapping
  • Git Branching
  • SAP PowerDesigner
  • Git
Tabelle 03: Zusammenfassung Phase 2

Phase 3: Develop

Nach dem Import der Modelle können die Entwickler in der SAP Web IDE mithilfe sogenannter Flowgraphs ETL-Strecken bzw. Datenvirtualisierungen konzipieren sowie durch Calculation Views Datenlogiken und Berechnungen erstellen. Die Entwicklung erfolgt dabei in isolierten Entwicklungsbereichen auf der SAP-HANA-Datenbank. Die Entwickler können auf diese Weise unabhängig voneinander arbeiten. Die Zusammenführung der auf diese Weise parallel entstehenden Entwicklungen erfolgt schließlich über das verteilte Versionskontrollsystem Git (Grafik 04).  Der Umfang einer Entwicklung an der einzeln oder gemeinsam gearbeitet wird ist individuell gestaltbar. Die DevOps-Philosophie empfiehlt grundsätzlich sich auf möglichst kleine, lauffähige Artefakte zu konzentrieren und diese jeweils aus der Designtime in eine produktive oder zumindest produktivähnliche (QA-System) Runtime zu überführen. Die Entscheidung, welche Entwicklungsschritte zu einem solchen lauffähigen Artefakt gehören, muss im Einzelfall getroffen werden.  

Grafik 04: Zusammenführung Isolierter Entwicklungsarbeiten in Git
Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Entwickler Definition von ETL und Businesslogik Technische Umsetzung des Datenmodells
Methodische Form Werkzeuge
  • Sandboxes
  • Git Branching
  • SAP Web IDE
  • Git
Tabelle 04: Zusammenfassung Phase 3

Phase 4: Build

Beim Build-Vorgang werden die in der SAP Web IDE einzeln entwickelten Designtime-Objekte in Runtime-Objekte auf der SAP-HANA-Datenbank transformiert und im Git-Repository abgelegt. Auf Basis der Änderungen im Git können automatische Tests durch ein Automatisierungstool, wie Jenkins ausgelöst werdenEin gängiges Beispiel sind Prüfungen auf Namenskonventionen, die es im gesamten Projekt einzuhalten giltDie weitere Integration der auf diese Weise parallel entstehenden Entwicklungen erfolgt durch ein ständiges Zusammenführen der verschiedenen Entwicklungsstände im Git (Grafik 04)Dieser Prozess wird in DevOps unterm dem Stichwort Continuous Integration (CI) zusammengefasst. Auch die Vornahme umfangreicher Tests hat in diesem Zusammenhang eine große Relevanz und wird mit dem Begriff Contnuous Testing umschrieben. Eine detaillierte Betrachtung dieser zentralen Kontinuitätsprozesse im Rahmen des SAP HANA SQL Data Warehousing finden Sie in den demnächst folgenden Teilen unserer Blogserie.  

Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Entwickler Wechsel Designtime zu Runtime Generierung technischer Datenbankobjekten
Methodische Form Werkzeuge
  • Continuos Integration
  • Continuos Testing
  • Git
  • Automatisierungstool
Tabelle 05: Zusammenfassung Phase 4

Phase 5: Release

Zum Release auf einer übergeordneten Entwicklungsebene, beispielsweise einem gemeinsamen Entwicklungs- oder QA-System werden die verschiedenen Quellcodeversionen konsolidiert und in das Zielsystem ausgeliefertFür diese Konsolidierungsvorgänge wurden in den letzten Jahren die bereits genannten Automatisierungstools (Jenkins, Bamboo) entwickelt. Diese reagieren auf Veränderungen im Git und transportieren die definierten Entwicklungen automatisch in das gewünschte Zielsystem. Darüber hinaus können noch spezifische Tests vorgenommen werden, beispielsweise auf Namenskonventionen oder ähnliches. Auch dieser Prozess sollte im besten Fall kontinuierlich und weitgehend automatisiert erfolgen. In der DevOps-Philosophie wird er als Continuous Delivery (CD) beschrieben. Vertiefende Einblicke in diesen Kontinuitätsprozess des SAP HANA SQL Data Warehousing sowie das weiterhin wichtige Continuous Testing finden Sie in den demnächst folgenden Blogs unserer Praxisreihe. 

Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Automatisierungstool Zusammenführung der Einzelentwicklungen in das Gesamtprojekt Fertige Produkte definieren und auslieferbereit vorhalten
Methodische Form Werkzeuge
  • Continuos Delivery
  • Continuos Testing
  • Git
  • Automatisierungstool
Tabelle 06: Zusammenfassung Phase 5

Phase 6: Deploy

Beim Deployment wiederholt sich prinzipiell nur das zuvor beschriebene Continuous Deliveryjedoch in das Produktivsystem. Zum Schutz des Produktivsystems sind Abweichungen vom grundsätzlichen Vorgehen beim finalen Schritt nicht selten. So werden gegebenenfalls besondere (manuelle) Tests vorgenommen und prinzipiell auslieferbare Artefakte aus Gründen der Vorsicht nur in zusammengefassten und vorab getesteten Paketen produktiv geschaltet, um Fehler zu vermeiden. Die Form des Continuous Deployment, in der die Automationskette bis in das Produktivsystem reicht, haben wir in unseren Projekten bisher noch nicht umgesetzt. Die Deploymentzyklen sind allerdings flexibel gestaltbar und können zwischen Wochen– und Tagesintervallen variieren, je nach ProjektvorgabeDie DevOps-Maßgabe schnell produktiven Mehrwert zu erzielen, lässt sich folglich mit dem SAP HANA SQL Data Warehousing praktisch umsetzen. Darüber hinaus bietet das SAP HANA SQL Data Warehousing an dieser Stelle den Vorteil, dass sowohl On-Premises als auch in die SAP Cloud Platform deployed werden kannSAP HANA bietet hier eine spezifische Transporteinheit (MTAR), die diesen fließenden Übergang möglich macht. Grafik 05 zeigt das Beispiel einer Entwicklung des SAP HANA SQL DWH On-Premises mit produktivem Deployment in der Cloud 

Grafik 05: Entwicklung On-Premises, Produktivsystem in der Cloud
Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Automatisierungstool Ausliefern in das Produktivsystem Zeitnahe Bereitstellung der angeforderten Entwicklung
Methodische Form Werkzeuge
  • Continuos Deployment
  • Continuos Testing
  • Git
  • Automatisierungstool
Tabelle 07: Zusammenfassung Phase 6

Phase 7: Operate

Im Anschluss können die Business User die Entwicklungen im Produktivsystem nutzen und für ihre fachlichen Zwecke verwendenIn unserem Szenario können die Business User nun ihre Dashboards bauen und das Reporting ausführen (Grafik 07). 

Grafik 06: DashboardBeispiel in SAP Analytics Cloud
Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Business User Produkte analysieren Kosteneffiziente Gestaltung des Produktportfolios
Methodische Form Werkzeuge
Täglicher Betrieb SAP-HANA-Datenbank
Tabelle 08: Zusammenfassung Phase 7

Phase 8: Monitor

Werden etwaige Mängel, welche nicht in Tests aufgefallen sind, oder neue Anforderungen festgestellt, fließen die Änderungsanforderungen in Form eines Tickets in den Entwicklungszyklus zurück. Der DevOps-Zyklus beginnt dann von neuem und die Schleife wird abermals durchlaufen. Insgesamt kann auf diese Weise schnell eine hohe Entwicklungsqualität erreicht werden. Auch wenn in diesem Schritt das Feedback zwischen Business Usern und Entwicklern besonders deutlich wird, so lebt DevOps vom Continuous Feedback in allen Phasen, sei es durch spezifische Tests im Rahmen von CI/CD oder der Kommunikation der beteiligten Stellen und Personen in der Modellierung und EntwicklungSinn und Zweck ist dabei eine möglichst enge Kooperation von Entwicklern und Nutzern, um schnellstmöglich produktiv nutzbaren Output generieren zu können.  

Rolle (Wer?) Ziel/ Wunsch (Was?) Nutzen (Warum?)
Business User Hohe Qualität der DWH-Entwicklung Kosteneffiziente Entwicklung des DWH
Methodische Form Werkzeuge
  • User Story / Ticket
  • Continuos Feedback
  • Jira
Tabelle 09: Zusammenfassung Phase 8

Fazit

Im ersten Teil unserer Praxisreihe agiles SAP HANA SQL Data Warehousing haben wir Ihnen die acht Schritte unserer DevOps-Vorgehensweise vorgestellt und konkrete Rollen, Ziele, Methoden, Werkzeuge sowie den Nutzen unseres Tuns beschrieben. In unseren Projekten konnten wir auf diese Weise, die DevOps-Vorteile einer kurzen Entwicklungszeit bis zur Generierung nutzbarer analytischer Erkenntnisse gut umsetzen. Eine wichtige Rolle spielen dabei die kurz angesprochenen Kontinuitätsprozesse, Continuous Integration, Continuous Delivery, Continuous Testing und Continuous Feedback auf die wir in den folgenden Blogs der Praxisreihe näher eingehen wollen. Für Fragen rund um das Thema agiles SAP HANA SQL Data Warehousing stehen wir Ihnen in der Zwischenzeit gerne zur Verfügung. Weitere aktuelle Erläuterungen in Webinar-Form finden Sie zudem bei der DSAG.  

Autor: Dominik Fischer, Martin Peitz

Über ISR

Wir agieren seit 1993 als IT-Berater für Data Analytics und Dokumentenlogistik und fokussieren uns auf das Datenmanagement und die Automatisierung von Prozessen.
Ganzheitlich und im Rahmen eines umfassenden Enterprise Information Managements (EIM) begleiten wir von der strategischen IT-Beratung über konkrete Implementierungen und Lösungen bis hin zum IT-Betrieb.
ISR ist Teil der CENIT EIM-Gruppe.

Besuchen Sie uns virtuell auf diesen Kanälen:

News Kategorien
News Archiv

Zuletzt erschienen

Nächste ISR Events

[tribe_events_list limit=“3″]