There remain some good ideas in this article, which talked about Sun UK’s consolidation planning methodology but it is now mainly interesting as a then contemporary comment. See my comment. DFL 9 Jan 2015
- The methodology involves defining the problem area or scope, creating a detailed catalogue and describing the systems, system costs, the cost scalability rules, the system capabilities and utilisation. We then map the current system consumptions onto a future state architecture, costing the transition and then performing a traditional investment analysis. This involves understanding the expected costs of the future state solution, and designing to obtain the benefits of new systems which are smaller, cheaper, faster and more reliable. We have some key rules of thumb when designing a future state, these include
- Always deploy full systems; the card cage and backplane work harder justifying their cost. i.e. the cost/CPU is higher on half empty systems. ( This is a true rule of thumb, and is more appropriate for smaller systems (1-12 way)).
- Big systems (& hence domains) will deliver higher utilisation, and hence the acquisition costs to obtain the necessary capability will be lower; you pay for unused capability as well as used.
- Using large systems as if they were multiple small systems is silly. Only buy huge systems if you need big domains (or are at the margin of requiring big domains and value the scalability &/or flexibility).
- The premium paid in buying scalable systems can be seen as an option purchase for a bigger system than deployed. i.e. buy 48 CPUs and an option for 24 more.
The consulting offerings available to customers in the UK were described here……