If I were standing in front of you right now, I would have in my hands an empty glass and a pitcher of water. I would hold out the empty glass and say over and over, "capacity." Then I would hold out the pitcher and say repeatedly, "requirements." Then I would ask you, "Is the water going to fit in the glass? Are the requirements going to exceed the capacity?" In IT, what usually occurs is the water is poured in the glass, and we all look away, hoping it will fit. After a while, we start feeling the water dripping down our arm, and we have a mess. That mess is the result of the requirements exceeding the available capacity. When this occurs, we have a performance firefighting situation.

The performance management trick is to ensure the requirements will fit into the available capacity. In fact, if we can mathematically express the requirements and capacity-injecting alterations such of politics, budget, purchases, timing, and new and changing workloads-we have a much better chance of anticipating change. But if we guess at the requirements or the capacity, then everyone is just plain lucky if the solution works.

Requirements are one of the two metrics we need to derive utilization. Requirements can take on many useful forms, like CPU seconds consumed per second or consumed in a peak workload hour, IO operations performed per hour or in a single hour, or megabytes transferred per second or per hour. We can also change the tense from the past, "CPU seconds used yesterday between 9 a.m. and 10 a.m." to "How much CPU is the application now consuming each second?" or to the future, "How much CPU time do we expect the application to consume during next year's seasonal peak?" Don't tie yourself to a single rigid requirement definition. Throughout your work, allowing a flexible requirements definition will help bring clarity to an otherwise muddy situation.