zhongwei/gh-secondsky-sap-skills-skills-sap-btp-best-practices
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bd301d195d5385b585e6ce01e075ee82c5a9d894
gh-secondsky-sap-skills-ski…/references/account-models.md
Zhongwei Li bd301d195d Initial commit
2025-11-30 08:54:47 +08:00

12 KiB
Raw Blame History

SAP BTP Account Models - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan

Account Hierarchy Deep Dive

Global Accounts

Global accounts are region and runtime-independent entities representing contracts with SAP:

  • Administrators manage subaccounts, members, entitlements, and quotas
  • Typically one global account per commercial model
  • Separate billing per global account
  • Multiple global accounts may be needed for legal or commercial separation

Commercial Contract Options:

  • Consumption-Based: BTPEA, CPEA, Pay-As-You-Go (cannot mix flavors)
  • Subscription-Based: Fixed-cost for 1-3 year periods

Directories

Directories group subaccounts for organized management and can nest up to 5 levels deep.

Directory Use Cases:

  1. Administrative Organization: By subsidiary, department, or line of business
  2. Billing and Accounting: Align with financial structure
  3. Geographical Grouping: Regulatory compliance and performance optimization
  4. Business Scenario Alignment: Group by project or initiative
  5. Resource Control: Usage limitations and quota management
  6. Technical Organization: Based on infrastructure constraints

Subaccounts

Subaccounts are individual operational units where applications run and services are consumed:

  • Deployed in exactly one region
  • Can enable multiple runtime environments
  • Support dedicated identity provider configuration
  • Independent quota and user management

Labels

Labels are user-defined tags for organizing directories, subaccounts, instances, and subscriptions:

  • Landscape designations: Dev, Test, Prod
  • Departments: HR, IT, Finance, Sales
  • Cost center codes
  • Custom tags: "Flagged for deletion", "Important"

Best Practice: Use directories as primary structure, labels for virtual grouping and reporting.

Account Model Templates

Template 1: Directories Per Functional Area

Global Account
├── Directory: HR
│   ├── Subaccount: hr-development
│   │   └── Identity Provider: Corporate IdP
│   ├── Subaccount: hr-test
│   │   └── Identity Provider: Corporate IdP
│   └── Subaccount: hr-production
│       └── Identity Provider: Corporate IdP (hardened)
├── Directory: Sales
│   ├── Subaccount: sales-development
│   ├── Subaccount: sales-test
│   └── Subaccount: sales-production
└── Directory: IT Services
    ├── Subaccount: shared-services-dev
    ├── Subaccount: shared-services-test
    └── Subaccount: shared-services-prod

Benefits:

  • Clear functional separation
  • Independent entitlement management per directory
  • Easy cost allocation by department

Template 2: Directories Per Location

Global Account
├── Directory: Europe
│   ├── Labels: Region=EU, Compliance=GDPR
│   ├── Subaccount: eu-development (Frankfurt)
│   ├── Subaccount: eu-test (Frankfurt)
│   └── Subaccount: eu-production (Frankfurt)
├── Directory: North America
│   ├── Labels: Region=NA
│   ├── Subaccount: na-development (Virginia)
│   ├── Subaccount: na-test (Virginia)
│   └── Subaccount: na-production (Virginia)
└── Directory: APAC
    ├── Labels: Region=APAC
    ├── Subaccount: apac-development (Singapore)
    ├── Subaccount: apac-test (Singapore)
    └── Subaccount: apac-production (Singapore)

Benefits:

  • Regulatory compliance (data residency)
  • Performance optimization (proximity to users)
  • Regional legal requirements

Template 3: Directories Per Subsidiary

Global Account
├── Directory: ACME Corp
│   ├── Labels: CostCenter=CC001, Owner=John
│   └── Subaccounts: acme-dev, acme-test, acme-prod
├── Directory: ACME Manufacturing
│   ├── Labels: CostCenter=CC002, Owner=Jane
│   └── Subaccounts: acme-mfg-dev, acme-mfg-test, acme-mfg-prod
└── Directory: ACME Services
    ├── Labels: CostCenter=CC003, Owner=Bob
    └── Subaccounts: acme-svc-dev, acme-svc-test, acme-svc-prod

Benefits:

  • Clear subsidiary boundaries
  • Cost allocation to legal entities
  • Independent ownership and management

Simple Subaccount Model (Without Directories)

For initial implementations or smaller organizations:

Global Account
├── Subaccount: Development
│   ├── Labels: Stage=Dev, CostCenter=IT
│   └── Identity Provider: Corporate IdP
├── Subaccount: Test
│   ├── Labels: Stage=Test, CostCenter=IT
│   └── Identity Provider: Corporate IdP
└── Subaccount: Production
    ├── Labels: Stage=Prod, CostCenter=IT
    └── Identity Provider: Corporate IdP (hardened)

When to Use:

  • Less than 3 projects
  • Single team
  • Initial BTP adoption

Upgrade Path: Transition to directory model when exceeding 3 subaccounts.

