The Bounce, the Trigger and Everything In-between - SAP Automation

In the past 18 months, the need for SAP operations automation grew. These 5 requirements are the ones we hear from most companies.

Over the last 18 months or so I’ve had the privilege of speaking with many different SAP technical people in all different verticals and different industries about SAP automation.  Initially, I was confronted with confused looks, laughter, and disbelief.  While automation like this is standard with most other software in the world, in the SAP ecosystem it seems to get classified in the same bucket as The Tooth Fairy and Santa Claus - it sounds awesome but it’ll never be real.  

But as different hosting, workflow and scripting capabilities are being offered, the industry has started to take notice and now the conversations are getting real.  Below are some of the hottest things our customers and prospects are looking to automate in their SAP technical management and operations. 

The Magnificent Cloud

It’s no secret that the SAP hosting and hardware game is rapidly changing.  Both small and large enterprises are starting to look to IaaS public cloud providers (Azure, AWS, Google Cloud, Alibaba) to host their entire organization’s workloads, including SAP.  These cloud providers offer hosting in a way that had not been available in the past.  Options to almost instantly spin up servers and easily manage multiple servers from a single spot have meant SAP technical architects are rethinking how they handle SAP server loads, HA, DR, etc…   And now the conversations are starting to revolve around how we can use these cloud automation features to enhance and automate the SAP landscape.  By recognizing resources are limited or that performance is deteriorating within SAP, the system should trigger additional application servers automatically or add more resources, etc. In addition, when cloud resources are in low utilization, you’d want to automatically shut down some instances and save money.  What was once stagnant based on hardware, becomes a fluid environment.

The Bounce

Starting and stopping an SAP system can be a big task.  While not technically complicated, it takes planning, patience, and an understanding of specific orders that these environments must come down in.  Since SAP systems are the backbone of most organizations, bouncing (stopping/starting) a system during working hours could have a large financial impact on the company.  As a result, most SAP technical engineers spend their nights and weekends completing these tasks. So a typical SAP maintenance window when managing a large SAP system will look like this:

• The team gets up at 2 am, joins the group conference call or chat, and they get to work. They stop each system (properly and in the right order of actions), and this takes them about 15 minutes of the 2-hour maintenance window. 
• They then perform the maintenance, followed by the team starting the system (again in the right order of actions), taking another 15 minutes or so.

The math on that? 30 minutes out of the two-hour window got wasted.. That’s a quarter of the small maintenance window! Plus a bunch of very tired basis engineers are also showing up to work the following day. 

We hear it all the time, the struggle is real. This was deemed as one of the most frustrating tasks in the SAP engineer’s set of responsibilities.  

The Eyes and Ears

While this question is not so much around automation itself, it comes up in EVERY automation conversation “How do I know if my automation is working?”.  I have a theory why this comes up so often, because we in the SAP industry are still leery of the word ‘automation’ and want to self verify it is indeed working.  And I’m OK with that, it totally makes sense.  This is where having good visibility into every aspect of your SAP (and non-SAP) environments becomes critical.  At first, that may mean dashboards that can easily be viewed during the process, and over time it might become a simple email alerting you that something in your environment occurred and an auto resolution was applied.  

The Trigger

Triggered based action or resolution... This is my personal favorite because when we get to this point with our customers, they are excited, we are excited and we begin to imagine all the possibilities they want to automate that are based on a single trigger or set of triggers.  We start to think about what are the most recurring issues in their environment, how it is typically resolved, and how we can script around that.  Whether it’s OS, DB, or even Java based script, a resolution is almost always there.  Then it’s just simply tying the resolution script to the triggering event and identifying if any notifications to the team are necessary.  Can you think of something like that in your landscape?  I would love to hear your thoughts about it in the comments or feel free to share to my Twitter account.

The Integration

While not all, the majority of the organizations we speak with are using ServiceNow for managing their IT service and support.  ServiceNow has an arsenal of amazing abilities.  Tying these capabilities into the SAP world slingshots you into an array of SAP automation capabilities; however, integration between ServiceNow and SAP has been troublesome.  

But what if it wasn’t?  Consider this example: a set of SAP health metrics, that when triggered into critical status alone don’t mean much, but together mean something bad is about to happen within SAP.  This set triggers an incident within ServiceNow.  ServiceNow recognizes the issues but also identifies that the SAP kernel was changed yesterday.  At this point it sends approval to two different employees asking for the system to be shut down, the kernel reversed back, and the SAP system then brought back up.  The approvals are retrieved and ServiceNow communicates with the automation platform to perform the tasks identified.  These are the scenarios that start to become possible and many companies are already deploying them.

Still sound crazy?

I guess now comes the question, does this still sound crazy?  Are these things actually achievable?  Well, I can assure you that these automations are 100% achievable - and available today.  It all comes down to the single solution that is watching the SAP environment, communicating with the public clouds and ServiceNow, providing operational transparency, and giving you the platform to map it all together with different scripting types.  This is Avantra, and this is just the beginning.