Contribution 10 - Revision history

KeithBraithwaite: sub 500 words!

2008-07-02T18:49:05Z

sub 500 words!

←Older revision		Revision as of 18:49, 2 July 2008
Line 1:		Line 1:
	== Quantify ==		== 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~~.	+	"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.

-	~~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").	+	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").

-	~~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.	+	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. 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.	+	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 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.	+	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 ~~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~~.	+	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" (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.	+	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 ~~no need (and~~ we won't pay) to go below that." Now ''that's'' a ''requirement''.	+	"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]]

Rmonson at 13:30, 2 July 2008

2008-07-02T13:30:21Z

←Older revision		Revision as of 13:30, 2 July 2008
Line 1:		Line 1:
	== Quantify ==		== Quantify ==

-	"Fast" is not 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.	+	"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").		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").

KeithBraithwaite: punctuation tweks

2008-06-30T15:42:18Z

punctuation tweks

←Older revision		Revision as of 15:42, 30 June 2008
Line 1:		Line 1:
	== Quantify ==		== Quantify ==

-	"Fast" is not 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.	+	"Fast" is not 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").		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").
Line 9:		Line 9:
	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 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 ~~how~~ by when? Do not accept "lots" and "soon" as valid answers.	+	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.		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.

KeithBraithwaite: severe re–write to 570 words

2008-06-30T15:39:55Z

severe re–write to 570 words

←Older revision		Revision as of 15:39, 30 June 2008
Line 1:		Line 1:
	== Quantify ==		== 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~~.	+	"Fast" is not 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.

-	~~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 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").

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

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

-	~~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 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 how by when? Do not accept "lots" and "soon" as valid answers.

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

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

-	~~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.~~	+	"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''.
-		+
-	~~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]]		By [[Keith Braithwaite]]

KeithBraithwaite: /* Quantify */

2008-06-12T11:32:31Z

Quantify

←Older revision		Revision as of 11:32, 12 June 2008
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~~.	+	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.

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

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

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

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

-	~~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~~.	+	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]]		By [[Keith Braithwaite]]

-	(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
	[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

KeithBraithwaite: I hadn't finished

2008-06-01T16:45:35Z

I hadn't finished

←Older revision		Revision as of 16:45, 1 June 2008
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

Rmonson at 16:34, 29 May 2008

2008-05-29T16:34:08Z

←Older revision		Revision as of 16:34, 29 May 2008
Line 3:		Line 3:
	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.		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 ~~too often~~ vague adjectives are allowed to stand as statements of intent for a new system: "flexible", "maintainable" and the rest.	+	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.	+	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 cannot be answered then the need ~~which the system is being built to address~~ is not understood.	+	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.		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, 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.	+	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 ~~it doesn't need to be after all~~.	+	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]]		By [[Keith Braithwaite]]
		+
		+	(Edited RMH 5/29/2008)

	This work is licensed under a		This work is licensed under a

KeithBraithwaite: /* Quantify */

2008-05-24T10:13:23Z

Quantify

←Older revision		Revision as of 10:13, 24 May 2008
Line 1:		Line 1:
	== Quantify ==		== Quantify ==

-	It's ~~been said~~ that ~~one cannot manage what one cannot measure~~.	+	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.

-	~~This applies especially to the so-called "non-functional requirements" that are the traditional meat~~ of ~~software architecture. 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 cannot be answered then the business 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~~.	+	Like any other kind of requirement, we seek to write these qualities down. This is difficult and too often vague adjectives are allowed to stand as statements of intent for a new system: "flexible", "maintainable" and the rest.

-	~~Too often, 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") 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.	+	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 cannot be answered then the need which the system is being built to address 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, 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.		The criteria must always be given as a range: the least possibly acceptable, the nominal, 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 it doesn't need to be after all.		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 it doesn't need to be after all.
		+

	By [[Keith Braithwaite]]		By [[Keith Braithwaite]]

KeithBraithwaite: /* Quantify */

2008-05-12T14:39:48Z

Quantify

←Older revision		Revision as of 14:39, 12 May 2008
Line 3:		Line 3:
	It's been said that one cannot manage what one cannot measure.		It's been said that one cannot manage what one cannot measure.

-	This applies especially to the so-called "non-functional requirements" that are the traditional meat of software architecture. The questions to ask are simple. They include: how many? in what period? how often? increasing or decreasing? at what rate? If these cannot be answered then the business need is not understood.	+	This applies especially to the so-called "non-functional requirements" that are the traditional meat of software architecture. 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 cannot be answered then the business 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.

	Too often, 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") 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.		Too often, 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") 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.

KeithBraithwaite: one cannot manage what one cannot measure

2008-05-12T14:24:14Z

one cannot manage what one cannot measure

New page

== Quantify ==

It's been said that one cannot manage what one cannot measure.

This applies especially to the so-called "non-functional requirements" that are the traditional meat of software architecture. The questions to ask are simple. They include: how many? in what period? how often? increasing or decreasing? at what rate? If these cannot be answered then the business need is not understood.

Too often, 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") 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 criteria must always be given as a range: the least possibly acceptable, the nominal, 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 it doesn't need to be after all.

By [[Keith Braithwaite]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Software Architect Should Know]] home page