Contribution 10

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (18:49, 2 July 2008) (edit) (undo)
(sub 500 words!)
 
(5 intermediate revisions not shown.)
Line 1: Line 1:
== Quantify ==
== Quantify ==
-
System architecture is largely the domain of so-called "non-functional" requirements. These are requirements that describe what qualities a system should exhibit while it is meeting the functional dependencies that are its purpose. Often a system that meets the functional dependencies but does so too slowly, or using too many resources, or in a way that users find difficult, or otherwise fails to exhibit these qualities, is of little value. A large part of the architect's role is to have a care that the intended solution will exhibit these qualities.
+
"Fast" is not a requirement. Neither is "responsive". Nor "extensible". The worst reason why not is that you have no objective way to tell if they're met. But still users want them.
-
Like any other kind of requirement, we seek to write these qualities down. This is difficult and frequently vague adjectives are allowed to stand as statements of intent for a new system: "flexible", "maintainable" and the rest.
+
The architect's role is largely to help the system have these qualities. And to balance the inevitable conflicts and inconsistencies between them. Without objective criteria architects are at the mercy of capricious users ("no, I won't accept it, still not fast enough") and of obsessive programmers ("no, I won't release it, still not fast enough").
-
In every case (yes even "usable", with effort) the phenomena can be quantified, measured, and thresholds set. If this is not done, then there can be no basis for acceptance of the system by its users, no guidance for its builders, as they work, no vision for those architecting it.
+
As with all requirements we seek to write down these desires. Too often then the vague adjectives come out: "flexible", "maintainable" and the rest. It turns out that in every case (yes even "usable", with effort) these phenomena can be quantified and thresholds set. If this is not done then there is no basis for acceptance of the system by its users, valuable guidance is stolen from its builders as they work, and the vision is blurred 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.
+
Some simple questions to ask: 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 should be in the business case for the system 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. Then go get them.
-
In many cases, 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.
+
The next time someone tells you that a system needs to be "scalable" ask them where from and why these users are going to come. Ask how many and by when? Reject "Lots" and "soon" as answers.
-
The criteria must always be given as a range: the least possibly acceptable, the nominal, and the most conceivable. 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.
+
Uncertain quantitative criteria (which in mainstream development these will be—hard real–time folks have their own problems) must be given as a range: the least acceptable, the nominal, and the most worth paying for. If this range cannot be given, then the required behavior is not understood. As an architecture unfolds it can be checked against these criteria to see if it is (still) in tolerance. As the performance against some criteria drifts over time, valuable feedback is obtained.
-
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" to pay for actual performance trials, then there is a good chance that performance is not important.
+
Finding these ranges 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 performance trials, then more than likely performance doesn't matter. You are then free to focus your architectural efforts on aspects 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 we won't pay to go below that." Now ''that's'' a ''requirement''.
- 
- 
By [[Keith Braithwaite]]
By [[Keith Braithwaite]]
-
(Edited RMH 5/29/2008)
 
This work is licensed under a
This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
- 
Back to [[97 Things Every Software Architect Should Know]] home page
Back to [[97 Things Every Software Architect Should Know]] home page

Current revision

Quantify

"Fast" is not a requirement. Neither is "responsive". Nor "extensible". The worst reason why not is that you have no objective way to tell if they're met. But still users want them.

The architect's role is largely to help the system have these qualities. And to balance the inevitable conflicts and inconsistencies between them. Without objective criteria architects are at the mercy of capricious users ("no, I won't accept it, still not fast enough") and of obsessive programmers ("no, I won't release it, still not fast enough").

As with all requirements we seek to write down these desires. Too often then the vague adjectives come out: "flexible", "maintainable" and the rest. It turns out that in every case (yes even "usable", with effort) these phenomena can be quantified and thresholds set. If this is not done then there is no basis for acceptance of the system by its users, valuable guidance is stolen from its builders as they work, and the vision is blurred of those architecting it.

Some simple questions to ask: 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 should be in the business case for the system 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. Then go get them.

The next time someone tells you that a system needs to be "scalable" ask them where from and why these users are going to come. Ask how many and by when? Reject "Lots" and "soon" as answers.

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

Finding these ranges 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 performance trials, then more than likely performance doesn't matter. You are then free to focus your architectural efforts on aspects 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 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