Managing SAP on Azure with ALM

Managing SAP on Azure with ALM

SAP Customers are always looking for a lightweight, agile tool to manage their Multi-Product ERP landscape which may be a mixture of SAP , Integration Platforms, Custom Applications, SaaS vendors for different modules from billing to HR to logistics. They are always in the journey to perfect the process and one "toolset that rules them all"! Unfortunately, many customers , especially those with very large, diverse landscapes have come to a conclusion that there is no one platform that can do this and hence use a combination of tools for their Application Lifecycle Management(ALM) needs. Today I try to look at some possible use cases of a Cloudified SAP landscape and how to manage it.

Typically, what does a typical SAP ERP landscape have - SAP ERP of course (ECC/S4HANA), BW, SAP Cloud Platform , GRC, Business Objects and then of course systems connected to it . So we will have :

1. Cloud SAP products (Ariba, C4C, Success Factors) 

2.Integration Platforms (Mulesoft, SAP PO , TIBCO)

3. SaaS (Salesforce, Workday just to mention two popular ones)

4. IaaS - Custom Web and Mobile Applications on Cloud

5. Legacy Applications - either on cloud or on premise

This would have different integrations between them and different teams supporting them.

Let's assume the SAP and Non SAP components are deployed on Azure , quickly gaining traction as cloud platform of choice Ref:https://news.microsoft.com/2019/10/20/sap-partners-with-microsoft-for-first-in-market-cloud-migration-offerings/

These have the same lifecycle management needs that a traditional on premise landscape has but has more value from the functionality of the cloud

What does ALM really entail then ? A comprehensive (but definitely not exhaustive list) would be :

• Change and Release Management (Development via Agile or Waterfalls Models, Automatic Deployment/ CICD )
• Code Management
• Application Operations - Maintenance, Optimization, Right Sizing Servers and VM
• HA/DR
• Monitoring 
• IT Service Management (Incident, Problem, Service Request)
• Configuration Management
• Service Repository 
• Information Lifecycle Management (Data Volume Management)
• Software Lifecycle (Plan--->Build--->Deploy--->Maintain---> Upgrade ---> Decomission) 
• Infrastructure Design 
• Security and Compliance
• Test Management 
• Document Libraries 
• Integration to Digital Capabilities (IOT, ML, DevOps)

.I have added the last line item , not a traditional ALM capability. However in my book any modern ALM platform should be able to integrate seamlessly to these New Age features, bringing them right into the middle of business process . Rather them always remaining "pilot" and "experimental"

SAP Solution Manager 7.2 has always been position as SAP's platform of choice for ALM. It however is not tailored to make full usage of the cloud capabilities of Azure, AWS or GCP. While partially providing support for SAP's own cloud capabilities - even for basic monitoring it doesn't give the same value as it does for on premise systems - it has not tailored itself to integrate and utilize the native capabilities of Public Cloud . This I believe would be the next logical step in the SAP-Azure partnership. 

Capability	SAP	Microsoft Azure	Integration
Monitoring	Solman -Technical & Business Process Monitoring	Azure Monitoring	Yes - Azure Monitor can feed in metric data to SAP. No integrated dashboard
Change and Release Management , CICD	Solman - ChaRM ABAP Git	AzureDevOps GitHub Integration	No
Application Operations	LaMa  Solman - Guided Procedures	Azure Portal & CLI Resource Manager Multiple tools like Azure ScaleSets	LaMa connector
Software Lifecycle Management	Solman - LMDB  Service Marketplace	Azure Templates Resource Manager	No
HA/DR	Multiple options eg. ASCS, HANA DB	Multiple options including Zone Redundancy	No
Infrastructure Design	Solman - SolDoc, LMDB	Azure Blueprints	No
Security and Compliance	GRC, Solman - Configuration Mgmt	RDBC, Azure Policies	No

While it might be tempting to say, let the Infrastructure admins manage Azure , and the SAP Basis admins manager SAP , it leads to a seperate approach towards ALM . There is large overlap between infrastructure and application support and sometimes impossible to seperate the two concerns :

