Six Economic Answers You Need When Making Re-platforming Decisions

When framing a re-platforming decision, it’s important to ask the basic questions that assure the successful economic justification of the initiative. It’s also important to answer them accurately, completely and objectively. Additional dimensions to the strength of the business case are its transparency and defensibility. In other words its required to “show your work” to provide the backup and drill down proof of your answers.

These are not the only questions one should ask when making a re-platforming decision, or any IT investment decision. These provide the minimum amount of information to vet the initiative.

While the answers don’t guarantee that a project will be approved, they address the full life-cycle cost / benefit / risk expectations of the decision and go a long way towards measuring the success of that decision.

Here's our list:

1. How much will it cost to continue as-is?

Every argument for change has to start with a baseline model of the IT cost ecosystem. This puts the stake in the ground by which success or failure will be assessed. Once the baseline is established it should be forecasted over a reasonable time horizon (3-5 years). The forecast should be long enough to settle in on a stable run rate for the next generation of the workload. Note that we use “as-is” rather than “do nothing”. We believe there is no such thing as a do nothing scenario. Even in a stable, mature state a workload is subject to cost events like maintenance, patches, upgrade cycles, labor costs and licensing fees. So going forward as is does not mean doing nothing. It’s important to carefully identify, plot and plan these cost changes over the extended baseline scenario.

2. Which candidate workloads to forecast?

There are two ways to identify target workloads. The first is the list of workloads already known to be at end of life. An application that cannot meet the business demands because of technical obsolescence, spaghetti-code, or other inhibitors is a clear candidate. Infrastructure that is old, fully depreciated, and high maintenance are another class of possibilities. Development platforms that don’t meet modern needs could be considered. Finally, SaaS applications that offer new functionality by the slice may be appealing for re-platforming.

The second is to mine the baseline to look for opportunities to reduce costs, increase functionality, and better meet business needs (remember, IT is a business unto itself).  A proper baseline model is like a Rubik’s cube of assets, labor, and other resources that can be reshaped into IT functions, IT services, and business services. Workload TCO Analyst (WTA) is based on “perfect pivot tables” that present a data cube for Business Intelligence (BI) mining. This approach creates new insights into the cost data and the relationships between cost elements.

Either way the candidate workloads should be extracted from the baseline and isolated for comparative analysis.

3. What is the TCO of targeted workloads?

Each extracted workload should have a cost basis as a subset of the baseline. Using a modeling process like WTA, a fully burdened TCO of the workload can be established and forecasted to the planning horizon. This becomes the new baseline for as many alternate scenarios that can be imagined. The forecast should be based on a “planning curve” of factors that will affect the TCO over time. These planning curves should be easily adjusted for both “what-if “ analysis and updated as actual data are recorded. 

A key point here: a “living” addressable model is much more useful than a single point in time snapshot of the workload cost.

4. What is the TCO of alternative scenarios?

In today’s IT marketplace, there are often several technical options for the next turn of the crank of a workload. Alternative scenarios might include upgrading the existing on-premise workload; refactoring and moving it to cloud, choosing SaaS provider, etc.  One of the challenges of IT comparative cost assessments is creating an apple-to-apple cost analysis. This is why we chose the workload, a generic platform agnostic common denominator.

Once the cost of as-is is determined and forecast to the planning horizon, alternative scenarios for the next generation workload can be created. These scenarios take all the cost elements in the legacy workload, plus any new elements that are part of the next generation workload. The addition of new costs are called “puts” and the cost reductions are “takes”. These puts and takes create a cost basis for the scenario. They are applied to a planning curve and forecasted parallel to the baseline.

The result is a consistent, objective, comprehensive cost assessment of alternative scenarios for a targeted workload. This method can be applied universally to any workload in the data cube.

5. What do you need to make a defensible and informed decision?

Chances are that there will be a number of stakeholders interested in the cost and benefits of re-platforming and upgrading decisions. Each of these may have a different perspective on the decision. The business stakeholders are mostly interested in the bang and less interested in the buck. The finance stakeholders are looking for financial performance (typically ROI, IRR, NPV, payback, etc.). The IT stakeholders are mainly looking for integration, standardization, scalability, elasticity, security, and architectural fit. So the economic analysis of the workload options needs to meet all these needs. All the stakeholders are interested in risk profiles of the alternative solutions.

