Contribution 18 - Revision history

KeithBraithwaite: added one more clause re differences (6 words)

2008-07-05T23:03:06Z

added one more clause re differences (6 words)

←Older revision		Revision as of 23:03, 5 July 2008
Line 5:		Line 5:
	In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multi–faceted, fuzzy, messy world intrudes. Worse yet, business doesn't even deal with "the world", it deals with people's opinions about aspects of situations in parts of the world. One response is to deem the domain to be technical and apply a unique solution by ''fiat''. But reality is that which does not go away when one stops believing in it, and the messiness always returns as the business evolves. Thus are born enterprise data teams, and so forth, who spend all their (very expensive) time trying to tame existential dread through DTD wrangling. Paying customers tend to find the level of responsiveness that comes form this somewhat unsatisfactory.		In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multi–faceted, fuzzy, messy world intrudes. Worse yet, business doesn't even deal with "the world", it deals with people's opinions about aspects of situations in parts of the world. One response is to deem the domain to be technical and apply a unique solution by ''fiat''. But reality is that which does not go away when one stops believing in it, and the messiness always returns as the business evolves. Thus are born enterprise data teams, and so forth, who spend all their (very expensive) time trying to tame existential dread through DTD wrangling. Paying customers tend to find the level of responsiveness that comes form this somewhat unsatisfactory.

-	Why not face up to the reality of a messy world and allow multiple, inconsistent, overlapping representations, services, solutions? As technologists we recoil in horror form this. We imagine terrifying scenarios: inconsistent updates, maintenance overhead, spaghetti–plates of dependencies to manage. But let's take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated values arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the non–functional properties of a mart. The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing. These have very different rates of update and query, very different throughput, perhaps very different volumes. This is the key: sufficiently different non–functional properties of a sub–system create a boundary across which managing inconsistent representations is tractable.	+	Why not face up to the reality of a messy world and allow multiple, inconsistent, overlapping representations, services, solutions? As technologists we recoil in horror form this. We imagine terrifying scenarios: inconsistent updates, maintenance overhead, spaghetti–plates of dependencies to manage. But let's take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated values arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the non–functional properties of a mart. The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing. These have very different rates of update and query, very different throughput, different rates of change of design, perhaps very different volumes. This is the key: sufficiently different non–functional properties of a sub–system create a boundary across which managing inconsistent representations is tractable.

	Don't go duplicating representations, or having multiple transports just for the fun of it, but do always consider the possibility that decomposition of your system by non–functional parameters may reveal opportunities to allow diverse solutions to your customers' advantage.		Don't go duplicating representations, or having multiple transports just for the fun of it, but do always consider the possibility that decomposition of your system by non–functional parameters may reveal opportunities to allow diverse solutions to your customers' advantage.

KeithBraithwaite: /* There Can be More than One */

2008-07-05T13:39:36Z

There Can be More than One

←Older revision		Revision as of 13:39, 5 July 2008
Line 1:		Line 1:
	== There Can be More than One==		== There Can be More than One==

		+	It seems to be a never–ending source of surprise and distress to system builders that one data model, one message format, one message transport—in fact, exactly ''one'' of any major architectural component, policy or stance—won't serve all parts of the business equally well. Of course: an enterprise ( "enterprise" is red flag #1) big enough to worry about how many different "Account" tables will impact system building next decade is most likely too big and diverse for one "Account" table to do the job anyway.

		+	In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multi–faceted, fuzzy, messy world intrudes. Worse yet, business doesn't even deal with "the world", it deals with people's opinions about aspects of situations in parts of the world. One response is to deem the domain to be technical and apply a unique solution by ''fiat''. But reality is that which does not go away when one stops believing in it, and the messiness always returns as the business evolves. Thus are born enterprise data teams, and so forth, who spend all their (very expensive) time trying to tame existential dread through DTD wrangling. Paying customers tend to find the level of responsiveness that comes form this somewhat unsatisfactory.
		+
		+	Why not face up to the reality of a messy world and allow multiple, inconsistent, overlapping representations, services, solutions? As technologists we recoil in horror form this. We imagine terrifying scenarios: inconsistent updates, maintenance overhead, spaghetti–plates of dependencies to manage. But let's take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated values arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the non–functional properties of a mart. The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing. These have very different rates of update and query, very different throughput, perhaps very different volumes. This is the key: sufficiently different non–functional properties of a sub–system create a boundary across which managing inconsistent representations is tractable.
		+
		+	Don't go duplicating representations, or having multiple transports just for the fun of it, but do always consider the possibility that decomposition of your system by non–functional parameters may reveal opportunities to allow diverse solutions to your customers' advantage.

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

KeithBraithwaite: clearing the decks, taking another run

2008-07-04T22:11:45Z

clearing the decks, taking another run

←Older revision		Revision as of 22:11, 4 July 2008
Line 1:		Line 1:
	== There Can be More than One==		== There Can be More than One==

-	We urge programmers: "Don't Repeat Yourself". We seek to express every idea "Once and Only Once". This kind of thinking translates into architecture in the form of the "Enterprise" this, that and the other. The Enterprise Data Model, say, or the Enterprise Message Bus. These carry a connotation of being a single solution used for all systems within an organization. Which has its benefits. And its costs. And like all solutions, creates its own problems.

-	If all the facets of an organization's IT world had the same usage patterns, the same latency bounds, the same real-time constraints and all the other characteristics that architecture addresses, then the cost of using the Enterprise solution (there always is a cost) would be easy to justify. But they don't.
-
-	It's certainly more convenient for us as technologists to build systems if there is only one: operating system, platform, programming language, message format, message bus, data model, data base, component container, component framework, GUI toolkit, web toolkit, web browser, etc etc etc. That world is clean, efficient, and wholly imaginary. Striving to get into it often does more harm than good to the paying customer.
-
-	Axiom: by the time a business is large enough for someone to start thinking about the need for an Enterprise solution then it will be composed of the integrated systems of several businesses. There will be at lest one of other businesses acquired in the past, or the same business as it was in the past. Either way, there will be some duplication somewhere. We abhor duplication. But why?
-
-	We've learned to shun duplication of representation, of data, of logic, because it leads to well-known classes of failure. For example, we normalize out duplication in relational database schemas to make certain classes of update anomaly impossible. But then we de–normalize read–only views for performance. And the limit of that is the data warehouse—a giant pile of denormalized, duplication inconsistent with it's source data stores. And no trouble at all because of that because it never receives ad-hoc updates. This duplication and inconsistency is safe because the rates of change of data, and distribution of changes over time, are so very different.
-
-	Let's say that our team maintains lots of little websites for lots of different customers. Let's even say that they are all implemented with the same stack. One day a new requirement comes along that is prohibitively expensive to meet with that stack. But the customer is a valuable one. What to do? Could we bear to implement ''just this one site'' using a new tool with faster turnaround? Maybe we can. But, says our software engineering conscience, what if...what if we have to change one of the old ones and we forget to update the new one in the same way? Or vice–versa? What if, what if? Well, what does the data tell us? How often do those old sites change? Oh, between once every two years and never. Well then! And since they all have comprehensive automated functional tests (right? right) we'll know if we broke them, so off we go.
-
-	The default stance should be towards avoiding duplication, avoiding inconsistency, we know the pain too well. But never forget to stop an think, and recall that down in the bottom of the big of tricks is ''multiplicity of solutions''. Dismiss it 99 time out of 100, but dismiss it actively, not by reflex. And that one time it will save your project.

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

KeithBraithwaite: filled in more content. 579 words

2008-06-30T16:12:43Z

filled in more content. 579 words

←Older revision		Revision as of 16:12, 30 June 2008
Line 1:		Line 1:
	== There Can be More than One==		== There Can be More than One==

-	~~Many IT workers seem to have a fetish for uniqueness.~~ We urge programmers: "Don't Repeat Yourself". We seek to express every idea "Once and Only Once". This ~~often~~ translates into architecture in the form of the "Enterprise" this, that and the other. The Enterprise Data Model, say, or the Enterprise Message Bus. These carry a connotation of being a single solution used for all systems within an organization. Which has its benefits. And its costs. And like all solutions, creates its own problems.	+	We urge programmers: "Don't Repeat Yourself". We seek to express every idea "Once and Only Once". This kind of thinking translates into architecture in the form of the "Enterprise" this, that and the other. The Enterprise Data Model, say, or the Enterprise Message Bus. These carry a connotation of being a single solution used for all systems within an organization. Which has its benefits. And its costs. And like all solutions, creates its own problems.

	If all the facets of an organization's IT world had the same usage patterns, the same latency bounds, the same real-time constraints and all the other characteristics that architecture addresses, then the cost of using the Enterprise solution (there always is a cost) would be easy to justify. But they don't.		If all the facets of an organization's IT world had the same usage patterns, the same latency bounds, the same real-time constraints and all the other characteristics that architecture addresses, then the cost of using the Enterprise solution (there always is a cost) would be easy to justify. But they don't.
		+
		+	It's certainly more convenient for us as technologists to build systems if there is only one: operating system, platform, programming language, message format, message bus, data model, data base, component container, component framework, GUI toolkit, web toolkit, web browser, etc etc etc. That world is clean, efficient, and wholly imaginary. Striving to get into it often does more harm than good to the paying customer.
		+
		+	Axiom: by the time a business is large enough for someone to start thinking about the need for an Enterprise solution then it will be composed of the integrated systems of several businesses. There will be at lest one of other businesses acquired in the past, or the same business as it was in the past. Either way, there will be some duplication somewhere. We abhor duplication. But why?
		+
		+	We've learned to shun duplication of representation, of data, of logic, because it leads to well-known classes of failure. For example, we normalize out duplication in relational database schemas to make certain classes of update anomaly impossible. But then we de–normalize read–only views for performance. And the limit of that is the data warehouse—a giant pile of denormalized, duplication inconsistent with it's source data stores. And no trouble at all because of that because it never receives ad-hoc updates. This duplication and inconsistency is safe because the rates of change of data, and distribution of changes over time, are so very different.
		+
		+	Let's say that our team maintains lots of little websites for lots of different customers. Let's even say that they are all implemented with the same stack. One day a new requirement comes along that is prohibitively expensive to meet with that stack. But the customer is a valuable one. What to do? Could we bear to implement ''just this one site'' using a new tool with faster turnaround? Maybe we can. But, says our software engineering conscience, what if...what if we have to change one of the old ones and we forget to update the new one in the same way? Or vice–versa? What if, what if? Well, what does the data tell us? How often do those old sites change? Oh, between once every two years and never. Well then! And since they all have comprehensive automated functional tests (right? right) we'll know if we broke them, so off we go.
		+
		+	The default stance should be towards avoiding duplication, avoiding inconsistency, we know the pain too well. But never forget to stop an think, and recall that down in the bottom of the big of tricks is ''multiplicity of solutions''. Dismiss it 99 time out of 100, but dismiss it actively, not by reflex. And that one time it will save your project.

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

KeithBraithwaite at 12:02, 12 June 2008

2008-06-12T12:02:01Z

←Older revision		Revision as of 12:02, 12 June 2008
Line 1:		Line 1:
	== There Can be More than One==		== There Can be More than One==

-	Many IT workers seem to have a fetish for uniqueness. We urge programmers: "Don't Repeat Yourself". ~~Express~~ every idea "Once and Only Once". This often translates into architecture in the form of the "Enterprise" this, that and the other. The Enterprise Data Model, say, or the Enterprise Message Bus. These carry a connotation of being a single solution used for all systems within an organization. Which has its ~~advantages~~. And like all solutions, creates its own problems.	+	Many IT workers seem to have a fetish for uniqueness. We urge programmers: "Don't Repeat Yourself". We seek to express every idea "Once and Only Once". This often translates into architecture in the form of the "Enterprise" this, that and the other. The Enterprise Data Model, say, or the Enterprise Message Bus. These carry a connotation of being a single solution used for all systems within an organization. Which has its benefits. And its costs. And like all solutions, creates its own problems.

	If all the facets of an organization's IT world had the same usage patterns, the same latency bounds, the same real-time constraints and all the other characteristics that architecture addresses, then the cost of using the Enterprise solution (there always is a cost) would be easy to justify. But they don't.		If all the facets of an organization's IT world had the same usage patterns, the same latency bounds, the same real-time constraints and all the other characteristics that architecture addresses, then the cost of using the Enterprise solution (there always is a cost) would be easy to justify. But they don't.

KeithBraithwaite at 13:08, 14 May 2008

2008-05-14T13:08:03Z

←Older revision		Revision as of 13:08, 14 May 2008
Line 9:		Line 9:
	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

KeithBraithwaite: begun

2008-05-14T13:06:23Z

begun

New page

== There Can be More than One==

Many IT workers seem to have a fetish for uniqueness. We urge programmers: "Don't Repeat Yourself". Express every idea "Once and Only Once". This often translates into architecture in the form of the "Enterprise" this, that and the other. The Enterprise Data Model, say, or the Enterprise Message Bus. These carry a connotation of being a single solution used for all systems within an organization. Which has its advantages. And like all solutions, creates its own problems.

If all the facets of an organization's IT world had the same usage patterns, the same latency bounds, the same real-time constraints and all the other characteristics that architecture addresses, then the cost of using the Enterprise solution (there always is a cost) would be easy to justify. But they don't.

By [[Keith Braithwaite]]

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