1. usage of applications and their measurements (think ST03N) leads to performancing tuning and drive re-sizing of VMs
2. Usage patterns and release cycle on SAP (monthly, quarterly) drive need for test VMs and usage cycles (think Test Servers on during UAT) 
3. Archiving using ILM Stores drives data reduction and future planning
4. For provisioning and Upgrading servers, we have two seperate process by different teams , with no connection and governance 
5. Load Balancing, High Availibility - these are the problems being solved by two sets of admins 
6. Spinning up servers/instances on demand - this was never possible in the on-premises world but Azure makes it easy 

From an IT management perspective , they would definitely prefer to have a small set of tools for the above tasks giving them a "Single Source of Truth" - Solman consultants have used this term too many times ! This toolset would be able to drive governance and give a high level visibility of this complex landscape . 

Let us take example of Service Repository , also known as Service Catalog .

Configuration Steps : https://wiki.scn.sap.com/wiki/display/SAPITSM/Service+Catalogue+Management

Introduction : https://support.sap.com/content/dam/support/en_us/library/ssp/alm/sap-solution-manager/container/it-service-management/ITSM_Overview_2019_L1_v4_MS%20(2).pdf

How could the Azure server provisioning and Re-Sizing (Scale Up/ Scale Out) be taken care from Service Request Mgmt ?

Basically , to have a true cloud , should be available on demand and elastic . The service request from the user , based on pre-defined parameters (in this case Azure VM sizes , number of VMs) will trigger either a manual request to Admin, who verifies, or an automated Azure Resource Manager(ARM) Template which will create the VM.

It will calculate the cost, and upon approval , trigger creation of VM and close the service request. The cost will be charged back to the business unit. Here we can use Azure Tags and match that to the Org structure in ITSM .

As you see, we are using the Service Capabilities, of Solman , to truly convert the capabilities of Azure Cloud and make it an on-demand service . The Fiori App of Service Request will be then the entry point for all users. How do we configure it ?

Service Order 
1. Create the categories
            a.Azure VM / AWS VM / GCP VM
            b. 2nd level-  based on type of system (ECC AnyDB/S4 HANA/BW ...)
            c.  3rd level - T Shirt Size (A5-D14. The drop down will be based on system chosen in level
             d. Type of Server - Prod/Test/Dev/Sandbox

2. The quantity of VMs to be specified.

3. Business Unit for chargeback - Sold to Party field can be used and this will be same as Azure Tag

4. Checklist for items

5. Approval workflow

6. Custom SAP Images of the company can be created an uploaded - this is done in Azure

The interesting part here would be to estimate the cost and show it to the user , I haven't explored this but maybe some APIs exist for this ? If not the admin who gets the request can actually check it via Azure . I have a great example for this from SAP Cloud Appliance Library 1. https://cal.sap.com/catalog#/solutions - shows all available SAP Images
2. Select one SAP Images lets say S/4 HANA 1909, and it shows details :https://cal.sap.com/catalog#/solutions/246a5ed1-7f26-4424-9c7c-61b7f7fc3eb7
3. Use the button Calculate Cost to get the estimates

This sounds like a very good idea for Data Centre hosting partners - who typically have 100s of customers supported in one data centre, to have a Fiori App to provision access . A less expensive option is to leverage ITSM's Service Request capability as outlined above. This can be used by individual companies .

https://calstatic.hana.ondemand.com/res/docEN/3236804b2d05445499ffc2e23c12c67a.html - this gives a great idea of SAP Cal integrates SAP Fiori App to AWS/Azure/GCP .

This creates a great "layer" on top of the cloud provides, say Azure, so the SAP administrator can simply use these Service Orders to provision VMs, Create new instances , or re-size VMs . The request at this layer runs a script/template at the cloud infrastructure layer .

Now, finally the simplest use case is for users to request access to Applications

Service Request

1. Choose the VM or Application
2. VM access - trigger script in Azure to provision RBAC rules update for user to get access to specified VM
3. Application access - if it's SAP trigger GRC Access Controls to provision access

From a configuration standpoint , all the VMs and Applications will be added as Ibase items .