Contribution 10

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(I hadn't finished)
Line 19: Line 19:
By [[Keith Braithwaite]]
By [[Keith Braithwaite]]
-
(Edited RMH 5/29/2008)
+
(Edited RMH 5/29/2008) (And will be edited some more in future by KB)
This work is licensed under a
This work is licensed under a

Revision as of 16:45, 1 June 2008

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.

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.

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.

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.

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 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.

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.


By Keith Braithwaite

(Edited RMH 5/29/2008) (And will be edited some more in future by KB)

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools