The Future of SAP Operations: Audience Q&A

Brenton O’Callaghan, Head of Customer Experience at Syslink Xandria, asks John Appleby, Chief Revenue Officer, follow-up questions, provided by the audience, after November's Future of SAP Operations webinar.

Read the highlights of the conversation below. 

Prefer to watch the discussion instead? View the full follow-up video here. 

John, I see you attended the Solution Manager Summit by ASUG in Philadelphia. What were your key takeaways from that event?

It was back in 2001 when SAP got started with what has now become known as DevOps, and they were kind of head of their time in their thinking of sort of how to create system management that focused on an overall solution landscape from design, build and run.  The event sort of reflected on that: the18 years of DevOps, and how the market has moved on, but SAP hasn’t. Especially as it relates to the core, on-premise apps. Basically, SAP needs to modernize what they do around DevOps. 

You recently posted an article about the four levels of SAP DevOps maturity. Without spoiling the post for those who want to read it, can you please talk about the levels of maturity?

As an SAP customer, you likely have many fires to deal with. In my experience, customers are running from one problem to the other, finding solutions as they pop up. 

I call that reactive mode. In my opinion, most SAP customers don’t get past the reactive mode, and into the more optimal, following stages, proactive, automatic and self-healing.

If you’re in reactive mode, you won’t be able to recognize, for example, that a security vulnerability patch was released. Healthy organizations should be able to recognize a security event has occurred, identify if there is a fix available, download the fix immediately (but this can be configurable), automatically push the fix out to all the dev environments and sandboxes, and then kick off the sanity checks and the regression checks.

This process should all be automated and go through a workflow. That workflow should then go through managerial and technical approval, and then the fix should be scheduled and automatically updated. That is what I would call the proactive, semi-automatic self-healing process. 

I met companies that patch their Kernel once a year - which means they are constantly exposed to known, published risks.

Companies need to think about how to get out of reactive and into a proactive mentality so we can invest in automation and self-healing. 

Read John’s full post on the four levels of SAP DevOps maturity here >>

We can all agree that there's a gap between the reality of today and the future of DevOps. How does that gap impact businesses from a profit and loss perspective both directly and indirectly?

The most direct example is this: I talk to customers that have far too many SAP operations people employed to keep their business machine running. 

That is a very poor use of extremely experienced resources and a significant hit on direct costs. These additional employees aren’t unqualified people here. Most have graduate degrees and 5-10 years of experience in the industry, which come with high expenses.

I’m not saying to get rid of these people, but you can deploy them so much more effectively by creating automation to make the business run more effectively. Then, you can decrease the busy work from experienced people and increase innovation and problem-solving tasks that help grow a business. 

For indirect costs, think about the times when issues that take systems down and disable equipment from coming off the manufacturing line. That is literally business lost. And, in 2019, with the tools available to automate operations for SAP, there is absolutely no reason that should be happening. 

If you can get ahead of those outages then you will notice the indirect cost benefits as well. 

Do you think a culture of DevOps can be implemented in a company that focuses and relies on waterfall methodologies to build the business?

I don’t view DevOps as being attached to any particular methodology, so yes, it can be. 

Let’s say I want to build out a set of sandbox systems, and I implemented some tool which does post-copy automation, and also makes system copies. Now I might say, I want these production systems, and I want them copied into a particular place to create sandboxes. That’s pretty much a waterfall process. You’ve got a beginning and a set of steps in between. 

Now, how can DevOps improve and automate the process? Well, it improves the speed, reduces the number of labor hours, deletes some production data or anonymizes some data, and completes some testing. 

So, that’s one way DevOps can work in a waterfall methodology. 

How important are the right infrastructure and tools for implementing effective SAP DevOps?

Very. And, not at all — all at the same time.

There are distinct benefits of using the hyperscales for example. You don’t need to acquire machinery to set up new systems.  

