Quick Guide to SAP on Azure SLA and OLA
Alot of customer SAP Service Managers/Owners/Leaders in SAP CCoEA usually ask this question:
“What is Microsoft’s Service Level Agreement (SLA) to us for SAP on Azure?”
Well, I must say this is an important question to any SAP Service Owner that is going to run one of their most mission critical application workloads in Azure. And why this is important? Becuase it signifies the confidence and backing of a commitment from Microsoft Azure to its customers and partners in my opinion. After that, the follow-up question is:
“What does this Microsoft SLA mean to us, does it mean it encompasses everything SAP up to the application layer?”
The answer is nuanced and we will need to unpack the both questions in a way that is easy to consume and bring about clarity. Let us recall for a typical SAP Netweaver based S/4 HANA solution on Azure, it will be IaaS (Infrastructure as as Service). See below diagram:
Microsoft Azure will take care of the infrastructure layers ranging from the physical datacenter, network, hosts and up to hypervisor layer. However, this diagram does not really depict how a typical Service Management Model for SAP on Azure, and I would like to provide one here below at high-level :
Most important is to access the Microsoft SLA for Virtual Machines – last update July 2020.
Always goto the link above to get the latest, but here below is the snapshot as of today. Most importantly the SLAs are dependent on the architectural configurations made by the customer/partner in relation to the architecture design of your implementation for SAP on Azure:
- Azure Storage types for SAP workload
- Utilize Azure infrastructure VM restart to achieve “higher availability” of an SAP system
- SAP workload configurations with Azure Availability Zones
Any of the IaaS layers will be Microsoft responsibility and therefore be bounded by the SLA:
a) Cloud and DC Facility Management (physical datacenters – not disclosed
b) Network components (example, ExpressRoute Gateways, Load Balancers, etc)
c) Compute and Storage (VMs like Ev3, Mv1, Mv2 and various storage as above)
d) Cloud Service Fabric (Azure backplane, hypervisor and fabric controller)
Azure IaaS Layers a) to d) is the Microsoft SLA to your internal Azure Cloud Team that owns the Azure subscription.
So, in essence anything that is above these layers will belong to customer or managed application service providers. This includes OS, Database, Application Operations and Lifecycle Management activities (patching, upgrades and so forth)
IT Organization Responsiblity
- Cloud Platform Operations
- OS Platform Operations
- Database & Data Platform Operations
- Basis/Netweaver Operations
- Application Operations
- Application Development
Line of Business Responsibility
7. Business Process Operations
8. Organizational Process Management
Service Operation Layers 1 to 3 therefore are under customer responsibilty as part of the Operational Level Agreement (OLA) between SAP CCoEA and the Azure Cloud team
Service Operation Layers 4 to 6 is the OLA responsibility between SAP CCoEA and the Business Users on Layer 7, 8.
Remember that the Microsoft Azure SLA is not your OLA to your SAP end user, but is still an important underpinning construct for your OLA design.
If you are using a outside vendor (managed service provider for SAP Application Management Services for example), then it is likely the responsibility will change from the above diagram, and these outside vendor will give you a SLA (because you are considered a client or customer).
Read this great article that talks about the differences between OLA and SLA
“Service Level Agreements are external agreements between a service provider and a customer. They allow an organization to track performance and progress against commitments to the customer as defined in the SLAs. The agreement can consist of one or more service targets. Service targets can define penalties for noncompliance of an agreement or rewards for meeting and exceeding the specified goals.
Operational Level Agreements (also known as Operating Level Agreements) are internal agreements that a service provider defines for internal users to meet SLAs. OLAs can also contain one or more objectives or service targets. The OLAs would be used to track internal service commitments such as the following service targets:
- Response time for incidents or problems assigned to IT groups
- Availability of servers supporting various applications
Underpinning Contracts are agreements that are used to track performance between an external service provider and a vendor.
The main difference between OLAs and SLAs is that they represent different commitments. The SLA underscores a commitment to the client, while the OLA highlights the commitment to internal groups within the organization. In addition, the Operational-Level Agreement typically has a smaller target group compared to an SLA. And, the Operational-Level Agreement contains more detail on technical aspects of the problem.”
I hope this clarifies that both of these questions initially posed in the beginning of the article and give you a quick rundown of SLA and OLA of a typical SAP on Azure scenario.
Quick Guide/Reference Series
Quick Reference to SAP on Azure Components for HA and DR by Pankaj Kumar and Mary Chen
Quick Project Manager’s Guide to SAP on Azure
Other SAP Technical Community Articles
SAP Customer Center of Excellence for Azure
SAP Customer Center of Excellence for Azure: Govern, Design, Innovate & Build
SAP Center of Excellence for Azure: Sustain & Run
Microsoft Cloud Operating Model & SAP on Azure Migration Scenarios
SAP IT Service Operations Management on Azure
SAP Security Operations on Azure
SAP Expert Role Guide to Microsoft Azure Skills and Certification
Exam Study Resources for AZ-120 Planning and Administering Microsoft Azure for SAP Workloads.
Profile & Disclaimers here
Hello Chin Lai ,
Great post ! I think the point of SLAs in context of enterprise applications , including SAP ERP, running on Azure is not always understood . The multi-ownership model clearly defines which aspects of the architecture retain the customer responsibility .
The other thing is , even on the lower layers, the SLA for Azure services is not set in stone – it depends on the kind of redundancy and type (premium/standard) is chosen . By utilizing HA/DR and higher capacity of say VM/storage we can effectively increase the Service Levels in terms of availability .
Thanks for your comments and feedback.