As more organizations turn to automation and AIOps, Avantra's very own Tyler Constable breaks down a few technical examples that will help keep the business and finance offices happy, as well.
Automation has come a long way in the past year and half in the SAP world. For many, SAP automation implies the act of keeping the business up and running in the most effective way with little to no downtime using SAP AIOps. Others are starting to take notice of these capabilities and utilizing them for cost saving operations as well. Some don’t know where or how to get started with automation in their SAP environment. At this time, the amount of cost savings from SAP automation are generally realized in one of three ways:
- Integrating with a public cloud and hosting the SAP landscape in the cloud instead of on-premise
- Resolutions that are automatically identified and proactively triggered to alleviate downtime
- Kernel updates to ensure the system saves time and money by always being fully patched and secured
Of the four major IaaS public cloud providers in the SAP industry - Alibaba, AWS, Azure & Google Cloud - each have their own way of charging their customers and giving credits. While it really comes down to the agreement each organization has with their IaaS cloud provider, many organizations can take advantage of how these solutions can be scaled to save money.
Below are the top two ways we see organizations using automation to save on their cloud costs:
- Stop SAP systems and public cloud servers when they are not needed. The most common example is shutting down specific non-production systems over the weekend or at night when they are not needed. This is common in large systems spread over many, many application servers where the amount of those app servers can be reduced in non-primary work load times, such as night and weekends.
- AutoScaling SAP systems. While each of the public clouds can automatically scale up the operating systems resources (such as CPU and memory), the ability to scale out a SAP system requires further automation capabilities. This type of scaling comes in handy when SAP based performance metrics start to lag. Perhaps there aren’t enough SAP resources, such as the amount of dialog work processes at the SAP application layer, which will cause major performance problems. In this case we’d want to bring up additional application servers which have been pre-built but set to ‘sleep’, including the public cloud operating system, and shutdown. This means the SAP system can run on minimal cloud resources and only bring up (and start being fully charged) for those additional resources when needed. This comes in handy during periodic times of peak workloads, such as month end closing.
Moving up the technical stack, beyond the public cloud servers, one starts to review the SAP environment. It’s important to realize that SAP environments are constructed not only of SAP systems, but a web of third party solutions, interfaces, SaaS solutions (think Ariba, Successfactors, Concur, etc…) and stand alone DBs, etc. By having visibility into each of these areas, and perhaps going as far as mapping them out in a business service to see how they impact each other, is the foundation of identifying issues and triggering a resolution before issues become problems. A small, simple issue may easily get overlooked, but end up having a domino effect causing major - and potentially very expensive - business issues. Think of lag times, which slow down processes, and interrupts business continuity, with potential to snowball into full SAP outages that could cost millions of dollars.
It’s important to have an understanding of how each of these components behaves and have a predefined resolution that can be automatically triggered to resolve issues in their early stages. This could be done via script, raising an ABAP event, or API.
Below are the top 5 ways organizations are automating resolutions via monitoring triggers:
- Recognizing an external interface, such as a banks interface, is unavailable and triggering a generic ping to re-establish communication
- Identifying an interface to an internal system is not working and resolving via script
- Detecting that a SAP ABAP batch job failed and re-triggering it to run via ABAP event
- Stopping a backup that has started running during high workload times and is causing major performance issues
- Clearing a list of known ‘junk’ files that may be filling up an operating system directory, threatening to bring down the entire system
Lastly, the SAP kernel is the nucleus of a SAP system and for that fact SAP regularly releases SAP kernel patches. Without an up to date kernel, the system could be exposed to security vulnerabilities and performance issues, which have dire financial implications that are self explanatory. However, it’s important to note there are operational costs - that eventually turn to financial costs - of constantly updating the SAP kernel. By automating the kernel update process, one can save major headaches for both the technical and financial teams.
Below are the top 3 operational (and downline financial) costs of automating the kernel update process:
- Paying an off-hour consultant/employee fees to run the kernel update - because the system restart step of the kernel is typically done after hours
- Taking team members away from more important tasks while they manually update kernels across large environments
- Human error in implementing incorrect kernels or not knowing the role-back procedure
As automation becomes more adopted in organizations, additional ways of automating for cost savings are constantly being identified and implemented. What are some of the ways your organization has automated SAP for cost savings, or perhaps, what are some things you wish you could automate to help save costs?
SAP Systems Monitoring in Focus - The Story of Scheer Group
SAP cloud integration | Avantra
Deciding between SAP cloud integration methods can be confusing. There are so many options out...
SAP AWS Hybrid
SAP AWS hybrid cloud is a mixed environment consisting of a combination of on-premises...