1. Introduction

Many global companies today are using SAP ERP as their central enterprise resource planning system. Often these companies leverage a globally dispersed implementation of SAP applications: each major region runs their own SAP estate to support their individual business processes.

Recently, more and more companies are implementing SAP S/4HANA and in that context, they evaluate to move from a globally dispersed model of SAP to a single global instance to support standardized global business practices

This document does not address the challenges that are associated with transforming your business into a centralized operation.

This point of view document aims to provide guidance on best practice architectures for running SAP Applications in a consolidated Single Global Instance on Azure.

It focuses on how cloud technology can address some of the technical complexities that arise in central, global IT estates highly centered around SAP. Our ambitions are:

• to create the best user experience possible across all regions
• to ensure that all business processes that rely on interfaces can execute appropriately
• to keep network latency low at any time for every user/interface no matter where the user/interface geographically resides.

We will look at which factors can help define a Global Network Strategy, and express the significance of choosing the best Azure Region for your single global SAP Instance and conclude with how Microsoft technologies simplify the global platform for centralized businesses.

2. SAP on Azure Region Strategy

Some questions that arise, when customers plan to deploy a single global SAP Instance, are not always that straight forward to answer:

• Where, geographically, are the majority of my users?
• Which Azure regions provide the technology that I need?
• Are there any legislative requirements or policies that define where my data is kept, and or where users are allowed to access it from?
• What connectivity patterns can be established across the globe to support my userbase?
• What is the best UI or Front-end Strategy for global businesses that run on SAP?

2.1 Geographies and Regions

When Microsoft plans new data centers they start with geographies. Like the world map, Microsoft refers to the following geos: The Americas, Europe, Asia Pacific and the Middle East and Africa.

An Azure geography ensures that data residency, sovereignty, compliance, and resiliency requirements are honored.

Within a geography there are at least two regions, usually paired within a specific geo-political boundary, that typically maps to country specifics.

Paired regions have built in replication capability to safeguard your applications against complete metropolitan level failures.

2.2 Evaluation criteria

Choosing the most suitable Azure Region for a Single Global SAP instance is a daunting task, but the following evaluation criteria can inform your strategy.

2.2.1 Data Residency and Security

One of the most challenging technical design decisions for global SAP instances, is choosing a region that satisfies Data Residency and Data Security policies.

2.2.2 Business Continuity

Azure offers true regional disaster recovery. Choice or regions also depend on the resiliency solution customers prefer within a region. Customers can choose to deploy in the standard regional fashion, utilizing Azure Availability sets at a 99.95% uptime SLA, or they could deploy SAP workloads across availability zones within a region. Zonal deployment increases the uptime SLA of the virtual machine to 99.99%.

2.2.3 Network Connectivity

SAP Applications are latency sensitive. They also require sufficient bandwidth and throughput to operate at peak performance levels. This holds true, not only for end-user connectivity, but also integrations between a global single instances and other SAP or non-SAP systems.

2.2.4 SAP Certified Building Blocks

Azure supports a plethora of SAP HANA Certified cloud infrastructure and technologies, that can be obtained on the official SAP HANA Hardware Directory. AnyDB (or SAP Netweaver) Certification is published in SAP Note 1928533 – SAP Applications on Azure: Supported Products and Azure VM types

Azure does not offer SAP supported services in every region. To facilitate planning of your Azure deployment, and formulation of your Azure region strategy, you can always refer to the official documentation listing products be region here.

2.2.5 Business Model

As customers evolve to centralize more of their business processes, it becomes important to start formulating a Azure Region Strategy to align to your business model.

2.2.6 Cost of Ownership

There are differences to the cost of running of SAP on Azure deployment, depending on which geography or region you deploy to.

To assist in quantifying your Azure TCO, refer to the public Azure Pricing Calculator.

2.3 Example High Level Region Strategy

Contoso Ltd is a fictional company that is planning to centralize all Finance Operations in a new single instance deployment of SAP S/4HANA.  They are operating across the globe. Their data sovereignty and security policies dictate that they data cannot be stored in Asia.

Contoso requires True Regional DR, whilst minimizing Cloud Infrastructure costs. Their S/4HANA Sizing suggest a HANA requirement of 2.8TB.

This requirement can easily be served by the Azure M-Series virtual machine. Their Front-end Strategy is to minimize the dependence on SAPGUI.

After comparing a handful of regions, they have decided to define their Primary region as US-WEST (with M-series VMs generally available). Their Secondary Region has M-Series Virtual machines on the imminent roadmap. This matches their project timelines for DR testing and go-live.

3. Global Network Strategy

3.1 Guiding principles

Defining connectivity to and from Single Global SAP Instances does not have to be rocket science. If we understand the guiding principles for architecting network connectivity in SAP solutions, and instill a good practice of defining sizing requirements, then a high level global network strategy can be formulated with ease.

3.1.1 Latency

