Contribution 18

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(begun)
Current revision (23:03, 5 July 2008) (edit) (undo)
m (added one more clause re differences (6 words))
 
(5 intermediate revisions not shown.)
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.
+
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.
-
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.
+
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, 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.
By [[Keith Braithwaite]]
By [[Keith Braithwaite]]
Line 9: Line 13:
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

Current revision

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

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