This is where having a Rubik’s cube of IT BI data can really pay off by:

• Creating views of the data that appeal to various stakeholders
•  Pivoting to create custom relationships between data categories
• Automatically generate complete financial reports
• Ability to show your work by drilling down to the cost of the lowest component
• Capability for what-if analysis to address stakeholder questions

6. How will the solution perform over time?

Increasingly, IT investments are scrutinized over time to determine if the projected benefits are being realized.  Going are the days of one-off cost analyses that are filed away, never to be viewed again. Analysis by spreadsheet is very difficult to maintain over extended periods and is often limited to the initial assumptions. With a data cube, there is much more depth of inter-dependencies that often harbors the gremlins and boosters of benefit realization.

The selected solution scenario will have KPIs that can be harvested for benefit realization. It’s not only important to determine a benefit, but also to predict where it will occur during the workload life-cycle. Often benefits are realized late in the life-cycle after the workload platform is optimized and broadly adopted. This may be dramatically different between capital intensive on premise investments and pay as you go cloud solutions.

A working model of your IT costs that is maintainable and dynamic is, in our humble opinion, the best tool to determine if and when the chosen solution will payoff.

The net-net is that your important IT business decisions require a robust, repeatable methodology and toolset to adequately answer the above questions. Beyond answering these questions it’s critical to be able to defend those answers. And finally, these answers need to stand to the test of time. 

Contact the TCO Alliance at info@iiievalue.com for further information or to set up a demo.

So What’s A Workload?

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.

This is why we invented Workload TCO Analyst. It’s a combination of consultation and a powerful modeling tool designed to be a platform for making  critical IT transformational decisions.

IT is undergoing seismic change as next-generation technologies drive digital business transformation

 

How will you build the business case for the digital transformation - or simply your next cloud transition? We believe the answer is:

1.     to assess cost by fully-burdened workload and 

2.     address the full lifecycle cost including current and forecasted production costs as well as the often missed or underestimated migration costs.

We call this blind spot "The Gap".

To address this need, The TCO Alliance, a partnership of the International Institute of IT Economics and IT Business Decisions is pleased to announce Workload TCO Analyst.

Key Issue: What is the true cost of IT transitions?

Solution: Perform a rigorous financial analysis of:

·       Major on-premises and managed services workloads

·       Develop workload baseline costs, future scenarios, and decision options

·       Using detailed “puts & takes” to show financial impact, performance tracking and “what if?" analysis

HOW WORKLOAD TCO 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 months)

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 included: 

 

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

About The TCO Alliance

The TCO Alliance is a partnership of independent, IT financial analysts and modeling experts formed to solve IT’s most critical cost assessment challenges. 

 

The principals are:

Bill Kirwin - Inventor of TCO at Gartner. Founder, International Institute of IT Economics (IIIE)

Bob Multhaup - Former CIO, Inventor of ITin3D© cost modeling tool 

Peter Brooks - Business Value Consultant. Partner, IIIE

And a team of independent, IIIE certified IT financial assessment professionals

What We Do

Show fact-based financial future options to for making major
planning decisions

Deliver in-depth expert consulting and a working cost model of their optimum path forward

Our Value

Quantification of the optimum financial path forward with in-depth, proven tools to avoid pitfalls between digital transformations

Rapid, in-depth, affordable decision support tool to avoid major miscalculations in moving from one ‘S’ curve to the next

Our solution is scalable, flexible for point decisions or major planning initiatives

More effective than biased vendor-driven analysis and expensive management consulting

Our Unique Deliverables

We use ITin3D©, a powerful financial modeling and decision support tool to:

·       Defensibly communicate the transition costs to senior management

·       Perform scenario options including financials impacts to evaluate the ‘best’ path forward

·       Flexible planning, track actuals, rework plan – ability to easily rework the plan to adjust for changes to re-forecast financial impacts using the ITin3D© model

TCO Alliance Models work for any IT change scenario - BYOD, Data Center Migrations, Sourcing, Digital Business Transformation. If you can think it, we can model it.

Contact:

The TCO Alliance

info@iiievalue.com