Various factors influence our network and region strategy. Most notable Latency. Although there is no official hard stance on user to system latencies, This SCN Wiki page contains good guiding principles. When defining your strategy, aim to adhere to these latency guidelines:

3.1.2 Bandwidth and Throughput

Network requirements differ vastly, depending on the type of SAP activities performed.

As guiding principle, we should use the official SAP provided sizing guidelines for Front-end networks (available from https://www.sap.com/about/benchmark/sizing.sizing-guidelines.html)  and supplement this information with SAP Note 2240690 that contains SAP Fiori Specific guidance.

This task is intensive, make no mistake, but becomes a valuable input into any SAP Global Network strategy.

3.1.3 Interactivity of Traffic flows

Most SAP transactions are highly interactive, with dynamic programs, screens and UI’s generated in real time. As more and more customers move to web-based SAP front-ends, opportunities exist to accelerate user interaction with SAP systems, and by offering caching capabilities for static content.

When it comes to integration points, or message flows, consider ‘chatty’ applications that have a high frequency of integration invocations, alongside large data transfers, as an extension of your single application. Keep these together and as close to each other as possible.

Lastly, the closer to real-time integration your requirements, the lower the latency baselines should be.

4. Technologies that simplify a network strategy for a Single Global SAP Instance

Many Microsoft customers are already benefiting from running their Single Global SAP instance on Azure. The following table highlights some solutions already in use today.

4.1 Microsoft Global Network

The Microsoft Global Network facilitates true global reach of your applications across more than 60 regions, at speed and scale to meet even the toughest of application requirements.

Microsoft publishes inter-region latency statistics here. Using this information, customers can ‘triangulate’ the best azure region for a single global SAP instance based on our guiding principles of latency as discussed earlier.

There are various architectures that leverage the Azure backbone, this document briefly describes two options that customers can implement to get the best out of the Microsoft Network.

4.1.1 Global VNET Peering

Virtual Network Peering seamlessly connects Azure Virtual Networks (VNETS). Traffic between VNETS traverse the Microsoft network.

According to the SAP S/4HANA on Azure Reference Architecture, SAP solutions are typically deployed in a spoke VNET.This virtual network can be peered to any virtual network in any region, and in the process establishing optimal routes over the Azure backbone. This communication is private and not exposed to the internet.

4.1.2 Azure Virtual WAN

Azure Virtual WAN is a service that goes far beyond simply peering two virtual networks in Azure. It is a true global, highly secure and superfast networking solution with solutions for branch connectivity via ExpressRoute, S2S VPN or Point-to-Site VPNs.Incorporating Azure Virtual WAN into your Global Network Strategy for SAP will meet the requirements of a globally connected user base, from your regional head offices, through to branches, and even extend to mobile and remote workers.

Allowing high speed, low latency connections between Azure regions, risks of integrating SAP with other systems, regardless of location, can be mitigated

4.2 Content Delivery Networks

”A content delivery network, or content distribution network (CDN), is a geographically distributed network of proxy servers and their data centers. The goal is to provide high availability and performance by distributing the service spatially relative to end users.”

Source: https://en.wikipedia.org/wiki/Content_delivery_network

Azure CDN supports dynamic site acceleration, caching, geo-filtering and compression. Therefore, making it a viable CDN solution for a global SAP S/4HANA Instance, accessed via Fiori, where users get the benefit of local resources.

For more information, please refer to SAP Note 2526542 – How to load SAPUI5 files from CDN for performance improvements in Fiori and Standalone UI5 apps

4.3 Front-End Strategy: Windows Virtual Desktop

Although there are many factors to consider when defining your front-end strategy for a single global SAP Instance, one of the options have always been a remote desktop or terminal server type solution. However, these solutions do not always solve the challenges with latency to far remote offices.

In general, the argument is that with the remote desktop, in close proximity to the SAP Application, latency and throughput constraints are minimized. But they do bring other challenges.

Windows Virtual Desktop is a service that runs on Azure and allows rapid provisioning and easy administration of end-user compute environments. Communication between a Windows virtual desktop and an Azure VNET occurs over the Microsoft global network.

4.4 Azure AD Application Proxy

Azure AD Application Proxy is a feature of Azure AD that allows users to access applications running either on-premises or on Azure. It facilitates Secure SSO through Azure AD, and allows a web based SAP UI such as Fiori or the HTML GUI to be proxied securely and encrypted – thus increasing the reach of a single global instance.

5. Summary

Within this document we have touched upon a few topics that can help customers define the best Azure region for their SAP workloads, and also facilitate high speed, low latency connectivity topologies from remote offices to central SAP deployments as part of a Global Network Strategy.

As customers start to plot their journey to Single Global Instances on Azure, it is highly advised to deep dive into the SAP on Azure documentation

The SAP Workload on Azure Planning and Deployment Checklist can be used as a compass to navigate through the various phases of a customer’s Greenfield implementation or migration of SAP to Azure.