FinOps and SAP: Part 1. The “what” and “why”.

Welcome! After a longer period of silence, I decided to reactivate publishing on sapongcp.eu and this is actually first of a series of articles related to FinOps and how it relates to SAP. The reasoning for creating this series is pretty simple: based on what I see when working with enterprise customers, there is a lot of wastage… or potential (depending on how you look at it 😉) in optimising SAP workloads from financial perspective. By providing some guidance and high-level recommendations, I hope to contribute to a brighter tomorrow, where the public cloud (and GCP in particular) can really deliver what it’s supposed to: flexible and cost-optimal environment for running workloads, including the ones that are not necessarily cloud-native ones, such as SAP.

Since that may actually be one of the first places where the combination of words “SAP” and “FinOps” is used, let’s kick off by defining this mysterious term. FinOps is a new idea that was born around 2019, when the cloud, and – even more importantly – multi-cloud workloads became THE thing. That’s when a lot of companies started to lose track of their IT spending… Hence, a new “skill” emerged that was about understanding capex/opex revolution, controlling cloud costs and being able to make conscious financial decisions when planning, deploying and running cloud workloads.

FinOps quickly became a separate, full-blown specialization and started to evolve in different directions. Technically, it is now more of a people-oriented practice with an official FinOps Foundation than a system or process… After all, people are what make any organization rise or fall! So finally… what is FinOps? If I were to describe it with one sentence, I’d say: it’s mostly about optimizing DevOps from a financial perspective. 

Now that just made the thing so much more difficult, didn’t it? DevOps and SAP? C’mon… really? 🙂 Let me be brutally honest here: it’s not the easiest combination ever… but at the same time, not having a full-blown SAP-oriented DevOps practice doesn’t mean you have to give up and forget about all the possibilities to optimize the costs of running SAP systems. It just makes it a bit harder, maybe a bit less flexible… just more SAP-wise, if you will 😉. For most companies, SAP is not the only IT workload deployed to the public cloud, so FinOps will be a kind of an umbrella for different workloads and SAP will end up being a part of it. But it only gets a chance to become one if there is a common knowledge and understanding among different stakeholders (which – hopefully – you’ll gain after reading through this series of articles).

Since we know the “what”, let’s try to answer “why”. Here is my version of it: when implemented, FinOps ensures that spending gives business value.

For anyone working with SAP systems, it’s clear they’re one of the major elements driving IT costs. It’s also pretty clear that in most cases, they do deliver business value 😉. Since HANA (an in-memory database) has become the default choice for most SAP workloads, it’s increasingly important to be mindful about creating and running cloud-based resources. Why is that? Well, let’s assume you’re running a 1 TB HANA-based SAP system. When deployed to Google Cloud Platform, the HANA VM itself costs about… 

4.5k EUR a month (or over 50k a year) for 40 vCPUs, 1 TB memory and about 2.5 TB of SSD disks. This estimate includes ~30% Sustained Use Discount, which you receive automatically by running workloads for a longer period of each month. Now… you’ll need more of these, right? One for high availability, maybe another one in a different region for DR… and that’s just for a single, productive system, without application servers included yet. On top of that, you’ll surely deploy a QA and DEV system… and just maybe, a Sandbox one that may be needed from time to time. OK, I think you got my point: the costs add up quite quickly, and there is a pretty high probability that you’ll end up with multiple SAP landscapes, each being a similar combination of prod/qa/dev systems. This is exactly where FinOps comes into the equation. There is a huge difference between just accepting the current resource usage versus being mindful about controlling resource utilization and knowing what are your options to do so. 

The bottom line is: the bigger an enterprise is and the more it embraces public cloud, the more mindful it needs to be about cost optimization. It will not be an instant change, but along the way, fundamental changes to both mindset and behavior around existing financial management practices need to take place. In fact, the bigger the company is, the more it should crave FinOps! And even if one argues it’s just a new, fancy naming convention for a thing that should be obvious (which is: caring about your monthly bills), believe me: it’s not. 

What makes me think so? Well, I’ve seen way too many oversized on-premises HANA systems that only started to adequately utilize the allocated resources after around 5 years, when it was already the time to think about hardware refresh 😒. I’ve also seen too many on-premises to cloud migrations with the approach “let’s just take vCPUs and memory numbers from on-premises and we should be good”. If that wasn’t enough, during multiple years of working as a SAP Basis Consultant, I never wondered how much a single SAP system costs from an infrastructure perspective. I wasn’t aware about how much it costs to purchase, provision and operate those systems… or how to optimize those costs. And that was perfectly fine, as long as we all did it with a capex model using our own (or collocated) data centers.

But then the public cloud changed everything and shifted it all left. From a financial perspective it translates to developers / IT staff now having the power to spin up cloud-based resources and controlling the costs of running your core IT systems. It’s not enough anymore to have the “core” skills of designing / implementing / maintaining SAP systems. At least part of your Basis / Architects / DevOps team needs to be aware of the new reality and should be a part of your company-wide FinOps practice. It’s them who know the infrastructure, have insights into performance metrics and decide on resources to run your business processes. If them, who need to know how why they should even think about cloud-based resources, what options do they have to make the best use of those and how to talk to the finance team so that instead of a semi-controlled-chaos, there is a set of well-defined processes and common understanding between all the stakeholders.

If you’d like to know who – from SAP perspective – should be a part of the FinOps practice, what responsibilities might those persons have or what options and tools do you have to optimize SAP-based workloads, stay tuned (or sign up to my newsletter) for the next article, as I’m planning to shed some light on those – and other – aspects of cloud cost control.