As we developed Workload TCO Analysis, it was
critical for us to be able to answer the question “What is a workload?. In my
experience, clients often refer to “workload”, but can’t really define what
that is. Clearly if one wants to quantify the cost of a workload, project the
cost forward and compare it to the cost of alternative platforms, then the
workload needs to be carefully defined.
In it’s most simple expression, workload is a
term used to describe a collection of activities that need to be done.
A workload is a unique metric. It is defined
by the work it performs and is scaled to the level of effort of the work. By
scaling I mean that a workload can be a very small function, like resetting a
switch, or a huge amount of work which
may be the sum of many workloads, like rebooting a power grid.
In computing, a workload is the amount of processing that a computer (or virtual
computer) performs within a given time. We believe that this definition, while
correct, requires further context to be useful in business decision support. We
further define the workload within the cost and the job for which it was
designed to accomplish.
Another key defining trait of workloads is
that they are abstract. A workload would be an abstract description of the
capability or amount of work that could conceivably run in different physical and
virtual environments that have unique configurations suitable to the underlying
resources in play. In the IT-as-a-business world a workload can be defined at the
server, the mobile phone, or the entire data center level. So the size and
complexity of the workload is amorphous.
The business views workloads by its
accomplishments. It doesn't care about the various pieces that make up a
distributed application. They just want the whole megillah to do what it's
supposed to do, whether it's on premise or in one cloud or another. The best
way to think about a cloud-based workload, therefore, is all the individual
capabilities and effort that make up a discrete application. Allowing
distributed apps to be single workloads brings the workload discussion closer
to the business. This is key to understanding the value of Workload TCO
Analysis. Just as the workload can be an aggregation of capabilities and
effort, it can be dis-aggregated into its component parts.
In developing our Workload TCO Analysis
practice and service offering, we have further refined the definition of
workload to add measurability, so that it can be compared to alternative
platform and managed over time. We have
also implied the TCO attributes of life-cycle (over time), MECE (mutually
exclusive, collectively exhaustive) and holistic view (across enterprise
boundaries) to complete the analytical framework.
So the TCO Alliance
uses this definition:
A workload is a measurable level
of every IT resource needed to get a clearly defined business function
accomplished.
When we do Workload TCO Analysis, we need to
carefully define the workload based on based on its output and business
outcomes.
If the goal is simply to put new
infrastructure in place, it’s fairly simple to identify a workload – the
servers, storage, network, staff and fees associated with the production or
operations cost of the components. However, a full Workload TCO Analysis must
also include the cost of moving the workload and managing it through its
life-cycle, including the retirement of the old infrastructure and migrating to
the new platform.
Let’s say a sales application is a target to
be updated, it might be re-platformed to be cloud native, it might be upgraded
on-premises or it might be retired and a new SaaS solution put in place. In
order to properly assess the fully-burdened cost of these alternative
scenarios, we must surgically identify all the resources that contribute to
this application. There may be new
resources required, some other resources may be modified or redundant. This
will result in some costs going down and other costs increasing.
As the workload becomes more abstracted at
the business application level, the analysis becomes much more complex. There
are inter-dependencies between infrastructure components, data, platforms, and
labor resources.
In order to gain insights and make informed
decisions, an analysis of virtual
functionality of the workload with multiple re-platforming options is required.
This is much more complex than earlier decisions. And because of the realities
of today’s marketplace you need multiple
comparative scenarios (on-prem, cloud, hybrid, etc.) to make an informed financial
decision.