DevOps auf der SAP BTP: von der Referenzarchitektur zum Platform Engineering

DevOps auf der BTP ist keine Werkzeugfrage

SAP formuliert es in seiner Referenzarchitektur selbst: DevOps ist in erster Linie ein kultureller Ansatz — Werkzeuge können ihn fördern, nicht ersetzen. Für die Projektpraxis heißt das: Eine BTP-Landschaft wird nicht dadurch DevOps-fähig, dass man den CI/CD-Service bucht. Sie wird es dadurch, dass geklärt ist, wer welche Entscheidung treffen darf — und was einem Team dafür bereitsteht, ohne dass es das selbst bauen muss.

Der SAP-Standard: vier Schritte vom Commit bis zum Betrieb

Die Referenzarchitektur „DevOps with SAP BTP“ beschreibt einen durchgängigen Pfad. Sie ist auf die Cloud-Foundry-Umgebung zugeschnitten, das Konzept überträgt sich aber auf die übrigen Laufzeitumgebungen — SAP verfolgt hier ausdrücklich einen harmonisierten Auslieferungsprozess.

Referenzarchitektur „DevOps with SAP BTP“ · Quelle: SAP Architecture Center

·       1 · Continuous Integration — SAP Continuous Integration and Delivery ist im Kern eine Pipeline-as-a-Service. Man wählt eine Vorlage für ein typisches BTP-Szenario, etwa eine Side-by-Side-Erweiterung nach dem Cloud Application Programming Model (CAP) oder eine SAP-Fiori-Oberfläche, verbindet sie mit dem Git-Repository — und hat eine Pipeline, die bei jeder Änderung baut und testet. Kein eigener Build-Server, kein eigener Pipeline-Betrieb.

·       2 · Entwickeln — SAP Business Application Studio als Entwicklungsumgebung, die Testframeworks aus der Pipeline heraus angestoßen. Der qualifizierte Release-Kandidat wandert in den Release-Branch und löst dort eine getrennte zweite Pipeline aus. Diese Trennung ist bewusst gesetzt: Sie entkoppelt Entwicklung von Auslieferung und schafft den Ort, an dem Compliance-Prüfungen greifen — etwa bekannte Schwachstellen in eingebundenen Drittanbieter-Bibliotheken.

·       3 · Ausliefern — Am Ende der Release-Pipeline steht ein Transport im SAP Cloud Transport Management: eine zentral definierte Auslieferungslandschaft, geregelte Berechtigungen je Knoten und ein zentrales Protokoll für Audits. Die Nähe zum klassischen Transportwesen macht den Dienst in SAP-Organisationen anschlussfähig. Über die Change- und Deployment-Management-Funktionen von SAP Cloud ALM lassen sich BTP-Änderungen mit Änderungen aus Private Cloud und On-Premise abgestimmt orchestrieren.

·       4 · Betreiben — SAP Cloud ALM als zentrale Beobachtungsebene, darunter die lokalen Betriebswerkzeuge der BTP. Dazu gleich mehr.

Zwei Empfehlungen darin werden leicht überlesen und tragen weit: geteilte Dienste wie das Cloud Transport Management in einem eigenen Subaccount neben den anwendungsbezogenen Subaccounts betreiben — und die Konten über den Terraform-Provider für SAP BTP einrichten.

Der Standard lässt Raum für Abweichungen. SAP nennt sie ausdrücklich: ein eigener CI/CD-Server statt des SAP-Dienstes, zusätzliche Testframeworks in den Pipelines, CTS+ für MTA-Archive aus dem ABAP-Stack, Change Request Management oder Quality Gate Management aus dem Solution Manager zur Orchestrierung von Transporten — für neue Szenarien empfiehlt SAP allerdings SAP Cloud ALM. Und über offene APIs lassen sich einzelne Dienste in bestehende Prozesse einbinden, ohne den ganzen Pfad zu übernehmen.

Die Dienste im Überblick

SAP Continuous Integration and Delivery, SAP Business Application Studio und SAP Cloud Transport Management sind Teil von SAP Build.

Betrieb: zentral beobachten, lokal analysieren

In vielen DevOps-Konzepten endet die Betrachtung beim Deployment. Der Betrieb fängt dort aber erst an — und kontinuierliches Überwachen ist keine nachgelagerte Disziplin, sondern eine Kernmethode von DevOps. Die BTP bildet das zweistufig ab: SAP Cloud ALM als übergeordnete Sicht über alle SAP-Produkte, darunter die lokalen Werkzeuge für die Ursachenanalyse. Eigene Anwendungen werden über OpenTelemetry an dieselbe zentrale Sicht angeschlossen.

Die Betriebskette der BTP — von der Störung bis zur automatisierten Gegenmaßnahme