For example, I can type on GCP interface a command line. It’s a long command, but it will create the system that I wanted with the availability , security and network settings I wanted, and will bring it up. And, this will all work in 10 minutes. So, you know, there are distinct advantages of that from a DevOp perspective.

But on the other hand, if you’re a VMware customer, you get a chunk of that benefit. You don’t have the elasticity you have from a hyperscale, but you can certainly apply the same DevOps systems scenarios to set up VM systems. Like, if you have a VMware Farm you can have the elasticity that probably meets your requirements. Ironically, the same logic can be applied to big hardwares like IBM P-series, you set up large capacity and you can automate creating virtual logical machines in that context. So, the world of hyperscalers provides elasticity you didn’t have before, but if you already have all the infrastructure and want to keep using it, you can still get some of the benefits 

Do you see the SAP Cloud Platform playing a role in the future of SAP DevOps for on-premise customers?

My personal opinion is that the cloud platform needs to be containerized on-prem. And, they built it in a containerized way. So, [SAP] thought about it when designing it (PI has cPI the cloud version of PI for example). 

I think that SAP will have to transition into that as the primary enterprise service bus.

A good example is NetWeaver PI that is based on NetWeaver 7.5 JAVA which will be end-of-life at the end of 2024, the current SAP statement that there will be no extended maintenance, the logical strategy is to use the SAP Cloud Platform and make it available on-premises, so the customer can run cPI and they can transition from NetWeaver JAVA to NetWeaver PO (was called PI, and now I believe cPI).

The DevOps team now will have a hybrid cloud scenario which includes on-premise VM Kubernetic which they can then deploy on-demand - which is really exciting.

How can customers find the balance between business as usual in their DevOps maturity journey and innovation to drive business growth? 

As we already touched on before, you’ve got to get out of reactive mode. To do that, you must re-assign some of your team.Let’s say you have a team of 20, take two — 10% of the team — and re-assign their roles. Give them the responsibility to implement automation tools, and cut the tasks done by the other 18 teammates. 

This isn’t because you want to get rid of these people, but you’re employing a team that’s much too large to work only on repetitive activities. If you can, move the other 18 employees around to become responsible for other items like innovation. Prioritize the things that are necessary in terms of the volume of activities. 

Learn more about the future of SAP Operations in our webinar >>

How do you keep a lid on SAP Operations actual versus forecast spend, in an on-demand (potentially hybrid) cloud environment?

The simple answer is by doing it. The more difficult solution is, by watching the costs. 

You need somebody responsible for cost management in the cloud. If not, it is a lot like having an unlimited cell phone plan with a bunch of extra costs associated with it. Before you know it, you start racking up these extra costs, and your contract of $40 a month is all of a sudden $240.

You solve that by applying controls. Specifically for contracts, you must do two things: Negotiate discounts with your provider and decide which systems should be reserved systems. Actually, if you’ve got production systems, you should absolutely be using reserved instances. Those are typically 30-35% of the cost of an on-demand system.

If you got dev systems that are only needed 8-5 you can use automation to cleanly shut down systems when they are not needed, no need for reserve systems in this case, rather just bring those systems down.

Equally if you have systems that come up once a month like a payroll system - bring it up once a month - pay only for the amount of time you actually use it.

How do you pursue SAP DevOps principles in a vendor AMS environment?

The answer to this question depends on the culture of the company. But, when you have an AMS environment, you do retain a small internal team. Not everyone is outsourced.

With internal controls, you can:

• Implement tools that automate SLA reports
• Bring the tools to the table and tell the outsource company how and when to use them
  
  

Finally, any parting words before we close out?

I want to reinforce how much I’m shocked of how often I see and hear from our customers that they are  in this reactive mode of SAP operations. I estimate it’s over a billion-dollar industry with people doing repetitive work in the SAP eco-system. This is such a wrong way to spend money when there are real business problems to solve. 

My challenge to you is to ask how can you reduce the effort that doesn’t need to be done?

Watch the full Future of SAP Operations webinar here: