SAPCodeMonkeyBTP Governance After Clean Core
Moving extensions to BTP is the right call — and it removes the friction that used to do your governing implicitly. Your account model is your governance model, and it is cheap to make and expensive to change.
Here is a conversation that recurs. An organization moved its extensions to BTP — clean core, released APIs, side-by-side, exactly as recommended. It worked. And now there are thirty-something subaccounts, several of which nobody can account for, monthly consumption is climbing, and when finance asks what a specific project cost, nobody can answer. Nobody did anything wrong technically. They simply never decided how any of it would be governed, because the migration guidance stops at getting the extension off the core.
Clean core removed the constraint that used to govern you
In the old world, everything lived in one system with one transport path. Governance was implicit — you could not do much without going through a channel that already existed. Side-by-side replaces that with a platform where creating a new environment is a few clicks, each environment is independent, and consumption is metered. The old friction is gone, which was the point. But the friction was the governance, and nothing replaced it.
Your account model is your governance model
This is the idea that matters more than any individual setting. How you structure global account, directories and subaccounts determines four things simultaneously, and most people only think about the first. Isolation: what can reach what. Cost: consumption is tracked at subaccount level, so your account structure literally is your cost-reporting structure. Control: entitlements and quotas flow down the hierarchy, so whoever sits at the top of a branch controls what the branches below can provision. Lifecycle: if you cannot say what a subaccount is for, you cannot retire it. Four governance decisions, made once, often by whoever happened to have the credentials.
The three levels
The global account is the realisation of your contract with SAP — where entitlements, quotas and members live, region- and environment-independent. Directories are optional, group subaccounts, can nest, and can distribute entitlements and carry their own administrators, which makes a directory a delegation boundary rather than a folder. Subaccounts are where you actually deploy, and two properties matter enormously: each lives in exactly one region, chosen at creation, and each is independent of every other. Nothing crosses for free; every subaccount needs its own connectivity and trust configuration.
Why it doesn't refactor
A subaccount is region-locked from creation. Things get deployed into it, services get provisioned, identity trust gets configured, and applications get URLs that people bookmark and other systems call. Moving a workload between subaccounts is not a settings change — it is a migration project. So the account-model decision has a dangerous property: it is cheap to make and expensive to change, which is exactly the profile of a decision that gets made badly.
How sprawl actually happens
It is not one bad decision but many reasonable ones. Creating a subaccount is frictionless, so a developer needing somewhere to try something has one in thirty seconds. Nothing has a lifecycle, so the proof of concept from eighteen months ago is still there and its owner has changed teams. And the defaults are not free: in consumption-based global accounts, a default runtime memory quota is automatically assigned to every subaccount, so creating one allocates something. A fourth factor quietly wrecks the reporting — shared service instances, where two projects using one database is often the right call, but the cost sits in whichever subaccount hosts it.
The four decisions, and one caveat
Decide these explicitly and write them down: what a subaccount represents (pick one primary axis — lifecycle, business unit, region or project); who distributes entitlements, which is your real spending control; how costs get attributed, answered before you build the structure rather than after; and what is shared versus isolated, decided per service and recorded. The caveat: governance that gets in the way gets routed around. The goal is not control but fast paths with visible boundaries — a self-serve sandbox with a capped quota, a naming convention, a recorded owner and an expiry date. If your governance model makes the right thing harder than the wrong thing, it is not a governance model. It is a document.
Sources & further reading
- SAP Help — BTP Account ModelGlobal accounts, directories and subaccounts; confirms region-locked, independent subaccounts and entitlements flowing down. Verified live.
- SAP Help — Create a SubaccountThe creation flow and region choice referenced here. Verified live.
Commercial models, default quotas and cockpit navigation change between releases. Verify against SAP Help before committing to a project plan. SAP guidance, transaction availability and dates change between releases and editions. Verify anything here against SAP Help for your own situation before you commit to it. This article is independent commentary and is not affiliated with SAP or any implementation partner.