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
Other SAP Technical Community Articles
I blog this article to share information that is intended as a general resource and personal insights. Errors or omissions are not intentional. Products and services mentioned in this article are not endorsements. Opinions are my own and not the views of my employers (past, present or future) or any organization that I may be affiliated with. Your comments to my posts are your views. Content from third party websites, SAP and other sources reproduced in accordance with Creative Commons Attribution or Fair Use criticism, comment, news reporting, teaching, scholarship, and research.