SAP BTP-Administration: Architektur, Governance und Betrieb

Globales Konto, Verzeichnisse und Unterkonten

Jede BTP-Landschaft beginnt mit einem globalen Konto (Global Account). Dort sind die gebuchten Berechtigungen für Laufzeiten, Speicher und Plattformservices festgelegt. Darunter hängen Unterkonten (Subaccounts), jeweils in einer Region verankert, mit eigener Runtime, eigenen Services, eigenen Identitätsbeziehungen und eigenen Richtlinien. Verzeichnisse (Directories) dienen als Zwischenschicht, um Unterkonten nach Geschäftsbereichen, Projekten oder Systemlandschaften zu gruppieren und Entitlements sowie Berechtigungen zu verteilen.

Administratoren entscheiden an dieser Stelle, ob sie pro Landschaft eine Struktur mit Entwicklung, Test und Produktion aufbauen, ob sie Mandanten nach Ländern oder Geschäftsbereichen trennen und wie sie Verzeichnisse nutzen. Jede Entscheidung hat Folgen für Mandantentrennung, Kostenkontrolle und Betrieb. Ein Unterkonto erhält genau eine Region, aber beliebig viele Services. Administratoren planen daher vorab, welche Regionen SAP S/4HANA Cloud, Subscription Billing, Integration Suite oder Kyma unterstützen und wie Anforderungen an EU Access oder branchenspezifische Regularien in die Struktur einfließen.

Environments und Runtimes: Cloud Foundry, ABAP und Kyma

Umgebungen (Environments) bilden die eigentliche PaaS-Schicht. Cloud Foundry adressiert dabei die klassische Anwendungsentwicklung mit polyglotten Runtimes, Buildpacks und instanzbasierter Skalierung. Eine aktivierte Cloud Foundry Environment Instance hängt an einem Unterkonto. Dazu gehört genau eine Org mit mehreren Spaces. In diesen Spaces laufen Applikationen, Service-Instanzen und Bindings, die über die Kombination aus Manifest, Service Keys und Destinations kommunizieren.

Die ABAP-Umgebung hat dieselbe Basis, bringt aber einen eigenen ABAP-Stack mit HANA-Datenbank und Cloud-optimiertem ABAP-Sprachumfang mit. Die Administration umfasst hier sowohl klassische ABAP-Themen wie Transportmodelle und Mandantenkonzept als auch BTP-spezifische Punkte wie Destinations, Service-Instanzen und XSUAA-Konfiguration.

Kyma Runtime stellt wiederum eine verwaltete Kubernetes-Umgebung bereit. Jede Kyma Environment Instance erzeugt genau einen Cluster pro Unterkonto. Darin organisieren Administratoren Namespaces, Workloads, Ingress, Zertifikate, Secrets und Module. Kyma bringt eigene Module wie API-Gateway, Eventing, BTP-Operator und Telemetry mit. Die Plattform sorgt für Hochverfügbarkeit und Self Healing, allerdings konfigurieren Administratoren die Größen der Worker Nodes, Kapazität, Backup-Strategien sowie OIDC-Einstellungen selbst.

Rollen, Identitäten und Platform User

Die SAP Business Technology Platform unterscheidet zwischen Platform User und Business User. Platform User sind Administratoren, Entwickler und Operatoren mit Zugriff auf Cockpit, btp CLI und Environments. Business User arbeiten in Fachanwendungen wie Subscription Billing oder Integrated Product Development. Grundlage ist immer ein externer Identity Provider, bevorzugt ein SAP Cloud Identity Services Tenant, der über Trust an globale Konten und Unterkonten gekoppelt ist.

Rollenmodell und Administration folgen einem klaren Schema. Einzelne Rollen, die aus Rollenvorlagen stammen, bündeln Scopes einer Anwendung. Rollensammlungen fassen mehrere Rollen zusammen und werden den Nutzern zugewiesen. Für Plattformadministration existieren vordefinierte Sammlungen wie Global Account Administrator, Subaccount Administrator oder Directory Administrator. Diese Rolle steuert, wer Berechtigungen konfiguriert, Unterkonten anlegt, Umgebungen erzeugt oder Identitätsanbieter pflegt.

Für SaaS-Anwendungen liefern die Anwendungen eigene Rollenvorlagen, die Administratoren in fachliche Rollensammlungen übersetzen. Im Integrated Product Development-Umfeld gibt es zum Beispiel Sammlungen wie EPD Administrator, EPD Quality Manager oder EPD Design Engineer, die Kombinationen aus App-Rollen, Workflow-Rechten, Visualisierungsrechten und Kollaborationsrechten enthalten.

Business User und Zugriff auf BTP-Applikationen

Business User melden sich nie direkt im Cockpit an, sondern in Anwendungen, die im Unterkonto abonniert wurden. Für diese Nutzer entsteht im Unterkonto ein Schattennutzer, der über eine Rollensammlung Berechtigungen erhält. Administratoren entscheiden, ob sie Business User direkt in der Business Technology Platform pflegen, ob sie Provisionierung über Identity Provisioning Services verwenden oder ob sie ausschließlich auf Gruppen aus dem Corporate IdP setzen. Ein wichtiger Punkt dabei ist die saubere Trennung der Identity Provider für Platform User und Business User, insbesondere bei S/4HANA Cloud und BTP übergreifenden Szenarien.

Für Anwendungen definieren Administratoren Rollen für Administrationsaufgaben, Fachfunktionen und eingeschränkte Sichten. In produktiven Mandanten empfiehlt sich ein Least-Privilege-Ansatz, der zunächst breite Rechte für Implementierung und Tests nutzt und dann gezielt auf granulare Sammlungen mit Markt, Land oder produktspezifischen Einschränkungen reduziert.

Destinations, Cloud Connector und Netzarchitektur

Zentrales Konzept für Verbindungen sind Destinations. Jede Destination beschreibt Ziel-URL, Authentifizierungsart, Proxy-Typ, Token-Service und zusätzliche Parameter. Für reine Cloud-zu-Cloud-Szenarien genügt die Konfiguration im Unterkonto. Für On-Premises-Systeme kommt der Cloud Connector hinzu. Dieser stellt einen Outbound Tunnel vom internen Netzwerk in das BTP-Unterkonto bereit. Administratoren definieren im Connector Ressourcen, Pfade, Protokolle, Ports und System-Aliasse und verbinden den Connector mit einem oder mehreren Unterkonten.

Konfigurationen greifen in allen Szenarien. Integrated Product Development verlangt Destinations für Workflows, Identity Authentication, Object Store, PLM System Integration und diverse SAP-Systeme. Subscription-Billing-Integrationen mit S/4HANA Cloud benötigen Destinations für API-Integration, UI Integration, Event Hub oder Event Mesh und S/4HANA-Zielsysteme. Falsche Pfade oder Zertifikate führen sofort zu Kommunikationsfehlern, daher sollten Administratoren jede Destination dokumentieren, inklusive Authentifizierungsart und zuständigem System.

Integration Suite als zentrale Integrationsplattform

Die Integration Suite stellt auf SAP BTP die zentralen Werkzeuge für die Anwendungsintegration bereit. Sie verbindet Anwendungen und Daten On-Premises und in der Cloud, orchestriert Geschäftsprozesse, verwaltet APIs und realisiert ereignisgesteuerte Szenarien. Architekten und Integrationsentwickler arbeiten in der Suite mit Integration Flows, APIs, Adaptern und Events. Administratoren betrachten dieselbe Plattform aus Betriebs- und Governance- Perspektive.

Kernbaustein sind die Integration Flows. Sie stellen Integrationsszenarien grafisch dar, definieren Datenflüsse, Konvertierungen, Bedingungen, Aufrufe externer Systeme und Reaktionen auf Ereignisse. Das Modell ist visuell, weshalb auch Admins ohne Programmierhintergrund den Verlauf eines Szenarios nachvollziehen können. Die Wiederverwendung solcher Flows in mehreren Szenarien senkt Entwicklungsaufwand und reduziert Fehler.

Ein weiterer Baustein ist API-Management. Hier erstellen Administratoren API-Proxys, definieren Produkte, legen Security Policies fest, beschränken Call-Volumen, erzwingen OAuth oder mTLS und sammeln Nutzungsstatistiken. Das Management wird über Vorlagen, Richtlinien und zentrale Verzeichnisse standardisiert.

Für ereignisbasierte Architekturen nutzt die Integration Suite Event Backends, die auf Event Mesh oder Cloud Application Event Hub verweisen. So lassen sich SAP S/4HANA, Subscription Billing, externe Fachsysteme und Eigenentwicklungen über Events koppeln. Daraus entsteht eine Architektur, in der Systeme auf Änderungen reagieren, statt periodisch Daten abzuholen.

Business Accelerator Hub und vordefinierte Inhalte

Die Kombination von Integration Suite und SAP Business Accelerator Hub verschiebt den Schwerpunkt von Eigenentwicklung auf Wiederverwendung. Im Hub liegen tausende Integrationsszenarien, Events und Konnektoren für SAP und Nicht-SAP-Systeme. Administratoren wählen dort Produkt und Szenario, sehen passende APIs, Integrationspakete und Konnektoren und können diese direkt in die Integration Suite übernehmen.

Die Integration Suite verwendet diese Inhalte über das Discover-Konzept. Ein API-Paket für S/4HANA Product Master wird im Hub analysiert, in der Suite übernommen und dort zu einer konkreten API-Instanz mit definiertem Host, Pfad und Sicherheitskonfiguration transformiert. Administrativ relevant ist dabei die Verbindung zwischen Unterkonten, API-Management und Zielsystem. Fehler in dieser Kette führen direkt zu Ausfällen in produktiven Schnittstellen.

SAP BTP Administrators Guide und Guidance Framework

Der BTP Administrators Guide (PDF) beschreibt einen vollständigen Lifecycle für Anwendungen auf der Plattform. Er beginnt bei Onboarding und Identity Services, führt über Strukturierung von Konten und Sicherheitsmodellen zur Entwicklung und mündet in Betrieb, Monitoring, Optimierung und Stilllegung.

Das SAP BTP Guidance Framework bündelt Entscheidungsleitfäden, Referenzarchitekturen und DevOps-Prinzipien. Architekten und Projektleiter erhalten dort Vorschläge für sinnvolle Kontomodelle, Security Patterns, Observability-Konzepte und Deployment-Strategien. Administratoren nutzen den Guide, um Verantwortlichkeiten im Shared-Responsibility-Modell klar zuzuordnen. Plattform, Infrastruktur und Basis werden von SAP betrieben, Architektur, Zugänge, Konfiguration der Services und Applikationen liegen beim Kunden.

Einrichtung am Beispiel von SAP Subscription Billing

Das folgende Subscription-Billing-Szenario zeigt, was Administration auf der BTP bedeutet. Nach Bestellung der Lösung liegt ein Entitlement im globalen Konto. Administratoren entscheiden, ob sie einen Booster nutzen oder den Onboarding-Prozess manuell durchführen. Der Booster legt einen Unterkonto an oder nutzt einen bestehenden, weist Entitlements für Subscription Billing, Price Calculation und optional Event Mesh zu, aktiviert Subscriptions, erzeugt Service-Instanzen und Service Keys und ordnet Benutzerrollen für Administratoren und Entwickler zu.

Beim manuellen Weg folgen Administratoren einer klaren Sequenz. Zuerst prüfen sie die Bereitstellung im globalen Konto, dann fügen sie Administratoren hinzu, erzeugen Unterkonten in passenden Regionen und weisen Entitlements zu. Anschließend abonnieren sie die Anwendung Subscription Billing und Price Calculation im selben Unterkonto, damit zusammengehörige Tenants entstehen. Danach definieren sie Administratoren der Unterkonten, konfigurieren Identity Provider, bauen Rollensammlungen auf und ordnen diese Nutzern und Gruppen zu.

Für den API-Zugriff kommt Authorization and Trust Management Service ins Spiel. Die Administratoren erzeugen Service-Instanzen für Subscription Billing und Price Calculation, definieren Scopes per JSON, legen Service-Bindings mit Client ID und Secret oder mit Zertifikat an und dokumentieren die Token-Endpunkte. Im S/4HANA Cloud-Kontext wird mTLS über X.509-Zertifikat empfohlen. Die Zertifikatslaufzeiten müssen überwacht und rechtzeitig erneuert werden.

Eine Formation gruppiert S/4HANA-Tenant, Subscription Billing Tenant sowie Unterkonto und automatisiert API-Setup, UI Integration und Event-Kopplung. Formation erzeugt Service-Instanzen mit zertifikatbasiertem Zugriff, legt Kommunikationssysteme und Arrangements in S/4HANA an und richtet Destinations im Unterkonto ein. Dadurch sinkt die Fehleranfälligkeit im Vergleich zu einer rein manuellen Konfiguration.

Administration der SAP S/4HANA Cloud-Verbindungen

Die Logik der S/4HANA Cloud-Verbindungen auf der BTP entspricht dem oben skizzierten Beispiel. Administratoren registrieren S/4HANA-Tenants im globalen Konto, erzeugen Tokens, die im S/4HANA-Tenant zur Einrichtung verwendet werden, und überwachen die Registrierung. In der System-Landscape-Ansicht erscheinen die registrierten Systeme, ihre Formation, Zugehörigkeit und ihr Status. Ein Tenant lässt sich nur einmal pro globalem Konto registrieren, ein Umzug erfordert Neuregistrierung und Neuaufbau der Zuordnung.

Gleichzeitig konfigurieren Administratoren Kommunikationssysteme, Benutzer und Arrangements auf S/4HANA-Seite. Sie pflegen Zertifikate, OAuth-Endpunkte, Ziel-URLs und verbinden S/4HANA-Kommunikationsszenarien mit BTP-Services wie Subscription Billing, Integration Suite oder Event Hub. Für ereignisbasierte Szenarien kommt SAP Cloud Application Event Hub oder Event Mesh ins Spiel. Dort definieren Administratoren Event Flows, Zertifikate, technische Nutzer und die zugehörigen Ziele auf BTP-Seite.

Steuerung und Betrieb des Business Application Studio

SAP Business Application Studio (BAS) bildet die integrierte Entwicklungsumgebung (IDE) in der Business Technology Platform. Für Administratoren geht es nicht um Projekterstellung, sondern um Quotas, Service-Pläne, Dev Spaces und Rechte. Der BAS-Service existiert als Abonnement im Unterkonto, intern entstehen Dev Spaces mit zugewiesenen Ressourcen. Administratoren definieren, welche Space-Typen erlaubt sind, wie lange inaktive Spaces laufen, wie viel CPU und Speicher pro Space verfügbar ist und wie Backups und Artefakt-Speicher organisiert sind.

Git-Integrationen erfordern SSH-Schlüssel oder Zugriffstoken. Bannregeln für unerwünschte Git-Endpunkte, Einschränkungen auf bestimmte Repositories und Vorgaben zu Branching und Review-Pflicht gehören in Governance-Leitlinien. Zusätzlich prüfen Administratoren, wie BAS mit Cloud Foundry oder Kyma integriert ist, welche Buildpacks oder Container Images verfügbar sind und wie Entwickler Services wie HANA Cloud, Destinations oder Integration Suite aus Dev Spaces heraus konsumieren.

Infrastructure as Code mit Terraform und BTP-Provider

Die Automatisierung auf BTP-Ebene wird mit Terraform leichter. Terraform beschreibt Infrastruktur deklarativ. Statt Klickfolgen im Cockpit definieren Administratoren in HCL-Dateien Ressourcen wie globale Konten, Unterkonten, Entitlements, Environment-Instanzen, Service-Instanzen, Destinations, Rollensammlungen und Zuweisungen. Ein Planlauf zeigt den Unterschied zwischen aktuellem Zustand und gewünschter Zielkonfiguration.

Der BTP-Provider unterstützt eine breite Palette an Ressourcen. Administratoren legen Unterkonten mit Region, Plan und Labeln an, verteilen Entitlements, aktivieren Cloud Foundry, erzeugen Destinations, richten S/4HANA-Formations ein oder provisionieren HANA-Cloud-Instanzen. Der Provider nutzt intern BTP APIs und btp CLI und hält den Status in einer Datei fest. Diese Datei gehört in ein zentrales Remote-Backend, versioniert und mit Zugriffsschutz versehen.

Eine Main-Datei enthält Ressourcendefinitionen für Unterkonten, Entitlements, Subscription, Instanz und Nutzerrollen. Variablen-Dateien definieren globale Account IDs, Regionen, Unterkontonamen und HANA-Parameter. Output-Dateien bereiten Werte wie Admin-Passwort, Instanz-IDs oder Hostnamen auf. Über Environment-Variablen gelangen Benutzername und Passwort des BTP-Accounts in die Ausführung. Plan und Apply legen Unterkonto, HANA Cloud Trial-Instanz und alle zugehörigen Ressourcen an, Destroy löscht alles wieder. Solche Muster eignen sich für Schulungen, Testläufe oder kurzlebige Projektumgebungen.

API-Steuerung, Sicherheitsarchitektur und technische Richtlinien

API-Governance bündelt Sicherheit, Stabilität und Wiederverwendbarkeit von Schnittstellen. Das API-Management in der BTP erlaubt die Definition von Proxys vor Backend-Services. Administratoren steuern dort Pfade, Methoden, Authentifizierung, Rate Limits, Quotas, Caching und Transformationslogik. Policies legen fest, ob ein Aufruf einen gültigen OAuth-Token mit bestimmten Scopes tragen muss, ob mTLS erforderlich ist, welche IP-Bereiche zugelassen sind und wie lange Tokens gültig bleiben.

Für sicherheitsrelevante Komponenten spielt der Authorization and Trust Management Service eine zentrale Rolle. Dieser verwaltet OAuth-Clients, Scopes, Rollenvorlagen, Rollensammlungen, Trust-Konfigurationen zu einem Identity Provider und technische Artefakte wie Keys und Zertifikate. Die Dokumentation enthält auch Limits, Rate Limits und Backup-Konzepte für diese Services.

Monitoring, Betrieb und Security

Ein stabiler Betrieb verlangt laufende Überwachung. Im Cloud Foundry-Umfeld gehören dazu Org und Space-Verwaltung, Anwendungsläufe, Health Checks, Logs, Metriken, Scale Operationen und Audit-Events. Die Plattform begrenzt Request Header-Größen, gleichzeitige Verbindungen und Logging-Rate, Administratoren berücksichtigen diese Werte beim Design ihrer Anwendungen.

In Kyma verwalten Administratoren Cluster-Parameter, Module, Node Pools, Storage-Größen, Backups, OpenID Connect-Konfiguration und Admission-Policies. Sie kontrollieren Telemetry-Module, verteilen Logs und Traces an Backend-Systeme und lesen Kyma-spezifische Ereignisse aus.

Security-Aspekte umfassen Malware-Schutz in Plattformkomponenten, Schwachstellenmanagement für Betriebssysteme, Buildpacks und Runtimes sowie klare Abgrenzung der Zuständigkeiten zwischen SAP und Kunde. SAP übernimmt Plattform-Security, der Kunde verantwortet Applikationskonfiguration, eigene Images, Abhängigkeiten und geheime Daten.

Für wiederholbare Deployments setzen Teams auf CI/CD-Pipelines. SAP Continuous Integration and Delivery bietet vordefinierte Pipelines für Cloud Foundry-Anwendungen, Integration Suite-Artefakte und Fiori-Projekte. Pipelines holen Quellcode aus Git, bauen Artefakte, testen, deployen und aktualisieren BTP-Artefakte. Administratoren verbinden diese Pipelines mit Terraform-Skripten und erreichen damit nicht nur Applikations-Deployment, sondern auch Plattformveränderungen in einem konsistenten Prozess.

Governance und Betriebsorganisation

Eine große BTP-Landschaft ohne Governance kann sich innerhalb kurzer Zeit zu einem schwer administrierbaren Konglomerat entwickeln. Administratoren definieren daher verbindliche Konventionen. Dazu gehören Benennung von Subaccounts, Directories, Spaces, Destinations, Services und Rollensammlungen, Regeln für die Wahl einer Region, Templates für Service-Instanzen, Policies für Identity Provider, Richtlinien für Logging, Backup und Retention, Vorgaben für Entitlement-Management und Kostenverantwortung sowie Freigabeprozesse für neue Services.

Diese Governance funktioniert nur, wenn sie im Alltag umgesetzt wird. btp CLI und APIs unterstützen dabei, den Ist-Zustand gegen gewünschte Standards zu prüfen. Berichte über nicht verwendete Services, alte Unterkonten, überdimensionierte Quotas oder offene Rollen sind Pflicht.