Specialized Subaccount Patterns

Separate API Management Subaccounts

Global Account
├── Directory: Central IT Tools
│   ├── Subaccount: api-management-dev
│   ├── Subaccount: api-management-test
│   └── Subaccount: api-management-prod
├── Directory: Shared Data
│   ├── Subaccount: hana-dev-test (shared HANA Cloud)
│   └── Subaccount: hana-production
└── Directory: Projects
    ├── Subaccount: project-a-dev
    ├── Subaccount: project-a-test
    ├── Subaccount: project-a-prod
    └── ... (consume APIs via destinations)

Benefits:

  • Centralized API governance
  • Shared database costs
  • Rapid scaling with API-based connections

Large Project Separation

Global Account
├── Subaccount: development (standard)
├── Subaccount: test (standard)
├── Subaccount: production (standard)
└── Subaccount: project-x-all-stages
    └── (Completely separated support and operations model)

Use When:

  • Project requires isolated operations
  • Different SLA requirements
  • Separate support processes

Cloud Foundry Staging Details

Subaccount-Org Relationship

When Cloud Foundry is enabled, the system automatically creates a corresponding CF org with a 1:1 relationship:

Subaccount: hr-development
    └── CF Org: acme-hr-development (auto-created)
        ├── Space: recruiting
        ├── Space: payroll
        └── Space: benefits

Configuration Capabilities Comparison

Feature Subaccount Level Space Level
Business user groups Yes No
Cloud Connector tunnels Yes No
Roles and trust settings Yes No
Quota assignment Yes (mandatory) Yes (optional)

Data Segregation

Data access is controlled at subaccount level, not application or space level:

  • Services consume messages from ALL applications within a subaccount
  • Use separate subaccounts to restrict cross-application visibility
  • Spaces are for organization when dedicated user management isn't required

Kyma Staging Details

Subaccount-Cluster Relationship

Each subaccount provisions exactly one Kubernetes cluster:

Subaccount: platform-dev-test
    └── Kyma Cluster (auto-provisioned)
        ├── Namespace: hr-dev
        ├── Namespace: hr-test
        ├── Namespace: sales-dev
        └── Namespace: sales-test

Subaccount: platform-production
    └── Kyma Cluster
        ├── Namespace: hr
        └── Namespace: sales

Subaccounts vs Namespaces Decision Framework

Use Separate Subaccounts When:

  • Data access isolation required
  • Different network connectivity needs
  • Dedicated user management necessary
  • Separate billing/cost tracking required
  • Ingress traffic isolation needed

Use Namespaces When:

  • Structuring within cluster sufficient
  • Trust exists between teams
  • Cost efficiency priority
  • Development/testing environments

Configuration Comparison

Function Subaccount Namespace
User group configuration Yes Yes
Cloud Connector tunnel Yes No
Roles/trust setup Yes Yes
Resource quotas Yes (mandatory) Limited
Cost monitoring Yes No

Account Model Setup Checklist

Prerequisites

  • Review SAP Cloud Identity Services onboarding guide
  • Assess organizational needs for account model selection
  • Test hierarchy with pilot project managers
  • Familiarize teams with administration tools

Ownership Structure

Level Owner
Global Account Platform Engineering Team/CoE
Directories Designated owners with role collections
Subaccounts Designated owners with role collections
Spaces/Namespaces Development units

Directory Template Requirements

When creating new directories, document:

  • Name (following naming guidelines)
  • Minimum two owners
  • Description of developer audience and applications
  • Cost center allocation
  • Enrollment procedures

Rules to Define

  1. Directory creation criteria
  2. Naming conventions (see naming guide)
  3. Labels and values for reporting
  4. Quota limitations per directory/subaccount
  5. Entitlement distribution rules

Naming Convention Details

Character Restrictions

  • Use lowercase letters and hyphens
  • Avoid spaces and underscores (except subaccounts)
  • Maximum 63 characters for URL-related entities:
    • Subdomains
    • CF orgs and spaces
    • Kyma clusters and namespaces

Company Identification

Entity Include Company Name?
Subaccount name No
Subdomain Yes
CF Org Yes
Directory Depends on use case

Cloud Foundry Naming Example

Entity Dev Test Prod
Subaccount HR Development HR Test HR Production
Subdomain acme-hr-dev acme-hr-test acme-hr-prod
CF Org acme-hr-dev acme-hr-test acme-hr-prod
Space recruiting recruiting recruiting

Kyma Naming Example

Entity Dev/Test Prod
Subaccount Platform Dev Test Platform Production
Subdomain acme-platform-devtest acme-platform-prod
Cluster acme-platform-devtest acme-platform-prod
Namespace hr-dev, hr-test hr

SaaS Application Considerations

A SaaS application can only be used once within a subaccount. This necessitates:

  • Separate subaccounts per functional area using same SaaS
  • Or using CF spaces with HTML5 repository for central Fiori Launchpad

Source Documentation:

Reference in New Issue View Git Blame Copy Permalink