When I first created TCO, it was a way of understanding the full life-cycle cost of assets. The basic unit of measure was the thing, a PC, a server, and / or all the other stuff commonly found from the desktop to the data center. My advice to Gartner clients was “when you open the shipping boxes, out come the computers, and an assortment of people from the help desk, system administration, security, procurement, asset management, IT management, and end users.” The TCO was based on the physical asset and all the related labor and service costs were bundled into that asset. This was the logical way to look at IT in the 1980s and 1990s. TCO was designed to identify and manage the cost of the IT asset. This was also helpful in assessing the cost differences between vendors of those assets – famously between Wintel and Apple assets. If you wanted to know your end user help desk costs you could multiply the unit cost of help desk / PC and the number of PCs and it was a reliable metric. As a management tool, It conformed to the siloed nature of IT disciplines.
In an early wave of democratization, TCO was also a way for IT to demonstrate the value added beyond the base cost of the PC, to counter the end user argument that the “same” PC was cheaper at Fry’s or Crazy Eddie’s.
Then in the late 1990’s IT organizations followed the lead of the vendors and started restructuring their deliverables as services, collapsing the siloes (data center, desktop, networking, applications) into ITIL services, then packaged offerings like Infrastructure as a Service, ERP as a Service, Business Process as a Service, Mobility as a Service, etc. Then Service Catalogs were developed as the marketing face and cost recovery structure for IT. While Gartner predicted ITaaS was the way to go, it has taken IT a long time to evolve as a service provider. In the mean time the vendor side of the market has completely reinvented itself in the service model. Today, very few IT providers have pure play asset offerings.
Meanwhile the technology has become more abstract. Virtualization caught fire and redefined assets like servers and desktops. This has evolved to the software defined data center (SDDC) as networks and storage are virtualized.
The abstraction of physical assets was a key driver of new ways of thinking about IT cost. Now, instead a of a one for one replacement of a device with a cheaper, better, faster, or easier to use device, other options emerged. These options drive multiple scenarios for an asset; It can be replaced with another asset; it can virtualized; it can be offered as a service; it can exist in the cloud. Financially, the asset can be capitalized, or take one of several operating expense options. These were critical forks in the road to determining the best TCO decisions.
Early into this phase of IT evolution, we renamed TCO to TCS (Total Cost of Services). The TCS tool repackaged the resources into a cost per service mold. This has been very helpful to enterprises that need to have a cost underpinning for their service portfolios. It has also been useful as a decision support tool to assess the cost differences between commercial offerings. The question was no longer which server has the lowest TCO, but which IaaS offering has the lowest TCO.
At the same time as vendors and buyers moved to a service based model, another massive wave democratization of IT landed. IT no longer had a captive market. The business users were shopping the market for IT capabilities. IT has been forced to compare itself to market pricing, again to demonstrate its competitive value and establish a base for chargeback or showback. Without a cost basis, IT is caught in the conundrum of being perceived as both “free” and “overpriced” depending on the situation.
Now cloud computing has emerged and virtually every IT function is available as a service and is priced by consumption. Common iterations of cloud include IaaS, PaaS, SaaS delivered on public, private or hybrid platforms.
With the advent of virtualization and cloud computing, we started talking in terms of workload. The concept of a workload is simple – it’s a complete unit of functionality. Defining a specific workload is trickier.
In the virtualization era, workloads were asset defined, and while there are nuances like the fact that virtual machines need to run on physical hosts, traditional TCO analysis could still be applied. A virtual server is a server; a virtual desktop is pretty much a PC.
In the cloud era, services are unitized into workloads that are created in virtual domains. The workload can be crafted to the type of cloud offering that is a best fit. Let’s use a traditional HR application, running on premise on physical or virtual servers. The entire application can be viewed as a workload. Or just the infrastructure can be isolated as a workload. Same workload, vastly different cost analysis. This workload could also be looked at compared to a SaaS offering with similar functionality. Again, same workload, different cost analysis.
Please note that the principles of TCO remain the same. TCO is a holistic view of costs, across enterprise boundaries, over time. It consists of a collection of cost items – the resources (Chart of Accounts or Bill of Materials) and how much of those resources are consumed by the workload.
However, workload TCO creates additional complexity to the analysis. Multiple scenarios, using the same resources, but with different allocations need to be projected. The tools that worked for asset based TCO and even for TCS need to be more sophisticated, flexible and iterative.
This is why The TCO Alliance created Workload TCO Analyst. WTA is a powerful tool and methodology that will provide in-depth, fact-based cost baselines and projected future scenarios. Please contact us at: firstname.lastname@example.org or simply by calling me at 203.215.7717 for any questions on how this may apply to your project needs.
HOW WORKLOAD TCO ANALYSIS WORKS
Very recently, in an enterprise not so very far away, a decision was made. The decision was how to best modernize an on-premises legacy HR application.
Situation: The 10-year old HR application was highly customized to meet the changing business needs of the enterprise. It was integrated with several other applications and data sources. However, it was showing signs of age. It was increasingly down for maintenance and unplanned downtime; it was pushing the capacity of the infrastructure; and it was not able to easily meet the new demands of new social media and other workplace interfaces. This application is one of many workloads requiring financial analyses to assess the cost of moving to the cloud.
Task: Senior management has mandated a cloud-first strategy. This requires all new applications to be cloud-based (private, public or hybrid) and any new investments to prefer cloud solutions. The driving forces behind this strategy are that cloud platforms may cost less and require less capital investment, enable a service-oriented strategy, and a more agile, responsive IT function.
As this was a >$1M project, senior management oversight and due diligence dictated that all options be put on the table. The most viable options were to:
A. Do nothing
B. Upgrade the on-prem application. (Vendor support for the current version would cease in 18 mo.)
C. Modify the existing workload, make it “cloud-ready” and re-platform it, which implied refactoring, microservice APIs and containerization.
D. Abandon the legacy application and move to a commercial SaaS offering
Approach: There were many decision factors, but a primary driver was economic. Which approach would cost less over time? This enterprise employed a process called Workload TCO Analysis (WTA) to compare the above scenarios. WTA is based on the concept of a Fully Burdened Workload (FBW), where TCO can be assessed for any discrete workload.
The 8-week project process was:
1. Perform an analysis of the current workload TCO by building a baseline resource / asset model
2. Forecast the baseline forward with a fact-based forecasting tool
3. Develop a TCO scenario for each option, perform an in depth financial analysis of each path forward
Result: The engagement developed a defensible financial analysis that could be reviewed and understood by senior management. The decision was made to take option D, sunset the existing application and migrate to the cloud-based version from the same vendor within the next 12 months. The organization originally compared the SaaS costs to the on-prem costs. The WTA identified additional key costs such as multiple APIs, business process and governance changes, and SaaS staff support costs. The benefits of enabling new functionality and complying with the cloud-first strategy were the business justification drivers. Management had a clear expectation of the migration and long-term operations costs of the application.
The project produced the additional benefits of a baseline IT cost model that will be used to:
Build a strong financial foundation underneath your IT roadmap
Build zero-based annual budget with what if capabilities\
Make other point decisions as new workloads are assessed
Build a fully loaded IT service cost consumption model