Ein Hinweis, der in Projekten regelmäßig für Verwirrung sorgt: Der SAP Alert Notification service ist kein Monitoring-Dienst, sondern ein Ereignis- und Zustellmechanismus. SAP Cloud ALM nutzt ihn als eine von mehreren Quellen, verarbeitet dabei aber nur eine Teilmenge der verfügbaren Events — und die Integration muss einmalig aktiviert werden. Wer bestimmte technische Ereignisse zusätzlich braucht, legt sie dort als eigene Abonnements mit eigenen Kanälen an.

Wo das Modell an seine Grenze stößt

Die Grenze liegt nicht in der Architektur. Sie zeigt sich, sobald nicht ein Team auf der BTP entwickelt, sondern fünf.

Dann entscheidet jedes Team für sich über Subaccount-Zuschnitt, Destinations, Rollenmodell, Logging und Alerting. Das Ergebnis sind nicht fünf Lösungen, sondern fünf Varianten desselben Problems: zu viele Werkzeuge, zu viele manuelle Übergaben, zu viele Abhängigkeiten. Das kostet Zeit, verlangsamt Releases und frustriert genau die Entwickler, denen man Autonomie geben wollte. Hinzu kommt: Entitlements, Vertrauensbeziehungen, Netzwerkanbindung und Kostenverantwortung lassen sich nicht sinnvoll je Team beantworten. Fehlt eine zentrale Instanz, entsteht Wildwuchs — oder ein Flaschenhals.

Platform Engineering: die Plattform als Produkt

Die Antwort ist nicht weniger Autonomie, sondern besser vorbereitete Autonomie. Ein zentrales Plattform-Team stellt eine standardisierte, sichere Entwicklungsplattform als Self-Service bereit — mit einem Kontomodell samt automatisiertem Onboarding, einheitlichen Sicherheits- und Compliance-Standards, geteilten Services und Vorlagen sowie Guardrails, die Einzelfreigaben überflüssig machen.

Die Plattform als internes Produkt — bereitgestellt durch ein BTP Center of Expertise

Organisatorisch bündelt das ein SAP BTP Center of Expertise: Governance, Enablement und Best Practices an einer Stelle — nicht als Kontrollinstanz, die Vorhaben prüft, sondern als Befähiger, der sie schneller macht. Aus Dev und Ops wird echtes Enablement.

Fazit

Die Referenzarchitektur beantwortet, mit welchen Diensten ein durchgängiger Lebenszyklus auf der BTP aussieht. Sie beantwortet nicht, wer ihn bereitstellt. Genau diese zweite Frage entscheidet darüber, ob DevOps auf der BTP Tempo bringt oder zusätzliche Komplexität erzeugt.

„DevOps ist tot, es lebe das Platform Engineering“ ist eine Zuspitzung. Ihr Kern stimmt: Nicht die Werkzeuge sind das Problem, sondern die Erwartung, dass jedes Team sie sich selbst zusammensetzt. Wer die Plattform als Produkt begreift, bekommt beides — die Geschwindigkeit autonomer Teams und die Kontrolle, die eine Unternehmenslandschaft braucht. Das ist keine Frage der Unternehmensgröße, sondern eine Entscheidung, die man am besten trifft, bevor der dritte Subaccount entsteht.

Wie wir unterstützen

Wir bauen das DevOps-Modell nicht als Konzept auf dem Papier, sondern in Ihre bestehende Landschaft hinein — schrittweise und entlang dessen, was bei Ihnen bereits läuft:

·       Zielbild und Kontomodell — Subaccount-Struktur, Entitlements, Berechtigungs- und Vertrauensmodell, automatisiertes Onboarding über den Terraform-Provider für SAP BTP.

·       Delivery und Transportmanagement — Einführung des SAP Cloud Transport Management, Aufbau der Auslieferungslandschaft, Anbindung an SAP Continuous Integration and Delivery und an Ihre bestehenden Freigabeprozesse.

·       Observability mit SAP Cloud ALM — Setup und Anbindung Ihrer Systeme für Health Monitoring, Job- und Automation Monitoring, Real User Monitoring und Security Configuration, ergänzt um SAP Cloud Logging, den Alert Notification service und automatisierte Gegenmaßnahmen im SAP Automation Pilot.

·       Betrieb und Enablement — laufender Betrieb als Managed Service oder Know-how-Transfer an Ihr eigenes Basis-Team, damit die Plattform bei Ihnen bleibt.

Sie stellen gerade Ihr Cloud-Team oder Ihre BTP-Landschaft neu auf? Wir wollen Ihr BTP Center of Expertise sein und erarbeiten mit Ihnen ein tragfähiges Zielbild — von Kontomodell und Guardrails bis zum laufenden Betrieb. Erfahren Sie mehr über unsere SAP BTP Beratung und unsere SAP BTP Managed Services.