Introduction
This is the second part of a two-part blog series. In part one of the blog, I addressed some open-ish points that come along with the SAP Embrace story and my answers on that for the topic of rehosting as the first step. However, the story does not end there. In this second part of the blog I will now walk through the other steps after the rehosting starting with the next logical step the refactoring of applications.
Step 2 - Refactor
The next step of the journey after rehosting usually is a refactoring of the rehosted application to leverage the advantages of the cloud via minimal changes.
Transferring this to the SAP S/4HANA monolith is hard. When it comes to the custom code, we will probably end up in the next section of rearchitecting the solution. Here SAP is a special snowflake. Having said that there is room for improvement that we can use. One major aspect that I would put in that area is the integration of Microsoft365 with your SAP system. This can make the live of the users easier and is usually not tied to big changes custom code-wise.
Valid questions here: Do I need SAP S/4HANA for such an integration? Do I need to rehost my SAP system for that? Answer to both is “No”. You can benefit from these options already today. The necessary changes in the ABAP code are usually small so you will not boost your backlog of custom code adaption for SAP S/4HANA.
Finally, you should also think about options in the area of DevOps when combining SAP S/4HANA (and here I think about gCTS) and Azure DevOps. The following video gives you some first idea what is possible: Doing DevOps with SAP
So far, we have gathered the low hanging fruits. Where can we go next?
Step 3 - Rearchitect
The next stop on our journey is rearchitecting the application, i.e. splitting a monolithic application into services.
What does this mean in the context of an SAP application like SAP S/4HANA? Do we need to extract and reimplement all the custom code in Java or JavaScript or C#? No this is not the intention. But what does this step mean then? Let us pick up how we extended SAP systems in the past: Did you ever ask the question if the workload of an extension made sense on the SAP stack? Probably not, as extending the SAP system basically meant putting the extension into the SAP system. Things have changed. Since some years you have new options and therefore the basic questions when starting the rearchitecting of your SAP system are:
- Are there extensions that do not make sense in the SAP system itself?
- Do you have a measurable benefit when you rearchitect them e. g. can some processes be accelerated by doing so?
If you can answer both questions with yes, you have a piece of code that might be worth rearchitecting. However, I want to put some warning here: the cloud and its technological options are appealing, but do not go down the path of rearchitecting something for the sake of technology. The business values must be the driver of changes.
Another point to keep in mind is that the rearchitecting can mean a removal of load from your SAP system. Consequently, this can result in the chance to further optimize the sizing of your SAP system and this way reduce cost.
Again, rearchitecting does neither require a rehosting of your system nor do you need an SAP S/4HANA system to do this extraction of “misplaced” functionality.
So far so good: up to this point the basis for our discussion the history of the SAP system that grew over years and how to deal with it. What about new investments leading to new development?
Step 4 - Rebuild
This leads our journey to the rebuilding of software.
Usually a lot of dogmatic discussion comes up now and you might often read that you should build everything in a cloud native manner as microservices and so on. I do not agree with that. From my point of view, look at the problem/requirement and use the solution that solves it best under the given constraints (easier said than done, I know). In the SAP area there are a lot of scenarios that make no sense to be built as an extension in the cloud (aka side-by-side extension). They are strongly coupled to a core process in the SAP system, so implement them where they belong namely in the SAP system as an ABAP extension.
On the other hand, do not blindly put everything into your SAP system because this was the way it was done for the last years/decades. Know the toolbox that comes along with Microsoft Azure (and the SAP Cloud Platform like the ABAP runtime “Steampunk” or the Extension Factory) and find the fitting solution. The driver must always be the value delivered to business and the customer. This can result in a serverless application on Microsoft Azure or maybe in a good old piece of ABAP custom code or maybe something in between like a piece of ABAP code that makes use of a Microsoft Azure Service. Be pragmatic and do whatever adds value, has a decent cost/value ratio and is sustainable.
Building such extension is usually possible with the system you use today, so as in the other steps of the journey no need to wait for SAP S/4HANA and no need to rehost your environment.
Another Aspect: Innovation
One central point that accompanies the SAP Embrace storyline with Microsoft is “Innovation” and I did not address that up to now. To make one thing clear: just using Microsoft Azure will not automatically make you innovative. However, this will put you in a good starting position. Combining your SAP system with the options of Microsoft Azure gives you a solid ground to start developing innovative enhancements and solutions. That’s it.
The hard part is finding the innovation itself. This does not come for free. To master this undertaking, I would highly recommend getting support from the outside. There a lot of companies that help you with the process from the first ideation workshop to the prototypes and in the best case to the development and rollout of the solution. Innovations are not different to other changes in your system or your organization, so start small, act fast and grow over time to succeed in the long run.
Here I see a big chance for SAP and Microsoft partners who can cover the complete range of an innovation process and can deliver this in an attractive bundle to customers. This way the innovation part of SAP Embrace can be filled with life.
Summary
Wrapping things up: from my perspective SAP Embrace is a great initiative by SAP and Microsoft at the right time with the right goals. As usual the marketing message is a bit fluffy so it must be filled with life. It is important to understand that the concept behind it is not a one-stop shop, but it comprises a journey as sketched in this blog series. I would say that the journey is worth it and serves as a solid ground for future solutions at customers.
Another point to consider is to take a step back and look at the SAP Embrace picture as whole. Only then the full benefit of SAP Embrace can be leveraged. This means not only look at the costs of a rehosting, but also put the options and the different modus operandi into the calculation. Otherwise you might miss a chance. Also keep in mind that the different points on the journey interact, so rearchitecting parts of your solution might have a positive impact on the rehosted part.
Microsoft clearly recognized the reality of a hybrid landscape which is reflected by the services offered by Microsoft Azure. I think that is a huge benefit and enables a lot more scenarios than a pure “cloud-only” mindset.
SAP Embrace might leave you with the impression that you need SAP S/4HANA to make things real and my clear answer is to that is “No”. You already have the options at hand today on your Business Suite to refactor, rearchitect or rebuild your custom solutions. The results gather under the category of side-by-side extensibility, so your investment is safe when you make the move to SAP S/4HANA.
- SAP Managed Tags:
