zhongwei/gh-secondsky-sap-skills-skills-sap-btp-best-practices

Fork 0

Files

Zhongwei Li bd301d195d Initial commit

2025-11-30 08:54:47 +08:00

14 KiB

Raw Blame History

SAP BTP Governance and Teams - Detailed Reference

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

Governance Model Overview

Establishing an appropriate organizational setup and governance model is one of the first and most important steps in the cloud journey.

Benefits of Good Governance

Easier adoption of agile processes
Clear responsibilities and ownership
Streamlined onboarding for new projects
Consistent security and compliance
Efficient resource utilization

Preparatory Steps

Before launching development initiatives:

Establish an onboarding framework for new projects
Create a knowledge transfer system for teams

Governance Model Implementation Areas

Area	Key Activities
Organizational Structure	Team composition definitions, IT support positions, accountability assignments
Process Development	Integration pathways, knowledge sharing, operations documentation, tool selection
Resource & Change Management	Personnel scaling, process improvements, system tools, reference materials
Support Operations	Help desk workflows, incident management protocols, change management procedures

Reference: Team Topologies (teamtopologies.com) for organizational design patterns.

Team Structure

Required Teams

Platform Engineering Team (Center of Excellence)

Purpose: Manage cloud landscape infrastructure and reduce complexity for development teams.

Core Responsibilities:

Account operations and management
Build infrastructure setup
Governance and compliance guidelines
Security framework implementation
Enable developers with reduced cognitive load
Operate and ensure stable, secure cloud landscape

Extended CoE Functions:

Drive cloud adoption and migration organization-wide
Provide thought leadership and roadblock resolution guidance
Identify, evaluate, and implement SAP BTP use cases
Can include enabling teams composed of specialists

Does NOT Handle:

Individual application lifecycles
Application-specific development
Application-specific operations

Composition:

Skilled technology experts
Cloud architects
Security specialists
Infrastructure engineers
May include specialized sub-teams

Cloud Development Teams

Purpose: Develop and operate applications on SAP BTP.

Approach: DevOps model - same team both develops AND operates applications.

Responsibilities:

Application development
Application deployment
Application monitoring
Regular maintenance
Post-launch support
UI component compatibility verification (every 6 months)

Key Principle: Avoid traditional Build-Run separation where different teams handle development versus operations.

Essential Documentation

Three Core Documents

Document	Owner	Purpose
Onboarding Documentation	Platform Engineering	Guide new projects through enrollment
Security Guidelines	Platform Engineering + Security	Define security requirements and standards
Services Catalog	Platform Engineering	Provide templated services for developers

Onboarding Document Contents

Every new application should document:

Field	Description
Organization/Department	Business unit owning the application
Application Identifier	Unique identifier for tracking
Business Rationale	Why this application is needed
Go-Live Timeline	Target production date
Owner	Primary responsible person
Access Requirements	Who needs access and what level
User Accessibility Scope	Internal, external, specific groups
System Integration Details	Connected systems and interfaces
Technology Stack	Languages, frameworks, services
Repository Location	Keep outside SAP BTP to prevent accidental deletion
Testing Approach	Testing strategy and requirements

Security Document Contents

Requires security expert approval before development begins.

Field	Description
Owner Identification	Security-responsible person
Business Scenario	Use case and context
User Classifications	Types of users and roles
Data Sensitivity Levels	Classification of handled data
Policy Compliance	Applicable policies and standards
Data Flow	How data moves through system
Data Storage	Where and how data is stored
Connected Systems	External integrations
Protocols	Communication protocols used
Authentication Framework	Identity and authentication approach
Authorization Framework	Permissions and access control
Audit Procedures	Logging and audit requirements

Services Catalog Contents

Platform Engineering Team provides templated services:

Destination management
Build configuration
Application restart procedures
Access provisioning
Database schema creation
CI/CD pipeline templates
Monitoring setup

Automation Options:

SAP BTP APIs
btp CLI
SAP BTP Setup Automator

Knowledge Transfer Process

Key Practices

Document and Share: Platform Engineering Team documents and shares knowledge with current and incoming staff
Training Sessions: "Set up training and enablement sessions to get everyone on board"
Communication Channels: Create dedicated channels (e.g., SAP Build Work Zone) for:
- Lessons learned
- Guidance and recommendations
- Best practice sharing
- Q&A support

Knowledge Areas

Platform architecture and capabilities
Account model and structure
Security requirements and procedures
Development standards
Deployment processes
Operations procedures

Onboarding Process for Projects

Project Enrollment Steps

Submit Onboarding Document: Complete all required fields
Security Review: Security document approval
Resource Allocation: Assign subaccounts, quotas, entitlements
Access Provisioning: Set up team access rights
Integration Setup: Configure Cloud Connector, destinations
CI/CD Setup: Establish deployment pipelines
Monitoring Setup: Configure alerting and dashboards

