Contribution 10

From WikiContent

Revision as of 13:30, 2 July 2008 by Rmonson (Talk | contribs)
Jump to: navigation, search

Quantify

"Fast" is not a requirement. Neither is "responsive". Nor "flexible", "maintainable" and the rest. They aren't requirements for several reasons the worst of which is that you have no way to determine objectively whether they have been met or not.

A large part of the architect's role is to have a care that the intended solution will exhibit these so-called "non-functional" qualities. And to strike a balance between the inevitable conflicts and inconsistencies between them. Without being able to tell, at any given time, which are met and which not the architect is at the mercy of the capricious user ("no, I won't accept it, still not fast enough") and of the obsessive programmer ("no, I won't release it, still not fast enough").

Like any other kind of requirement, we seek to write down these desired qualities. This is difficult and frequently vague adjectives are allowed to stand as statements of intent for a new system: "flexible", "maintainable" and the rest. It turns out that in every case (yes even "usable", with effort) the phenomena can be quantified and thresholds set. And when the system is built, its performance can be measured. If this is not done, then there can be no basis for acceptance of the system by its users, valuable guidance is stolen from its builders as they work, and the vision is obscured of those architecting it.

The questions to ask are simple. They include: how many? In what period? How often? How soon? Increasing or decreasing? At what rate? If these questions cannot be answered then the need is not understood. The answers to these questions should be in the business case for the system being proposed and if they are not, then some hard thinking needs to be done. If you work as an architect and the business hasn't (or won't) tell you these numbers, ask yourself why not. And then go get them.

The next time someone tells you that system needs to be "scalable" ask them where these users are going to come from, and why. Ask how many and by when? Do not accept "lots" and "soon" as valid answers.

Uncertain quantitative criteria (which, in mainstream development, these will be—hard real–time folks have their own problems) must always be given as a range: the least possibly acceptable, the nominal, and the most worth paying for. If this range cannot be given, then the required system behavior is not understood. As the architecture of the system unfolds, it can be checked against these criteria to see if it is (still) in tolerance. As the performance against some criteria drifts, valuable feedback about the architecture is obtained. And the ranges will vary in different scenarios.

Putting these ranges in place, and checking against them, is a time-consuming and expensive business. If no one cares enough about the system being "performant" (neither a requirement nor a word) to pay for actual performance trials, then there is a good chance that performance is not important. You are then free to focus your architectural thinking on other specks of the system that are worth paying for.

"Must respond to user input in no more than 1500 milliseconds. Under normal load (defined as...) the average response time must be between 750 and 1250 milliseconds. Response times less than 500 milliseconds can't be distinguished by the user, so no need (and we won't pay) to go below that." Now that's a requirement.

By Keith Braithwaite


This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools