If cost of ownership analysis is a painful exercise for IT organizations, why has almost every company done it (and continued to do it) multiple times? \n\nSimply because management requires an accurate understanding of current IT costs and strengths so they can better assess new ideas and technologies. \n\nIn this article, we will identify six key elements to effective cost of ownership analysis, which you can use these to improve the accuracy and eliminate the \n\nfrustration associated with this necessary step in your IT evolution.\n\n1) Analyze Platforms, Not Servers\n\nFirst evaluate the current "platforms" within your environment, including all servers of all types in order to simplify the process. One of the most \n\ndifficult things to "get right" in an analysis of this type is an exact match between a given technology and the associated costs. The easiest way to do this is \n\nnot to limit the technology scope to a few machines or a single new application but to expand it to match all the technology in the IT budget. Limiting the \n\nscope makes cost of acquisition simple to determine but it makes every other cost almost impossible to quantify without controversy.\n\n\nA platform approach will result in development of a new "view" of the IT budget that is platform based. The advantage to this approach is that the \n\ntotal in this view should match the total in the budget. This gives the study team tremendous leverage if discussions should wander to "I think this amount \n\nis too high for platform A." So if the amount is reduced for platform A, it must be raised for platform B. What does B think of that? This places the \n\nentire cost discussion on solid footing \u2014 the IT budget \u2014 and allows the process to be managed dispassionately, a key to later acceptance \n\nof the results.\n\n2) Focus on a Representative Application and Include All the Pieces\n\nNext, let's consider a new business critical application or workload that requires platform selection. Once again, the key to success is to not limit the \n\nview to a subset of components. By definition, a critical application will require careful design, careful sizing, careful maintenance, operation, support, and \n\ndisaster recoverability. It may also require a new or dedicated infrastructure, but at a minimum, it will tax existing infrastructure. Each of these components \n\nand their associated costs, should be included in any cost of ownership comparison. The "view" developed in the previous step should facilitate this type \n\nof analysis.\n\n\nOver the past ten years, our group within IBM Lab Services has been doing IT Systems and Storage Optimization ("Scorpion") Studies that focus on \n\nthis type of view and component based analysis. Our findings show that a typical ratio of production Web, application, and database servers to \n\n"everything else" is about one to one. This means that any analysis that omits those other components for support, maintenance, and disaster recovery, \n\netc. may miss half of the real costs. This discrepancy grows for very large critical applications and is largely why our industry hasn't done so well sizing \n\nmany new enterprise application suites. We've all heard the stories.\n\n3) Consider Practical Capacity, Not Vendor Ratings\n\nSystem capacity and performance can quickly become a very tedious and esoteric discussion, and in many cost of ownership efforts, it does. \n\nVendors feed this controversy to gain competitive advantage. This can be avoided. Our experience is that the most important aspect of performance \n\nanalysis within cost of ownership is not which vendor claim or benchmark is used as a base, but rather (a) what system utilizations are "normal" in your \n\ncurrent environment?; and (b) what is a reasonable expectation for the future?\n\n\nOften, distributed server utilizations are very low and there is a good reason for it. An underutilized server requires no capacity planning. Most cost \n\nanalyses are considered part of a technology acquisition process so higher future state utilizations are assumed. If average server utilizations in your \n\nenvironment are low, model a future state of 2 or 3 times the current for each component in the possible solution. No higher. Use any reasonable \n\nperformance metric - expected utilizations are far more important.\n\n\nThis is particularly true with the rise of virtualization, which is almost always \n\nassumed in cost of ownership comparisons. Transitioning from a non-virtualized to virtualized server environment has some significant advantages including \n\nhigher potential utilization. It has a cost, however, capacity must be managed. Don't assume world class utilization numbers unless you know what kind of \n\neffort it will take to attain them.\n\n\nIBM's System z mainframe environments typically demonstrate this fact quite well. Mainframes usually run at very high utilizations around the clock. \n\nThey can do this because the level of internal standardization and automation is much higher than other platforms. Other platforms will eventually attain \n\nthese levels, but that is still years of vendor development away.\n\n4) Don't Ignore Labor Costs to Protect the Innocent\n\nThe most difficult topic within cost of ownership is undoubtedly the cost of labor. In a down economic cycle, most staff see nothing positive in \n\nquantifying the cost of labor for "their" platform. High Full Time Equivalent (FTE) ratios have been an industry target for years and most IT professionals \n\ncan quote the current best practice and describe how they are exceeding it. Therein lies a problem. IT infrastructure support organizations have been \n\nmanaging to these ratios for years using two basic strategies: (a) improve efficiency; or (b) push work onto other parts of the IT organization. The extent \n\nto which strategy (b) is used differs by platform for a variety of reasons, but the result is the same. Any cost of ownership analysis that limits labor \n\ncalculations to IT infrastructure support headcount will likely miss major portions of the real support costs and skew the results.\n\n\nA good solution to this problem is an approach similar to item one. Consider the entire IT organization and apportion every group that is not truly \n\nplatform neutral (and even individuals within an otherwise neutral group, like network support) to the appropriate platform labor category. The same kind \n\nof "view" is now developed for assignment of labor with the underlying organization chart as the foundation.\n\n\nThe results will look quite different from industry published norms. They will be higher \u2014 up to 2 times or more on x86 platforms \u2014 and \n\nwill reflect true insight to cost. Because the resulting labor cost numbers cross organizational lines, no one group will feel responsible for them, or for \n\nlowering them. Resistance to the process will be lessened and again, buy-in should be improved.\n\n\nA side benefit to the process stems from the two strategies often used to manage FTE ratios \u2014 productivity improvement and narrowing of \n\nresponsibility. If the FTE ratios are changed significantly by the new "view" of the organization, the need for productivity tools will be evident. In the \n\nyears that we have been working with customers doing these studies, we've seen an alarming trend toward high complexity within distributed systems \n\n\u2014 old hardware, old software, multiple releases of everything to be maintained \u2014 and a lack of investment in systems management \n\nsoftware. This is in stark contrast to the mainframe where software costs tend to be high while systems are maintained at strict currency levels, with the \n\nresult that staffing has been flat or dropping for years with steadily improving Quality of Service (QoS).\n\n5) Quantify QoS in a Way that Makes Sense\n\nQoS is an elusive topic since it has so many aspects that differ in importance between companies, but some general trends can give guidance. In this \n\nage of real-time systems, disaster recovery has become a universal need. Two key metrics in disaster recovery are Recovery Time Objective (RTO - the \n\ntime to bring alternative systems online for use) and Recovery Point Objective (RPO - the age of the data on those recovered systems). If we consider \n\nthe dominant RTO and RPO for a given platform, we gain insight into both cost and QoS. Though any system can be made disaster recoverable, there is \n\na huge cost differential between making a single mainframe recoverable and making 1,000 distributed systems recoverable. The majority of customers \n\nwe've worked with have done the former and not the latter because of the cost. This can be quantified very easily with a call to a recovery services \n\nprovider and should be included in the platform cost comparison.\n\n\nCloud computing and other metered services will certainly offer a recoverable \n\noption and here lies an opportunity. As IT will have to compete with public clouds the above cost analysis can be used to set internal cost guidelines for a \n\ncorporate cloud infrastructure very early in the cloud development process. Or it can be used to steer workload onto the platform that is already \n\nrecoverable, thus eliminating some of the need to develop a recovery capability where it currently does not exist.\n\n6) Look at Costs Incrementally \u2014 Plot Your Own Course\n\nThe last topic to consider is primarily financial. There is a "sunk cost" and an "incremental cost" associated with IT infrastructure that must be \n\nconsidered. Just as the first chip to roll off a fabrication line is worth billions and the second worth pennies, the first workload for a platform is far more \n\nexpensive to provision than subsequent ones. This is especially true for the mainframe since the technology may be physically refreshed, but financially the \n\ntransaction is handled as an upgrade. This is unlike the distributed world where technology and book value are tied together.\n\n\nIBM has taken this concept a step further with the arrival of mainframe "specialty" engines that have much lower price points and drastically reduced \n\nimpact on software costs. However, they cannot run alone, they must be added to an existing system. It is not unusual for mainframe systems in \n\nproduction to cost $4,000\/MIP while specialty engine upgrades may run only $200\/MIP. The incremental costs on the mainframe in this case are 1\/20th \n\nof current cost. These kinds of dramatic differences must be considered in cost of ownership and are often large enough to justify a change in course for \n\nIT. Exploiting these areas of low incremental cost to support growth can significantly improve the overall cost of IT. Virtualization is expected to have a \n\nsignificant effect on other platforms, so the need is universal and growing.\n\n\nWith 33 years at IBM, John Schlosser is currently a Senior Managing Consultant for the Scorpion practice within IBM Systems and \n\nTechnology Group \u2014 Lab Services & Training. He is a founding member of the group which was started in 1999. He has developed and \n\nmodified many of the methodologies the team uses for IT infrastructure cost analysis.