gh-secondsky-sap-skills-skills-sap-btp-best-practices/references/account-models.md

# SAP BTP Account Models - Detailed Reference

**Source**: [https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan](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**:
- [https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/setting-up-your-account-model-2db81f4.md](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/setting-up-your-account-model-2db81f4.md)
- [https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/account-model-with-directories-and-subaccounts-b5a6b58.md](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/account-model-with-directories-and-subaccounts-b5a6b58.md)
- [https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/account-model-with-subaccounts-049d331.md](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/account-model-with-subaccounts-049d331.md)
- [https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/naming-conventions-for-sap-btp-accounts-5302ea4.md](https://github.com/SAP-docs/btp-best-practices-guide/blob/main/docs/set-up-and-plan/naming-conventions-for-sap-btp-accounts-5302ea4.md)