Contribution 10

From WikiContent

Revision as of 11:32, 12 June 2008 by KeithBraithwaite (Talk | contribs)
Jump to: navigation, search

Quantify

System architecture is largely the domain of the so-called "non-functional" requirements. A system is built to help its users meet their goals, and this is manifested by functional dependencies of outputs upon inputs. Often a system that meets these 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. These conditions are captured in the non-functional requirements: qualities a system should exhibit while it is meeting the functional dependencies that are its purpose.

Users tend to have non-functional requirements to do with response times, ease-of-use, ease of managing anticipated future needs and other aspects of how the system will fit into their working day. Other stakeholders in the construction of the system can have non-functional requirements to do with the computational resources used, the way that the system will recover from out-of-bound conditions, how easy it is to deploy and maintain, and other "back room" aspects of the life of the system.

A large part of the architect's role is to have a care that the intended solution will exhibit these qualities. And to strike a balance between the inevitable conflicts and inconsistencies between them. For example, to access my employer's network while on the road I need two pieces of hardware and two passwords. Not convenient (so usability is lower than it might be) but security is high.

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. While the questions are simple, the answers tend to be quite complicated. Non-functional 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. And the ranges will vary in different scenarios.

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. If you are currently fulfilling the role of system architect, ask yourself if you know the performance criteria of the system you are working on. How many concurrent users? How many at most? How many in the usual case? What's longest response time that's acceptable in the usual loading case? In the worst case? Repeat this for the other non-functional aspects of the system.

And then ask yourself how much it will cost to get (and keep) the system within those bounds. And if you don't know, ask yourself how not. Then ask your business sponsors what it is worth to them to have the system within those bounds. Hope that B < A.

If you employ an architect, and they haven't come to you for help in finding out the answers to these questions, ask them why not. And if you work for an architect and they haven't told you the answers, ask them why not, too.

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


This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools