SAP BTP Subaccounts richtig strukturieren

Was Subaccounts in SAP BTP leisten

SAP Business Technology Platform (SAP BTP) organisiert Cloud-Ressourcen in einer klaren Hierarchie. Das Global Account bildet den vertraglichen Rahmen für alle lizenzierten Services und Kontingente. Darunter befinden sich Subaccounts als logische Einheiten mit eigenen Berechtigungen, Service-Entitlements und Mitgliederzuweisungen. Zusätzlich bieten Directories eine optionale Zwischenebene, um Subaccounts thematisch oder organisatorisch zu gruppieren. Für Architekturverantwortliche ist dieses Hierarchiemodell der Ausgangspunkt jeder BTP-Landschaftsplanung.

Warum das klassische Dreistufenmodell in der Cloud scheitert

In der SAP-On-Premise-Welt hat sich die Aufteilung in Entwicklung, Qualitätssicherung und Produktion über Jahrzehnte bewährt. Die Versuchung liegt nahe, dieses Prinzip auf SAP BTP zu übertragen und drei Subaccounts anzulegen. In unserem Entwicklungsalltag sehen wir immer wieder, dass diese Übertragung zu Problemen führt.

Das zentrale Risiko liegt in der Entwicklungsebene. Ein einzelner DEV-Subaccount, den sich mehrere Projekte teilen, erzeugt ungewollte Abhängigkeiten bei gemeinsam genutzten Service-Instanzen. Ein konkretes Beispiel: Muss eine PostgreSQL-Instanz im Rahmen eines Projekts neu instanziiert werden, verlieren alle anderen Projekte im selben Subaccount ihre Daten. Solche Seiteneffekte sind in einer Multiprojektlandschaft unvermeidlich, wenn keine Isolation auf Subaccount-Ebene besteht.

Hinzu kommt, dass die Trennung zwischen Entwicklung und Modultest in der Cloud-Welt verschwimmt. Die eigentliche Entwicklung findet häufig lokal oder im SAP Business Application Studio (BAS) statt. Schon das Deployment aus dieser lokalen Umgebung heraus ist ein kontrollierter Transportschritt in eine Testlandschaft. Ein separater Modultest-Subaccount erzeugt in diesem Szenario keinen Mehrwert, sondern zusätzlichen Verwaltungsaufwand.

Projektisolation als Fundament: Ein Subaccount pro Entwicklungsprojekt

Ein tragfähiges Modell setzt nicht auf einen gemeinsamen Entwicklungs-Subaccount, sondern auf dedizierte Subaccounts pro Entwicklungsprojekt. Jedes Projekt erhält seinen eigenen Subaccount mit eigener PostgreSQL-Instanz, eigenen Destinations und eigenen Service-Bindings. So kann ein Team Services neu aufsetzen, Schemata ändern oder Konfigurationen anpassen, ohne andere Projekte zu beeinträchtigen.

In diesen projektspezifischen Subaccounts finden Entwicklung und Modultest als zusammenhängende Aktivität statt. Das Deployment aus BAS oder der lokalen Entwicklungsumgebung in den Projekt-Subaccount ist der erste kontrollierte Transportschritt. Erst wenn die Anwendung dort stabil läuft und die projektinternen Tests bestanden sind, erfolgt der nächste Schritt.

Über Directories lassen sich die Projekt-Subaccounts im Global Account übersichtlich gruppieren. Ein Directory pro Fachbereich oder Programmcluster verhindert, dass die Landschaft bei wachsender Projektanzahl unübersichtlich wird.

Die Konsolidierungsebene: Wo Projekte zusammenwachsen

Nach der projektinternen Stabilisierung folgt eine Ebene, die im klassischen Dreistufenmodell fehlt: die Konsolidierung. In einem eigenen Konsolidierungs-Subaccount werden die Ergebnisse verschiedener Projekte erstmals zusammengeführt.

Die Notwendigkeit dieser Ebene wird am Beispiel der Datenbank deutlich. In der Entwicklung betreibt jedes Projekt seine eigene PostgreSQL-Instanz. Im späteren Produktivbetrieb sollen die Anwendungen jedoch häufig auf einer gemeinsamen Datenbankinstanz laufen. Die Konsolidierungsebene bildet genau dieses Szenario ab. Hier werden Schemakompatibilität, Datenmigrationen und das Zusammenspiel der Services unter realistischen Bedingungen geprüft. Erst wenn das konsolidierte Gesamtsystem stabil funktioniert und alle Integrationstests bestanden sind, wird es in die Produktion überführt.

Hier stellen wir bei Inwerken oft fest, dass diese Konsolidierungsebene den entscheidenden Qualitätssprung bringt. Viele Fehler, die bei einem direkten Transport aus isolierten Entwicklungsumgebungen in die Produktion auftreten würden, werden hier frühzeitig erkannt und behoben. Gleichzeitig zeigt die Praxis, dass Konsolidierung und Produktion bei unterschiedlichen Nutzergruppen nicht immer jeweils nur einmal ausreichen. Wenn interne Mitarbeitende einerseits und externe Nutzerinnen und Nutzer wie Kundinnen und Kunden oder Lieferantinnen und Lieferanten andererseits auf Anwendungen zugreifen, sind oft getrennte Konsolidierungs- und Produktiv-Subaccounts sinnvoll. So lassen sich Sicherheitszonen, Identity and Access Management, Schnittstellenfreigaben und Betriebsprozesse sauber voneinander trennen.

Dedizierte Service-Subaccounts nicht vergessen

Neben den Subaccounts für den Entwicklungszyklus benötigt eine vollständige BTP-Landschaft weitere Subaccounts für zentrale Services, die quer zu den Projektebenen liegen. Ein CI/CD-Service, der Build- und Deployment-Pipelines orchestriert, benötigt einen eigenen Subaccount. Ebenso verhält es sich mit SAP Build Work Zone: Die Testumgebung und die Produktivumgebung des Portals erfordern getrennte Subaccounts, da Work Zone eigene Content-Konfigurationen, Rollenzuweisungen und Integrationen verwaltet, die sich nicht vermischen dürfen.

(Grafik 1)

Auch diese Service-Subaccounts lassen sich über Directories strukturieren. Ein Directory für übergreifende Services hält sie von den projektbezogenen Subaccounts getrennt und erleichtert die Governance.

Ordnung im BTP-System: Empfehlungen zu Rechten und Kontingenten

Mit der höheren Anzahl an Subaccounts steigt die Bedeutung eines strukturierten Entitlement-Managements. SAP BTP verteilt Service-Kontingente vom Global Account auf die einzelnen Subaccounts. Ohne klare Zuordnung besteht das Risiko, dass Entwicklungs-Subaccounts unbemerkt produktive Kontingente aufbrauchen.

Ebenso wichtig ist ein durchdachtes Identity and Access Management (IAM). Idealerweise wird ein einheitlicher Identity Provider für alle Subaccounts konfiguriert, während die Rollenzuweisungen subaccount-spezifisch gesteuert werden. So ist sichergestellt, dass Projektteams nur auf ihren eigenen DEV-Subaccount zugreifen und kein unkontrollierter Zugang zur Konsolidierungs- oder Produktivebene besteht. Regelmäßige Reviews der Entitlements und Berechtigungen gehören dabei zur Governance-Routine, idealerweise synchronisiert mit bestehenden Audit-Zyklen.

Sub-Accounts auf SAP BTP: Von der Architekturentscheidung zur stabilen Landschaft

Eine praxistaugliche Subaccount-Struktur auf SAP BTP geht über das bekannte Dreistufenmodell hinaus. Projektisolation in der Entwicklung, eine dedizierte Konsolidierungsebene und separate Service-Subaccounts bilden zusammen ein Modell, das den realen Anforderungen paralleler Cloud-Entwicklung gerecht wird. Je nach Zugriffsmodell kann dieses Zielbild um eine getrennte Konsolidierungs- und Produktivspur für interne und externe Nutzergruppen erweitert werden.

Inwerken unterstützt beim Ordnung schaffen und Strukturaufbau in der BTP

Wer die eigene BTP-Landschaft von Anfang an strukturiert aufsetzen oder ein bestehendes Modell konsolidieren möchte, findet bei der Inwerken AG erfahrene Ansprechpersonen. Von der initialen Landschaftsarchitektur über die Einrichtung projektspezifischer Subaccounts bis zur Governance laufender Multiprojektlandschaften begleitet Sie das Inwerken-Team den gesamten Prozess.

Sie haben Fragen? Melden Sie sich gern an sapentwicklung@inwerken.de oder vereinbaren Sie einen Termin. Wir freuen uns auf Ihre Kontaktaufnahme!