I’m looking forward to presenting at the SAP Insider IT 2011 conference March 15-18 in Las Vegas…and have been developing my presentation this week. One of my passions over the last 15 years is SAP and other LOB application Total Cost of Ownership (TCO) analysis. For many IT organizations, the decision to ‘replatform’ or migrate from one computing platform to another is based first on cost. Will we save money moving to Windows/SQL? Does the Linux/Oracle platform really reduce my costs compared to AIX/DB2?
The idea of saving money is simple, but the reality is complex. A simple TCO analysis breaks out the technology stack into its various layers and seeks to assign costs to each layer. At the simplest level, an LOB application technology taxonomy comprises:
· Data center/hosting facilities
· Hardware (servers, disk subsystems, network infrastructure, and other required physical assets)
· Operating system (license cost)
· Database (license cost)
A very basic TCO model might be described as:
TECHNOLOGY A+B+C+D Acquisition Costs
Interestingly, the SAP application layer doesn’t really need to be included in the list above, as it’s essentially the same cost regardless of the underlying computing platform (HW+OS+DB). This simple model is fine for starters, but it has significant shortcomings. Smarter TCO models extend the technology taxonomy to include middleware and other integration technologies, client devices, and so on. But at the end of the day, such a ‘technology-focused’ view of cost is inherently limited in that it only captures point-in-time costs (or more specifically, the acquisition costs associated with each technology). A better TCO model factors in operations costs across a reasonable timeframe, i.e. 3 years. By including these lifecycle costs, we can arrive at a much stronger estimation of what one platform costs vs a different platform.
TECHNOLOGY Acquisition + TECHNOLOGY Operations Costs
Capturing technology acquisition costs plus ongoing lifecycle costs is good, but it’s still limited. What about the “process costs” associated with migrating, installing, patching, administering, operating, and generally running each platform? These costs can vary considerably. In fact, they vary over time as well (as an organization grows adept at managing and maintaining its IT platforms). So a better TCO model might look like this:
TECHNOLOGY Acquisition & Operations + PROCESS Acquisition & Operations Costs
Who makes sure all these processes are executed? Who installs the technologies? Who maintains and operates the platform? People! And as we all know, the cost of people can vary significantly. Windows and SQL administrators are more readily available and less expensive than their UNIX, Oracle, and DB2 counterparts. Various hosting providers charge different rates for different skillsets. And so on…. Thus, a really good TCO model should factor in the cost of people – a cost that varies over time just as technology and process costs vary over time. Typically, we people get more expensive….though that’s not always the case. For example, a North American firm that transitions to a global support model should see its costs decrease). Regardless, a pretty strong TCO model can then be described as follows:
TECHNOLOGY A&O + PROCESS A&O + PEOPLE A&O Costs
This Technology+Process+People (or TPP) representation of TCO has become something of a defacto standard for identifying and presenting costs models. We can apply this model to SAP platforms just as easily as collaboration platforms, BI/Analytics platforms, Manufacturing Execution System (MES) platforms, and so on.
But there’s a problem with the TPP model, which brings me to my session I’ll be presenting at the BI/IT conference in March 2011. As most of us realize, TCO is only one of a CIO’s hot buttons. What about time-to-value? What about the impact of change? And perhaps most importantly, what about RISK??? A really effective TCO model should incorporate TPP costs as well as the ‘costs’ or impact of various risks, giving us a formula like this:
T/P/P A&O Costs + RISK Costs
In my SAP Insider IT2011 session, I’ll walk through what I’ve described above and then I’ll outline how we can better inform our traditional TCO models with this concept of risk. I call my approach “Cost and Risk Modeled Architecture” analysis, or CARMA analysis. CARMA is based on a Microsoft-developed taxonomy of 10 primary risk factors which in turn are comprised of 40 unique and quantifiable subfactors. The 10 factors include:
1. AppPlat Deployment/Migration (Deploy)
2. AppPlat Hosting (Host)
3. AppPlat Availability (Down)
4. AppPlat Agility/Flexibility/Scalability (Agility)
5. AppPlat Performance (Perf)
6. AppPlat User Community (Users)
7. AppPlat Management (Mgmt)
8. AppPlat Strategic Vendor Alignment (Align)
9. AppPlat People/Org (People)
10. AppPlat Process Maturity (ProcMat)
Check out my session abstract:
Thought leadership: Using risk factors to better quantify SAP architecture design TCO
Dr. George W. Anderson, Microsoft
Enterprise architecture designs are notorious for hidden costs, problematic value propositions, and uncertain return on investment (ROI). With regard to technology platforms for mission-critical applications like SAP, there’s simply no clear cut answer as to which truly offers the lowest cost of ownership or most rapid ROI. This session offers a proven methodology for calculating and credibly comparing the weight of risks inherent to various technical platforms. Learn how to assess total cost of ownership (TCO) using Cost and Risk-Modeled Architecture (CARMA), a method of informing traditional TCO analysis through the application of risk factors. Understand how CARMA enables business and technology architects to quickly identify the technology, people, and process areas that most likely affect their TCO. Explore a method of “weighting” SAP TCO analyses to enable better-informed vendor-agnostic decisions as to the ideal technical platform for a proposed ERP implementation or platform migration.
At Microsoft, we’ve begun developing a tool that will help our customers and prospective customers capture all these cost and risk data to provide better visibility into what it means to replatform. It comprises TPP as well as the 10 risk factors/40 subfactors. We like the idea of quantifying these risks of change, i.e. the risks of going against the status quo or “going out on an unfamilar limb” (which is what Frank Scully said, completing his though with “after all, isn’t that where the fruit is?!”). So stay tuned! And I hope to see you in Vegas where we can talk more about this model, what’s missing, and how to make it more effective….