November, 2009
by Adam Grummit
This article is based on extracts from Capacity Management - A Practitioner Guide.
A good capacity manager can do well for one dollar what any fool can do badly for ten (with apologies to Nevil Shute). In order to do so, a good capacity manager should try to simplify a problem to something that can be solved using pragmatic approximations. Many laws can be applied in practice, subject to due consideration. Rather than consider the underlying science and mathematics, most of the laws are discussed here in terms of liquid refreshment, as they have been so discussed (most intensely) at CMG PARS and workshops in the past.
Various operational research laws used in capacity management will be introduced later. In order to set the scene, a few other laws are first reviewed. These are all expressed in sets of three, namely those of Newton, Thermodynamics, Clarke and Asimov.
Newtons Three Laws of Motion
Isaac Newton's Three Laws of Motion in Mechanics were first compiled in his work Philosophiæ Naturalis Principia Mathematica, published in 1687. They can be related to capacity management.
The First Law states that things stay restful unless there is an external force applied to it. Or in IT Service Management [ITSM] an organization can become stagnant without calling on some catalyst for change such as a ITSM consultant.
The Second Law states that the rate of change of momentum of a body is proportional to the impulse applied to it. The impulse is the product of force and time. So that the larger the enterprise, the greater the force required to make a change to ITSM and the longer it takes. This suggests that long assignments of large capacity management evangelists are recommended.
The Third Law deals with the balance between equal and opposite forces, typically expressed in terms of actions and reactions. This encourages ITSM enthusiasts to find ways of working with those less keen, rather than against them; so that the deliverables are seen to be to the benefit of the organization.
Three Laws of Thermodynamics
The Three Laws of Thermodynamics evolved during the nineteenth century. Contributors included Sadi Carnot, Rudolph Clausius, William Thomson (Lord Kelvin) and Josiah Willard Gibbs. The laws can also be related to capacity management. Capacity management can use its energy to instigate better control of the infrastructure and improve insight in the relations between business demand, IT services and resources. To achieve this, the members of the Capacity Management Team [CMT] need to be good communicators and be well energized.
The principle of the Conservation of Energy (the First Law of Thermodynamics) states that "The energy of a closed system remains constant during any process." So an enterprise considering Capacity Management Practice [CMP] needs to be open to change and establish an energetic CMT.
The Second Law is the conservation of entropy. Entropy is a measure of disorder, the more liquid the less ordered and the more entropy (for example, consider a glass of alcohol with some melting ice). A pub can be viewed as an entropy pool. Perhaps what is needed to energize a lethargic CMT is the right amount of the right liquid to optimize entropy in the system. This may need a bit of practice.
The Third Law states that as the temperature of a body approaches absolute zero, so its entropy approaches zero. A restaurant serving a good chilled wine with seafood is also an entropy pool. Again, enough of the right liquid served at the right temperature can ensure a well oiled team.
Asimov's Three Laws of Robotics
Isaac Asimov coined the Three Laws of Robotics in his 1942 short story Runaround.
- The First Law states that a robot may not injure a human being, or, through inaction, allow a human being to come to harm.
- The Second Law states that a robot must obey orders given it by human beings, except where such orders would conflict with the First Law.
- The Third Law states that a robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
These can be redrafted in a minor way (as first reported by Mike Ley of UKCMG) to address capacity management practice in the Three Laws of CMP:
- First Law of CMP: Make sure you have enough capacity for today, but not too much.
- Second Law of CMP: Make sure you have enough capacity for tomorrow, but not too much and only after satisfying the First Law.
- Third Law of CMP: By all means optimize the cost of your infrastructure, but only to the degree the business requires and only after satisfying the first two laws.
Arthur C Clarke's Three Laws
Arthur C. Clarke's Three Laws [ACCTL] were coined with due acknowledgements to the previous set of three laws from Isaac Newton. The first two were published in an essay "Hazards of Prophecy: The Failure of Imagination", in Profiles of the Future in 1962 and the third added in 1973 when he stated 'As three laws were good enough for Newton, I have modestly decided to stop there'.
ACCTL1: "When a distinguished but elderly scientist states that something is possible he is almost certainly right. When he states that something is impossible, he is very probably wrong." So beware when an aging ITSM guru says you can't manage the capacity of some new architecture, he may well be wrong. Note that Clarke defined old (in the days before political correctness raised issues such as ageism) in this context as "In physics, mathematics and astronautics it means over thirty; in other disciplines, senile decay is sometimes postponed to the forties. There are of course, glorious exceptions; but as every researcher just out of college knows, scientists of over fifty are good for nothing but board meetings, and should at all costs be kept out of the laboratory". This possibly applies to the CMT as well.
ACCTL2: "The only way of discovering the limits of the possible is to venture a little way past them into the impossible." In ITSM sometimes it is necessary to make assumptions about the limits of a solution in forecasting scenarios just to identify the true limiting factors.
ACCTL3: "Any sufficiently advanced technology is indistinguishable from magic." In ITSM this is important in that as new architectures emerge, they initially appear to be as magic (consider hypervisors and paravirtualization) until they become part of the landscape and their true issues, such as overhead, integrity and fiduciary become known.
Arthur C. Clarke was born in the seaside town of Minehead, Somerset, England in 1917. He wrote many technical articles, including the proposition of geo-stationary satellites in 1945, in Wireless World. He also proposed photon power and so paved the way for warp factors in Star Trek. He claims that he did not name the disturbed computer HAL to belittle IBM who had been less than cooperative in some aspects of making '2001'. Maybe he called it HAL 9000 in honor of HP. Note that the HAL-IBM 'one-letter-shift' relationship was carried on by Microsoft when naming Windows NT [WNT] as developed largely by a team of Digital/DEC VMS engineers. Note that Clarke added a fourth law later in 1999: 'For every expert there is an equal and opposite expert' and other less reputable ones later.
Having established that not all laws are necessarily mathematically complex, the laws of capacity management are now briefly reviewed. The three classic laws of capacity management are Little's Law, the Utilization Law and the Response Time Law.
Three classic laws of Capacity Management
1. Little's Law
John D C Little proved this law in 1961 as part of part of queuing theory within operational research. Little's Law states that "If a number of customers N are observed in a queue in a stable system and served in a period of time T and there are an equal number of arrivals A and leavers L, then throughput is defined as C= A/T = L/T and if the response time, the long-term average time spent resident in the queue and being served is R then R = N / C This means that a measure for a response time can be derived from throughput and counts of transactions in a given snapshot window.
2. Utilization Law
If there is a server which is busy for B seconds in a period of time T seconds then utilization is defined as U = B/T. Mean service time S is defined as B/L. There are L leavers n the period and throughput is defined as C =L/T. Rewriting B/T as B/L*L/T reveals the Utilization Law: U = S * C This means that a measure for service time can be derived from throughput and utilization.
3. Response Time Law
If there is a queue of transactions waiting for a queuing time of QT for service from a device with a service time of S then the response time is R where R = QT + S and subject to certain assumptions (summarized as 'M/M/N' models) the Response Time Law states: R = S/ (1-UN). This means that given the service time and utilization, the actual response time under different traffic conditions can be estimated.
The three modern laws of capacity management are Amdahl's Law, Moore's Law and Grum's Law. The last of these is not meant to be taken seriously (although it may resonate with many in practice).
Three modern laws of Capacity Management.
1. Amdahl's Law
Amdahl's Law is used when adding more processors to the CPU. If only a portion P of a process can be made parallel, then the limit of throughput improvement is 1/(1-P). If the parallel portion runs faster by a factor S (speedup), then the overall improvement is 1/((1-P)+ P/S). This is an example of the law of diminishing returns as each new processor added will add less usable power than the previous one and the speedup ratio will eventually limit. The law was first coined in 1967 by Gene Amdahl of first IBM and then his own ventures. The law may be less relevant with emerging architectures.
2. Moore's Law
Moore's Law is used to express the expected empirical growth in power. The observation was made that transistor density of integrated circuits (since 1958) increases exponentially and doubles every 18 months or so. It is now applied to most hardware. It was first observed by Intel co-founder Gordon E. Moore in 1965, it has continued since and is expected to continue for another decade
3. Grum's Law
All these well-known laws are all very fine, but why are things not so simple in real life? Gremlins. Gremlins are well known. They are creatures, commonly depicted as mischievous and technically oriented. Their origins were with World War II airmen, claiming that gremlins were responsible for sabotaging aircraft that they had returned badly damaged.
Grumlins are similar but smaller and more aggressive (check the author's surname) and are responsible for sabotaging the best endeavors of the CMT and others in IT. Grum's Law states (with due acknowledgement to Paul Wilkinson and his ABC of ICT, An Introduction to the Attitude,Behavior and Culture of ICT) that 'no matter what infrastructure practice framework is adopted by capacity managers, it will fail if they don't know their ABC from their 123 Grumlins'. Grum's Law is expanded in 123 grumlins under three headings, with just the first few shown under each heading in this summary:
Borrowed grumlins
1. From Murphy and states that 'anything that can go wrong, will go wrong'. So the CMT should look for program loops, memory leaks, missing indexes, fragmented discs, backups, housekeeping schedules et cetera to avoid building forecasts based on a badly tuned system or poorly selected snapshot window.
2. From Parkinson's Law and states that 'work expands to fill the space available' (in time or resource) so limits need to be introduced, even if self-imposed, to avoid project drift.
3. From Hofstadter's Law and states that 'Everything takes longer than you plan, even when the plan takes Hofstadter's law into account . . .' so when planning a timeline allow greater margins for error in predictions from marketing or development than from actual reported operational trends.
Anonymous grumlins
1. 'No matter what the chipset or architecture, all computers wait at the same speed' (zero) so it is important to regulate the impact of queuing.
2. 'The great thing about IT standards is that there are so many to choose from'. On average, new standards (like new CIOs) last for eighteen months so that in any large enterprise there are typically five active standard definitions in various degrees of implementation in place for each aspect of IT and five to the power 'n' permutations for the 'n' regimes of standards defined. So be dubious when you are advised that there are standard builds and standard applications enterprise wide.
3. The 80/20 rule - '80% of the detail/benefit/resource can be gleaned/gained/consumed by the top 20% of time/effort/workload' so focus on the 'easy pickings', low hanging fruit and major applications rather than trying to aim for a 100% solution.
4. The 90/90 rule - 'All projects are reported as 90% complete for 90% of the time' so monitor real deliverables (such as alpha testing) in the development of a new application.
Grum's grumlins
1. Every software developer and every computer system tries to expand to grab all the available resources faster than Moore's Law advises us the hardware is improving, so make a business case for the system 'as is' rather than assuming it will be twice as good a case in a couple of years.
2. Only a good software developer can do performance engineering but only a bad one needs to (as the good developer will incorporate performance issues in his thinking, whereas the bad one will try to do something retrospective after initial testing).
3. The more acronyms on a page of text, the less the author understands it (unless the topic is a goldmine of acronyms such as ITIL).
4. If the author can not explain the issue in a page or two (albeit using a small font), he probably doesn't understand it. So make sure your management summary for a capacity plan does not exceed a couple of well-written pages with no equations, few statistics and clear recommendations).
In conclusion, please exploit selected laws appropriately, be aware of the grumlins and keep all your capacity management activities lean, well directed, focussed and practical so that they are efficient, effective, well perceived, transparent and well respected. And please send me your ideas for more grumlins or any typos you find in the book!