In this blog post, I would like to share with you some of the thinking behind Gekkobrain DevOps for SAP and how the exciting new features in release 1.5 will help you on your journey to build an agile SAP development process. With our tools, we are moving the needle on what’s currently possible in an SAP team.
Gekkobrain DevOps for SAP is all about getting to a faster SAP development cycle, higher custom code quality and introducing DevOps disciplines in your SAP team. How do we do that? We give you real-time insight into performance of custom code, early issue detection, and super-fast root cause establishment with all dependencies.
Automated HANA analysis and code remediation built-in
Some of the feedback we’re getting is that our clients find it easy to migrate to Suite on HANA using our software, which in the full package includes our Gekkobrain for SAP HANA code analysis and remediation tool. The level of automation which our team have achieved is staggering. So far, our record is 3 days’ Suite on HANA migration time from start to finish converting all priority 1 issues (mandatory) and also taking care of most priority 2 (performance).
Furthermore, most of customers are analysing, measuring and even fixing their ABAP code getting it proofed for HANA long before they migrate and some of them re-run the Gekkobrain HANA code remediation tool because the code which is going to production is often times full of the performance degrading SELECT * statements.
Our vision is to have the Gekkobrain code remediation tool become an integral part of the development process, optimizing code and database statements on the fly, not only for HANA issues but optimizing the code in any respect.
So much for the Gekkobrain code remediation tool. Let’s talk about automation and DevOps.
Any HANA issues are spotted immediately and most can be corrected automatically by Gekkobrain.
Automating development tasks with DevOps for SAP
Understanding automation and how it can help you is nothing new to the SAP department.
Code automation for ABAP is what ABAP was – and is – for your business data.
One of the primary reasons why SAP became so popular was that the automation framework was very robust. And while the business scenarios supported by SAP were still very well defined, the effort required to maintain existing solutions was high, but not too high.
This has changed and now ABAP requires a lot of effort.The IT departments need to solve an increasing number of tasks with an increasing number of data-points. Data is everywhere now. Very large amounts of data. And more sources are added every year. Businesses that are moving to SAP are also different. Their markets, partners, solutions and products change so many times a year that the time the IT department has to adapt SAP to accommodate is much smaller.
This could be summed up in 2 paradigms:
- The backend team solved problems really well for a relatively small amount of users on a slowly increasing or almost constant amount of data.
- The backend team is bombarded with business requirement with varying use patterns coming from mobility based use patterns, interface based, good old backend automation patterns and then the crystal ball solutions for the changing world.
What are crystal ball scenarios you ask? Customers are exploring data now. They are measuring their customers and products using IoT. They are trying out various new SaaS solution to manage stock, human resource, customer sentiment, product lifecycle. All of which hopefully leads to a competitive edge.
And all of which are loading up custom code and traffic in your SAP system.
On top if this, your ERP system is going to be upgraded and all the custom code you have needs to be revisited. No matter if you are an S4 journey or Suite on HANA you need to do this. So… is this a perfect storm scenario or not?
Well. Let’s revisit the sentence above. Code automation for ABAP is what ABAP was– and is – for your business Data.
Automated Problem Detection
The reason why DevOps was invented by Google as Service Reliability Engineering was simple enough. Google maintains solution with millions of users and reliability is key; consider Gmail being down worldwide because someone changed a generic library function.
Blame free post mortem – a discipline practiced by Google Engineering teams are a token of a culture were the answer to a software mistake is NOT to write less code, but to quickly refactor and redeploy.
This is the new SAP IT department. You are pretty much live all the time and you have to sleep some times. So, let’s automate problem detection in SAP.
Because without early detection of code performance issues you risk that the big data algorithms and automation programs you deploy in production are so complicated, that you won’t be able to mitigate the risk.
It all comes down to knowing why your system is slower or why a webservice is hanging and first and foremost it comes down to knowing the risks changing a specific piece of code will carry.
Gekkobrain DevOps for SAP monitors your code. It spots code that is widely used in your system and responsible for slowing down core transactions. We detect patterns in the way that your ABAP runs in production and we map this against your business cycle for you to understand when a code change will hurt the fewest number of users. That’s right. We show you which days of the month is best suited for a patch.
From the trenches 1 – External developer saves the day
Consider this scenario from one of our clients. They hired an expensive consultant to fix some complicated code (Gekkobrain DevOps for SAP can measure how complicated it is, by the way). The code involved large SQL statements, calls to standard BAPI’s and also a few enhancements to central functions, because our client has a policy to not copy code because it is safer than to alter the existing solution. With the actionable insights Gekkobrain DevOps for SAP provides to the code, the new consultant knew from the offset how the code performed right now in production. He knew the complete “medical record” of that code and any code, which this code calls. He knew how the code had performed historically and he was able to identify unusual peaks in memory use and correlate that with the functional requirements, he was given by the functional consultant.
He was able to see that this code is sometimes run in batch. Not directly, but further away in the call-stack. In this specific case, he noticed an unusually high number of dumps, which turned out to be because a batch function sends a screen to prompt the user for input. These types of problems can be difficult to spot, especially if they are interfaces with missing values. The list goes on and on. The point is: this information was available to the external consultant before he even started developing.
With Gekkobrain DevOps for SAP, this works even for new development, which have never been in production that make use of code which is already in production (and almost all new ABAP is in that category). It is a huge benefit knowing how big of a call-stack to expect by using certain pieces of code and as we gather SQLM data, the developer can even put break points in those deep stacks to see if his code will have similar problems as the code has in production.
Gekkobrain analysis cross dependencies between programs, allowing the developer to quickly see, where problems occur: Is it in my program? Is it in a program, I call? Or is it in a program calling my program?
From the trenches 2 – Custom-built solution running wild
Another example: A client have hired an external vendor to develop a custom solution for them. Suddenly they had 5 new developers on their system, and it was agreed that any issues arising during burn-in would be handled directly by them. with Gekkobrain DevOps for SAP our client could measure if the code performed as required. The code didn’t add code in their standard transactions but it was calling a lot of BAPIs and it started running an unusually high number of updates on some very large transaction tables. Gekkobrain DevOps for SAP detected this right away. And as part of the handover, this mistake was quickly resolved before it was rolled out. Had that happened, the number of users was so high, that our client would have been facing serious memory issues on their application cluster.
Gekkobrain DevOps constantly keeps track of SAP performance and the relevant users will be notified if any issues occur.
From the trenches 3 – Problems detected before disaster
Here’s a final example from a client. No new code had been introduced in the area, but suddenly our tool detected a performance degradation in a central transaction. Our client realised that the usage pattern had changed. Traffic on an interface had increased dramatically. They had memory enough to withstand another 2 months of growing requests, but Gekkobrain DevOps for SAP detected the accident before it happened and even showed the root cause. All components currently under development which touched this solution were alerted to the increase in use and refactoring could immediately be incorporated as part of the new release.
Gekkobrain DevOps keeps track of a myriad of data sources and quickly visualizes the findings, so developers or the ops team can quickly troubleshoot SAP performance problems and through root cause analysis come up with a solution.
You might say that Gekkobrain DevOps for SAP finds ALL the needles in the haystack for you without you having to land on one of them.