Agile Entwicklungsansätze und -methoden prägen die Softwareindustrie seit den späten 1990er Jahren und gehören heute zum Standard der IT-Industrie.
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 SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Mehr HANA SQL Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Mehr 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)Was ist Continuous Integration?Continuous Integration (Kontinuierliche Integration, CI) ist ein… Mehr, Continuous Delivery (CD)Was ist Continuous Delivery?Continous Delivery (kontinuierliche Lieferung, CD) baut auf… Mehr, Continuous Testing (CTContinuous Testing (CT), ein Bestandteil von CI und CD um… Mehr) und Continuous Feedback einsteigen und unsere Ansätze erläutern.
- Teil 1: Agile Development
- Teil 2: Continuous Integration (CIContinuous Integration, bedeutet die kontinuierliche Zusammenführung von einzelnen Entwicklungsständen (Feature… Mehr)
- Teil 3: Continuous Delivery (CDContinuous Delivery oder Continuous Deployment, zielt darauf ab kontinuierlich viele… Mehr)
- 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 DevOpsWas ist DevOps? Der Begriff DevOps setzt sich aus den… Mehr-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 JiraJIRA ist eine webbasierte Anwendung von Atlassian zur Unterstützung im… Mehr, aufgenommen und in einem ersten Business Model/Konzeptionellen Datenmodell im SAP PowerDesignerClientbasiertes Modellierungswerkzeug, welches ein Leistungsstarkes Modellierungswerkzeug darstellt. Hierbei können eine… Mehr 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 |
|---|---|
|
|
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 |
|---|---|
|
|
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 GitGit stellt ein Softwarerepository da, welches in der Softwareentwicklung einen… Mehr (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 |
|---|---|
|
|
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 werden. Ein gängiges Beispiel sind Prüfungen auf Namenskonventionen, die es im gesamten Projekt einzuhalten gilt. Die 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 |
|---|---|
|
|
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 ausgeliefert. Fü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 |
|---|---|
|
|
Tabelle 06: Zusammenfassung Phase 5
Phase 6: Deploy
Beim Deployment wiederholt sich prinzipiell nur das zuvor beschriebene Continuous Delivery, jedoch 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 Projektvorgabe. Die 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 kann. SAP HANA bietet hier eine spezifische Transporteinheit (MTARArchive File für eine MTA Applikation. Dieses File stellt die… Mehr), 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 CloudDer Begriff Cloud stammt aus dem Englischen, zu deutsch „Wolke“…. Mehr.
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 |
|---|---|
|
|
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 verwenden. In unserem Szenario können die Business User nun ihre Dashboards bauen und das Reporting ausführen (Grafik 07).
Grafik 06: Dashboard–Beispiel 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 Entwicklung. Sinn 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 |
|---|---|
|
|
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
KONTAKT
Stefan Kahle
Senior Executive Manager
SAP Information Management
