Just as it is said, a dog is for life, not just for Christmas – meaning that one small decision impacts the long term not just a single day – the same can be said for enterprise software. Bringing in and deploying new IT platforms, suites, services, and applications in any organization is not about the deployment of new software; it is instead a serious undertaking that requires foresight, a holistic mindset and a longer-term view.
Enterprises who want to purchase software, as well as hardware, efficiently look beyond initial contract cost. They also see the sum of all direct and indirect costs incurred by that software. The most progressive businesses will also accommodate for hidden and unknown costs across the software lifecycle.
This is Total Cost of Ownership (TCO), and it is a critical part of an ROI calculation.
Driving software forward
When we examine the sometimes thorny topic of TCO, it’s common to reference automobile or house ownership as a comfortable parallel to illustrate the pain points. Anyone who has owned a car or house knows that after the initial purchase cost there comes an inevitable stream of service charges, taxes, tolls and, of course, the cost of parts and maintenance.
Technology and software in particular are similar in so many ways. Software application developers build a code-based ‘engine’ and ship it to the customer, but there are plenty of additional engineering and commercial costs to think about down the line. Those additional costs can include integration, maintenance, updates, training, operations time, and the cost of retiring systems when they reach end-of-life status.
TCO timeframes for SAP Cloud
Let’s examine the intricacies of a TCO calculation in relation to an ‘average’ (if there were such a thing) SAP Cloud deployment. Given the path that a business will travel on a deployment of this level of complexity, we can achieve better TCO if we know the component parts of the cost curve and when they are likely to change or spiral, or be potentially avoidable.
First and foremost, let’s remember that this is a timeframe-centric analysis. Logically then, we can point to up-front costs and longer-term costs that won’t surface immediately.
Initial costs will of course include license purchase cost, consultancy overhead, and perhaps exit charges from previous and/or incumbent IT platform suppliers.
Initial cost envelope
To examine the cost envelope that describes the initial part of our SAP Cloud TCO universe, we must look, not just at migration management and testing, but also at integration on two levels. A business will need to perform what could be keyhole surgery level integration to bring SAP Cloud into a) its existing IT estate on a greenfield basis and b) into line with any other third-party technologies that form the brownfield zone of its working IT function.
Inside whatever time horizon a customer works with in terms of its enterprise software stack, ultimately it will want to use TCO to keep track of where its expenditure sits in relation to that pre-specified horizon. This is usually a factor determined by the terms of the software license undertaken. But even with these measures, just how accurate is TCO?
In real-world operations, customers very often find that cost estimates are essentially underestimated. These overruns are often due to the fact that they have spun up extra servers or bought in additional easy-to-consume Cloud services for which they had not initially budgeted. For this reason, it’s very important to embrace FinOps (financial operations) to provide an essential cost-conscious control mechanism that stems from a dynamic view of the installed base of technologies.
Comfortable controllable constancy
Assuming everything stays the same in a given deployment, SAP IT estates are generally very stable instances of technology. Crucially here, we’re talking about SAP Cloud deployments. For customers coming from on-premises environments to this new universe of technology, that constancy and predictability is a welcome standard upon which they can start to function and innovate.
When you think about the various services that any company will consume, the basic trinity is composed of storage, networking, and compute. Of these, networking is the most consistent and solid, compute is relatively consistent, but storage can be the cost that balloons the most if a lot of extra backups are performed. In this scenario, we would make sure we know what the rationale is behind the additional storage costs and look to examine whether additional backups are being performed erroneously, or perhaps where old redundant data is still being stored.
One of the higher costs that can surface time and again are egress charges, i.e., when a customer wants to move from one Cloud Services Provider (CSP) data center to another, whether that’s to an analytics engine, or to some Cloud service with highly optimized transactional throughput capabilities, or perhaps to another CSP’s data lake. Most providers will make sure that it’s free (or as good as free) to get your data up to the Cloud but moving it elsewhere generally comes with a surcharge.
Payment shapes & constructs
When it comes to operating costs, things have obviously changed in the world of Cloud. In the old world, we used to have to think about ground rent, insurance, utility costs, and all the other charges associated with physically keeping the lights on in order to figuratively keep the business’s lights on. Now that we have moved from the physical to the virtualized world of Cloud computing, those costs have shifted and now exist as an element of the charges levied by the CSP who encapsulates them in their billing systems.
If we think about when these costs surface, it will generally depend on the commercial constructs that a customer opts for with their Cloud provider. While some customers will pay monthly, quarterly or bi-annually, other contracts, such as those based on ‘reserved instances’, will feature up-front payments in lump sums.
Keeping your eyes on the cost horizon
We know that in real terms, customers’ mindsets are often just focused on getting to the Cloud. With all the fireworks and distractions that this entails, it can be hard for customers to think about their short, medium to longer-term cost cycles. However, organizations moving to Cloud are starting to realize that their cost curves come down in years two and three of a deployment. From this, we can say that TCO calculations are becoming more mature – and this is a maturity that is happening in line with the wider maturity of Cloud itself and the way organizations use it.
