Contribution 18

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m
m
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.

Revision as of 12:02, 12 June 2008

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.

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 Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools