Contribution 48 - Revision history

Egarson at 21:04, 23 June 2008

Egarson — Mon, 23 Jun 2008 21:04:36 GMT

←Older revision		Revision as of 21:04, 23 June 2008
Line 23:		Line 23:
	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

-	'''* Footnotes *'''	+	'' Footnotes ''

	[1] - A tank, despite its extremely dubious purpose, is still an engineering marvel.		[1] - A tank, despite its extremely dubious purpose, is still an engineering marvel.

Egarson: /* Context is King, and Simplicity its Humble Servant */

Egarson — Mon, 23 Jun 2008 21:04:13 GMT

Context is King, and Simplicity its Humble Servant

←Older revision		Revision as of 21:04, 23 June 2008
Line 16:		Line 16:

	So, while newsgroups rage with the flames of technology debates of X vs Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more than others when there is no guiding ''context'' to act as a trump card.		So, while newsgroups rage with the flames of technology debates of X vs Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more than others when there is no guiding ''context'' to act as a trump card.
-
-	'''* VERY MUCH MORE ROUGH *'''
-
-	[I want to better tie the role between simplicity and context. This is the start of that effort.]
-
-	'''An Onion-Shaped King'''
-
-	Context is shaped like an onion, with concentric rings that go from the outer layer representing forces at the system and environmental level (sometimes the only place where architects are active), through to design-level forces and finally converging on the smallest part in the middle, perhaps individual lines of code. Outer layers influence inner ones, and irrespective of whether architects exert influence on inner layers (in a role akin to that of master mechanics at a Mercedes-Benz factory), their decisions reverberate through to the core of the system.
-
-	'''The New Simplicity'''
-
-	A revolution is underfoot in our industry: for the first time, programmers are starting to exert an influence on the relative popularity of ''mass-market'' software technologies. Until now, mass-market technologies have largely been thrust upon the average programmer by the big players.
-
-	The new simplicity bucks this trend, and we now see industry reacting to programmers who are voting with their feet. As an example of this, popular execution environments (i.e. the .NET CLR and the Java Virtual Machine) are being reworked to accommodate new languages that have one overriding and unifying theme: simplicity. We see Microsoft recapitulate (to a certain extent) from the WS-* Web Services vision and introduce first-class support for the RESTful architectural style in .NET 3.5.
-
-	The New Simplicity is percolating throughout our industry in a myriad of ways; the architectures you work with would do well to pay heed to this revolution.

	Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.		Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.

Egarson at 22:48, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:48:04 GMT

←Older revision		Revision as of 22:48, 9 June 2008
Line 38:		Line 38:

	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-
-	'''* SCRATCH PAD *'''
-
-	This is my area of half-finished thoughts and random musings on the topic.
-	--
-	Heterogeneity wins.
-	--
-	The old adage - or at least, as 'old' as an adage can be in our nascent engineering domain - of the so-called Golden Triangle that states, "Fast, Cheap, Good - Pick Two" is related to context.
-	--

	'''* Footnotes *'''		'''* Footnotes *'''

Egarson at 22:46, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:46:51 GMT

←Older revision		Revision as of 22:46, 9 June 2008
Line 36:		Line 36:

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

	'''* SCRATCH PAD *'''		'''* SCRATCH PAD *'''

Egarson at 22:46, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:46:08 GMT

←Older revision		Revision as of 22:46, 9 June 2008
Line 35:		Line 35:
	Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.		Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.

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

	'''* SCRATCH PAD *'''		'''* SCRATCH PAD *'''

Egarson at 22:28, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:28:14 GMT

←Older revision		Revision as of 22:28, 9 June 2008
Line 13:		Line 13:
	Historically, there have been some fascinating examples of the influence that context can have on architecture. A favorite example involves the database selected to support an ambitious new software system for a modern battlefield tank [1]. (Deciding what database to use is not usually architecturally significant; this example merely serves to illustrate a point).		Historically, there have been some fascinating examples of the influence that context can have on architecture. A favorite example involves the database selected to support an ambitious new software system for a modern battlefield tank [1]. (Deciding what database to use is not usually architecturally significant; this example merely serves to illustrate a point).

-	When it came time to choose the database, the ~~architects tried quite a few~~. They found that while the tank was moving quickly over undulating terrain, the majority of the databases ~~would be~~ capable of supporting ~~the~~ throughput required of the navigation and targeting systems ~~in this scenario~~. But they were taken by surprise when they discovered that firing the main gun on the tank caused such a strong electromagnetic pulse that it totally crashed the on-board systems and of course the database along with it! ~~Now, you can easily imagine that on~~ a modern battlefield, a tank without its software running is quite literally in the dark. In this context, recovery time was the overwhelming factor in the choice of database, and no database did that better at the time than InterBase [2], and that is why it was chosen for the M1 Abrams tank.	+	When it came time to choose the database, the team assessed many. They found that while the tank was moving quickly over undulating terrain while tracking a target, the majority of the databases were capable of supporting this maximal throughput required of the navigation and targeting systems. But they were taken by surprise when they discovered that firing the main gun on the tank caused such a strong electromagnetic pulse that it totally crashed the on-board systems and of course the database along with it! On a modern battlefield, a tank without its software running is quite literally in the dark. In this context, ''recovery time'' was the overwhelming factor in the choice of database, and no database did that better at the time than InterBase [2], and that is why it was chosen for the M1 Abrams tank.

	So, while newsgroups rage with the flames of technology debates of X vs Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more than others when there is no guiding ''context'' to act as a trump card.		So, while newsgroups rage with the flames of technology debates of X vs Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more than others when there is no guiding ''context'' to act as a trump card.

Egarson at 22:23, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:23:43 GMT

←Older revision		Revision as of 22:23, 9 June 2008
Line 7:		Line 7:
	One of the most valuable lessons that I have learned as a software architect is that context is king, and simplicity its humble servant. What this means in practical terms is that context is the only force that trumps simplicity when making architectural decisions.		One of the most valuable lessons that I have learned as a software architect is that context is king, and simplicity its humble servant. What this means in practical terms is that context is the only force that trumps simplicity when making architectural decisions.

-	When I say context, I refer not only to high-level, immediate forces such as business ~~strategy~~, but also to ~~external~~ elements such as emerging technologies and thought leadership on diverse topics. Indeed, good architects keep track of several fast-moving targets.	+	When I say context, I refer not only to high-level, immediate forces such as key business drivers, but also to elements in the periphery, such as emerging technologies and thought leadership on diverse topics. Indeed, good architects keep track of several fast-moving targets.

-	What constitutes good architecture? It is the product of decisions made within a context usually tainted with multiple competing priorities. Those competing priorities mean that sometimes the most important decisions are not about what you put in, but rather what you omit. The currency of good architecture is simply astute decision-making.	+	What constitutes good architecture? It is the product of decisions made within a context usually tainted with multiple competing priorities. Those competing priorities mean that sometimes the most important decisions are not about what you put in, but rather what you omit. The currency of good architecture is simply astute decision-making (while the products are all only about communicating your intent).

	Historically, there have been some fascinating examples of the influence that context can have on architecture. A favorite example involves the database selected to support an ambitious new software system for a modern battlefield tank [1]. (Deciding what database to use is not usually architecturally significant; this example merely serves to illustrate a point).		Historically, there have been some fascinating examples of the influence that context can have on architecture. A favorite example involves the database selected to support an ambitious new software system for a modern battlefield tank [1]. (Deciding what database to use is not usually architecturally significant; this example merely serves to illustrate a point).

Egarson at 22:21, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:21:05 GMT

←Older revision		Revision as of 22:21, 9 June 2008
Line 1:		Line 1:
-	~~'''~~Context is King, and Simplicity its Humble Servant~~''' - [[Edward Garson]]~~	+	== Context is King, and Simplicity its Humble Servant ==

	I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively ''there are no ideals''. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.		I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively ''there are no ideals''. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.
Line 34:		Line 34:

	Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.		Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.
		+
		+	[[Edward Garson]]

	'''* SCRATCH PAD *'''		'''* SCRATCH PAD *'''

Egarson at 22:18, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:18:02 GMT

←Older revision		Revision as of 22:18, 9 June 2008
Line 1:		Line 1:
-	'''Context is King, and Simplicity its Humble Servant'''	+	'''Context is King, and Simplicity its Humble Servant''' - [[Edward Garson]]

	I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively ''there are no ideals''. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.		I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively ''there are no ideals''. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.

Egarson at 22:17, 9 June 2008

Egarson — Mon, 09 Jun 2008 22:17:31 GMT

←Older revision		Revision as of 22:17, 9 June 2008
Line 50:		Line 50:
	[2] - Interestingly, InterBase had an architecture that caused disk-writes to leave the database in an always-consistent state. This is one reason that contributes to its ability to recover from hard failures so quickly.		[2] - Interestingly, InterBase had an architecture that caused disk-writes to leave the database in an always-consistent state. This is one reason that contributes to its ability to recover from hard failures so quickly.

-	~~'''~~[[~~97_Things_Every_Software_Architect_Should_Know#Contributions~~]]~~'''~~	+	Back to [[97 Things Every Software Architect Should Know]] home page