Stay Certified

The topic of governance along the day-to-day work with the SAP BTP is very important to avoid freely grown structures and setups across your company, which will become hard to manage over time. You need to define some rules and responsibilities for:

• Managing multiple SAP BTP contracts and Global Accounts,
• Define clear ownership of accounts, applications, and instances,
• Managing entitlements,
• Improved transparency on cost and usage,
• Address security risks from unsecured apps or accounts.

Traditionally, responsibilities have been divided across development teams, the operations team, and the support team, working in silos. This model may have worked in traditional on-premise landscapes, but it's not a good working model in a modern cloud environment. Therefore, we recommend establishing an agile operating model with a centralized platform engineering team and local cloud development teams.

A good collaboration and communication between the platform engineering team and the cloud development teams is crucial to have a good operating model. Let’s have a look at the different tasks and responsibilities:

For managing SAP BTP and its account structure it is recommended to distribute the ownership and responsibilities accordingly. Central topics and guidelines are defined by the Platform Engineering Team. If wanted, you can also establish a model with Account Owners managing parts of the account structure using so-called Directories. The cloud development teams are responsible for development projects and keeping their applications up and running.

To enable Joule for all SAP BTP cockpit users in a global account, the following steps must be performed by the global account administrator:

1. In the Account Explorer of the global account, choose Global Account Settings (gear wheel) in the upper right.
2. In the Global Account Settings window, choose Joule.
3. Check Accept the terms and conditions.
4. Switch Enable Joule to ON.
5. Choose Save.

As divers as services can be, is the provisioning and usage of services. Many services are only used inside the same subaccount, where they are provisioned. That leads to multiple service subscriptions and instances of the same service distributed in your SAP BTP account model – which is totally fine.

It is also possible to provision services centrally in one subaccount and share them between users and other subaccounts. For some services it is your decision how you want to use it in your account model. Others are explicitly designed as a shared service. These shared services can be distinguished into two categories:

Central Shared Service

The service is used centrally and accesses other subaccounts, their services, and their applications, to manage these or to provide a feature while accessing.

Instance Sharing

The service is accessed from other subaccounts, their services, and their applications, providing its resources and features to them.

Running services centrally increases cost efficiency, streamlines administration, and facilitates user access.

In the SAP BTP Administrator's Guide, SAP recommends providing shared services in subaccounts organized in a directory called "Shared Services". The number of shared subaccounts depends on your account model and on the services you use. For example, if you use services for operating other services in other subaccounts, an operations (Ops) subaccount is recommended.

Authorizations of applications are only available after the application has been subscribed (SaaS application) or deployed (custom application) to the Subaccount. Respectively, authorizations for reuse services are only available after at least one instance of the service has been created in the Subaccount. We can differentiate two different authorization models for the business users:

Traditional model: Authorization and Trust Management service

Most of the existing applications and services apply to the traditional model using the Authorization and Trust Management service to grant authorizations to users. This is the same model as used for account members. Applications and services include predefined roles and usually also predefined role collections. Some applications support instance-based authorizations for certain criteria (e.g. markets). They provide role templates which define possible restrictions. You can create custom roles based on them, specifying restrictions as needed. You can group roles across all applications and services in a Subaccount into custom role collections.

New model: SAP Cloud Identity services – Authorization Management (AMS)

The new strategic model going forward is using the Authorization Management service. It is natively integrated into SAP Cloud Identity services and has much more powerful capabilities for instance-based authorizations. Some first SaaS applications use it already, such as SAP Ariba Buying and SAP Green Ledger. You can also use it for your custom applications running on SAP BTP. The applications include predefined authorization policies that are available for immediate user assignments. Some applications support instance-based authorizations for certain criteria. They provide base policies which define possible restrictions. You create custom policies ("admin policies") based on them, specifying restrictions as needed.

Note

Currently, you assign policies to users and design custom policies directly in the Identity Directory of SAP Cloud Identity services and not using SAP BTP specific tools like SAP BTP cockpit. Assignment of policies to users requires user profiles to exist in the Identity Directory of SAP Cloud Identity services. You can still delegate user authentication to a corporate identity provider. Going forward, more and more scenarios across the SAP portfolio rely on the Identity Directory as central store for user profiles and as location to assign all kinds of authorizations to users.

The btp CLI has a command structure, which makes it really convenient to use. A command has to start with the keyword btp, which will call the executable file.

Next, you have to define an action, which could be a create, read, update, and delete (CRUD) operation to, for example, create a subaccount or remove a role collection. Then you need to specify which group or object the action should apply to. This is followed by the object or group's ID.

Finally, there's the option to provide additional parameters to perform more specific configurations, such as setting a password of an SAP HANA Cloud instance.

Prerequisites for administrating and configuring a global account:

• You have downloaded and extracted the btpCLI (see related information).
• You have a user and password for the global domain with the appropriate permissions.

Infrastructure as Code (IaC) enables you to automate infrastructure provisioning and management using code instead of manual actions. It helps ensure consistency, scalability, versioning, collaboration, and documentation of your infrastructure.

IaC uses a declarative approach. You define the desired state of the system, including what resources you need and any properties they should have. The IaC tool will take this target configuration and execute the necessary steps to match it.

Idempotency is another key concept. Rerunning a script should always result in the same configuration.

Key benefits of IaC:

• Automation: IaC lays the foundation to automate the provisioning and management of your infrastructure. Infrastructure can be created, modified, and destroyed programmatically, reducing the need for manual intervention and minimizing human error.
• Consistency: Using IaC, you can ensure that your infrastructure is consistently provisioned and configured across different environments, such as development, test, and production. This reduces configuration drift and improves reliability.
• Scalability: IaC allows you to roll out infrastructure in a scalable way. By defining infrastructure configurations in code, you can easily replicate and deploy infrastructure resources in a consistent and repeatable manner.
• Versioning and collaboration: IaC configurations should be stored in version control systems, allowing you to track changes over time and roll back to previous versions if needed. It also enables collaboration among team members, as multiple people can work on the same infrastructure codebase simultaneously.
• Documentation: IaC serves as a form of documentation, providing a clear and concise representation of the desired infrastructure state. It helps in understanding the infrastructure architecture and facilitates knowledge sharing within the team.

To allow your cloud applications to access a certain on-premise system on the intranet, you must specify this system in the Cloud Connector. The procedure is specific to the protocol that you're using for communication. The following protocols are supported:

• HTTP
• RFC
• LDAP
• TCP

In the following, the widely used HTTP protocol is covered as an example in more details. The figure shows the overall workflow to securely use the HTTP protocol.