Three Main Areas in SAP Cloud Application Management
Central Cockpit or Service Provider Cockpit:
This ensures high automation, for example, tenant lifecycle management, maintenance and upgrade management, which provides high quality.
Application Management: Security Compliance:
This performs daily backups. An incremental log file backup is created on a regular basis during the day. There are automatic checks to see if a backup has been successfully executed. The system is automatically checked on a tenant level and overall.
System Security:
User access is highly restricted.
Access to SAP Cloud application management is only possible due to an incident occurring, either a system or customer incident. A support user has a limited access profile. A password is generated when it is required to solve an incident.
The activities of a support user are traced in a security audit log, which is stored for 200 days and provided to customers only if requested. There is no regular reading of entries.
Application Software Upgrades and Change Management
During staging, development is allowed to implement fixes and create required documentation. During development, functional, and performance scripts are run and a report is delivered after every change, which confirms there is no regression.
SAP Dev Pre-Prod is the landscape that is closest to the production version. Development tests the transport tool and other steps in this landscape.
Pre-production is treated as the first production system. SAP Cloud managed services apply the changes in the pre-production system. Any changes must be tested in the Quality Assurance (QA) landscape and approved by Quality Management (QM). This is followed by Pilot/Staging in the SAP Cloud. A request is sent as an internal ticket on the component <Application Component - MS>.
Change Management Process
The following are the main features of the change management process:
All the upgrades, support packages, and hot fixes follow the change management process. Support packages are a collection of one or more patches, and they are released according to a set schedule.
There is no customer specific downtime. A weekly patch or hot fixing cycle is performed, and all of the systems are maintained as the same code line, version, support package, and hot fix.
Functional and performance testing is performed to evaluate regression and performance issues before the change is moved into production.
The standard weekly hot fixing downtime maintenance windows are based on application activities.
Standard quarterly downtime windows are based on infrastructure activities and are communicated to the customer in advance.