Self-Service vs. Managed

Aspect	Self-Service	Managed
Speed	Faster	Slower
Control	Less	More
Suitable For	Low-risk, sandbox	Production, sensitive
Governance	Light	Full

Account Administration Tools

Available Options

Tool	Use Case	Automation
SAP BTP Cockpit	GUI administration	No
btp CLI	Terminal, scripting	Yes
REST APIs	Programmatic	Yes
Terraform Provider	Infrastructure as Code	Yes
SAP Automation Pilot	Low-code automation	Yes

btp CLI Overview

Alternative to cockpit for users who:

Prefer terminal work
Want to automate operations using scripts

Handles:

Global account management
Directory management
Subaccount management

Note: Environment-specific tools needed after environment creation:

cf CLI (Cloud Foundry)
Kyma CLI
kubectl (Kubernetes)

Terraform Provider

Purpose: Automate infrastructure provisioning using code (IaC).

Current Status: Available for non-productive environments; SAP developing for production use.

Repository: HashiCorp registry + SAP GitHub samples

Example:

resource "btp_subaccount" "my_subaccount" {
  name      = "my-dev-subaccount"
  subdomain = "my-company-dev"
  region    = "eu10"
}

resource "btp_subaccount_entitlement" "hana_cloud" {
  subaccount_id = btp_subaccount.my_subaccount.id
  service_name  = "hana-cloud"
  plan_name     = "hana"
}

Shared Responsibility Model

SAP Manages

Area	Responsibility
Infrastructure	Software updates, patches, maintenance
Monitoring	Infrastructure, OS, and service monitoring
Capacity	Capacity management and troubleshooting
Incidents	Incident management and resolution
Provisioning	Global account creation, resource provisioning
HANA Operations	Hardware, backup, recovery, security
Kyma System	`kyma-system` namespace management

Customer Manages

Area	Responsibility
Account Strategy	Global account and subaccount planning
Configuration	Subaccount configuration and setup
Development	Application development and security
Deployment	Application creation, deployment, management
Authorization	Role assignments for applications
Integration	System integration and connectivity
Monitoring	Application monitoring and health checks
Maintenance	Application updates and improvements
Security	OSS vulnerability scanning, updates
HANA Updates	Trigger revision updates via self-service

Additional Resources

SAP BTP Security Recommendations
Operating Model documentation

Cost Management Governance

Commercial Model Selection

Model	Best For
Consumption-Based	Pilots, flexibility, new workloads
Subscription-Based	Established use cases, known services

Contract Strategies

Consolidation: Combine subscriptions into one global account (reduces TCO)
Hybrid Accounts: Mix subscription and consumption-based
Separation: Multiple consumption contracts require separate global accounts

Note: Consumption credits non-transferable between global accounts.

Governance Practices

Minimal Entitlements: Provide only required set to prevent overage
Quota Management: Set appropriate limits per subaccount
Monthly Monitoring: Review costs and usage in cockpit
Label Usage: Enable filtering and cost allocation
Automated Alerts: Set up usage threshold notifications

Checklist: Account Model Setup

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	Recommended Owner
Global Account	Platform Engineering Team/CoE
Directories	Designated owners with role collections
Subaccounts	Designated owners with role collections
Spaces/Namespaces	Development units

Standards to Define

Directory creation template and process
Naming conventions
Labels and values for reporting
Quota limitation rules
Entitlement distribution rules

Directory Template Required Fields

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

Staged Development Environment

Standard Three-Subaccount Model

Subaccount	Purpose
Development	Cloud-based development, individual testing
Testing	Integration testing, production-like conditions
Production	Live applications

Flexibility Options

Combine development and testing
Create additional subaccounts for large backends
Maintain separate subaccounts for different projects

Reasons for Separate Subaccounts

Isolate different projects or scenarios
Separate team workflows
Control application access and administration
Share databases across similar projects
Host centralized shared services

Important Considerations

Consideration	Guidance
On-Premises Connections	Each subaccount needs separate integration setup
Geographic Selection	Choose regions near customers for latency
Regulatory Compliance	Segregate S/4HANA tenants when legally required
Team Structure	Separate DevOps teams warrant distinct subaccounts

Development Lifecycle

Phases

Explore: Identify business opportunity, set up team roles
Discover: Identify use cases, understand technology
Design: User experience design, domain-driven design
Deliver: Set up landscape, develop application
Run and Scale: Gather feedback, optimize, operate

Programming Models

SAP Cloud Application Programming Model (CAP):

Framework for enterprise-grade services
Supports Java, JavaScript, TypeScript
Domain-driven design approach

ABAP Cloud:

Modern ABAP for cloud
RAP (RESTful ABAP Programming Model)
Extensions for ABAP-based products

Source Documentation:

14 KiB Raw Blame History