Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Designing a dev, test and prod landscape

9 min

A good BTP account structure makes change safe and costs visible; a poor one makes both hard. SAP's learning material for solution architects describes several patterns: subaccounts per stage (development, test, production), development subaccounts per project feeding shared test and production subaccounts, staged subaccounts per division or line of business grouped in directories, and directories by region. All of them share one principle: stages are separate subaccounts, because separate subaccounts give separate users, trust settings and entitlements, and allow a locked-down production.

Global account: Contoso Motor Co.Central platform team; entitlements from the contract
Directory: ERP extensionsLabels: cost center, owner. Holds the staged subaccounts for S/4HANA extensions
Subaccounts: cmc-ext-dev, cmc-ext-test, cmc-ext-prodSame US region; Cloud Foundry enabled; matching service plans
Directory: Shared servicesHolds cmc-central-services for SAP Cloud Transport Management and alerting
Subaccount: cmc-sandboxExperiments on free tier plans; never connected to production data
Contoso's BTP account structure.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-101

Pair every BTP stage with an ERP stage

Side-by-side extensions talk to the ERP. If the BTP test subaccount points at the production SAP S/4HANA system, a test can create real orders; if production points at QAS, users see test data. So each BTP stage is paired with one ERP stage, through destinations configured in that subaccount. Contoso's pairing is simple, and Priya checks it at the start of every test cycle.

BTP subaccountPurposeConnected SAP S/4HANA systemWho has access
cmc-ext-devBuild and unit testCMD (development)Developers
cmc-ext-testIntegration and acceptance testingCMQ client 100 (test)Testers, key users, release team
cmc-ext-prodLive useCMP (production)Business users; administrators only by approved access
cmc-central-servicesTransport and alerting across stagesNone directlyRelease and operations team
cmc-sandboxExperimentsNone, or a sandbox onlyDevelopers

Stage pairing between BTP and the ERP landscape.

Rules that keep the structure healthy

  1. Naming convention. Company, purpose and stage in every subaccount name, for example cmc-ext-test, so nobody deploys to the wrong one.
  2. Labels. Cost center, owner and stage on every directory and subaccount, so costs can be reviewed by area.
  3. Same plans in test and production. Smaller quotas in test are fine; different plans are not.
  4. Restricted production. Few administrators, no developer deployments by hand; changes arrive by a controlled transport.
  5. One region per stage chosen deliberately. Close to users and compliant with data residency requirements.
  6. Shared tools in their own subaccount. Transport and alerting serve all stages, so they should not live inside one of them.
One staged trioDev, test, prod subaccounts under the global account. Right for a single extension program.
Project dev subaccountsA development subaccount per project feeding shared test and prod.
Directory per business areaStaged trios grouped in directories with their own administrators and entitlements.
Regional directoriesDirectories by region, then by business function, for global organizations.
Choosing an account structure pattern. Start simple and grow into directories.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-101
  1. Week 1Account skeletonDirectories, the three staged subaccounts, sandbox and shared services subaccount created with names and labels
  2. Week 1Identity and trustEach subaccount trusts the corporate identity provider; administrator role collections assigned to named people only
  3. Week 2EntitlementsService plans and quotas assigned per subaccount; test and production plans compared line by line
  4. Week 2Environments and connectivityCloud Foundry enabled; destinations in each subaccount point to the paired SAP S/4HANA system
  5. Week 3Transport pathSAP Cloud Transport Management set up in the shared services subaccount, with routes from development to test to production
  6. Week 3First release rehearsalA trivial change travels the whole path, proving access, destinations and transport before real work depends on them
The order in which Contoso's platform team set up the BTP landscape. Rehearsing the path early is cheaper than discovering gaps at go-live.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-101

The rehearsal in week 3 is worth copying. A small, harmless change (a label on a launchpad tile, for instance) is built in development, transported to test, checked there, and transported to production. If any step fails, it fails on something trivial, weeks before a real release depends on that path.

Moving content between these subaccounts should not be manual. Developers build in cmc-ext-dev; a transport service carries the tested deployable to cmc-ext-test and then to cmc-ext-prod, with an audit trail of who imported what and when. That is the job of SAP Cloud Transport Management, which runs in cmc-central-services and is the subject of course sap-rel-203.

What would you do?

On a Friday evening, a developer fixes a bug in the fleet order status app and deploys it from the development tools straight into cmc-ext-prod, skipping test. The fix works. What should Luis do on Monday?

Key points
  • Separate subaccounts for development, test and production; spaces or namespaces are not a substitute.
  • Pair each BTP stage with the matching ERP stage through destinations, and check it before testing.
  • Use naming conventions and labels; give test the same plans as production.
  • Keep shared tools such as transport and alerting in their own subaccount.
  • Restrict production: changes arrive by controlled transport, not by hand.

Check your understanding · not graded

Lesson check

  1. 1. Why use separate subaccounts for each stage?

  2. 2. Which SAP S/4HANA system should the BTP test subaccount connect to?

  3. 3. Why put transport and alerting tools in their own subaccount?

  4. 4. What is the role of labels on subaccounts?