Contribution 22

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Architects focus is on the boundaries and interfaces)
(Architects focus is on the boundaries and interfaces)
Line 3: Line 3:
Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, "divide an conquer" has been the mantra for dealing with complex and difficult problems. The challenge is that its easier said than done, at least if your intension is a working system at the end. Hacking something to pieces is seldom constructive.
Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, "divide an conquer" has been the mantra for dealing with complex and difficult problems. The challenge is that its easier said than done, at least if your intension is a working system at the end. Hacking something to pieces is seldom constructive.
-
Therefore the architects focus should be on the boundaries and interfaces when a large problem is partitioned, and later integrated into a working whole. At the end, the systems internal integrity and quality depends on this.
+
Therefore the architects focus should be on the boundaries and interfaces when a large problem is partitioned, and later integrated into a working whole. At the end, the final systems conceptual integrity and quality depends on this.
-
The next thing is, how to do this in practice?
+
Eberhardt Rechtin's book "The Art of Systems Architecting, Second Edition, Cith Mark W Maier" provide a set of useful heuristics: "Choose elements so they are as independent as possible", "Choose elements with low external complexity (simple interfaces) and high internal complexity" and finally, in the jargon of a software developer: "Maximize cohesion, Minimize coupling".
-
First of all there are some old heuristics that might help, if they do not add more to the confusion. Here goes:
+
-
Choose the element so they are as independent as possible, or in other words choose elements with low external complexity (simple) interfaces and high internal complexity. Expressed in the language of a software developer strive for high cohesion, low coupling.
+
Service Oriented Architecture (SOA) is based on the wisdom found in the heuristics listed above, but it has as well illustrated how hard it is to do in practice.
-
 
+
-
In many ways this is the idea behind SOA (Service Oriented Architecture), but experience has shown us that SOA a hard thing to do, especially in situations where there are legacy systems in place, legacy systems that for all practical purposes are huge monolithic monsters.
+
So the question how to do it in practice is still unanswered.
So the question how to do it in practice is still unanswered.
There is though one technique I have used with success, Eric Evan's Context Maps, a technique thoroughly described in his book Domain Driven Design. In short a context map is an informal map of model context extracted from internals of existing systems and the relationships between the contexts. The value provided by a context map is the ability to communicate how an existing software landscape is wired, what belong together, and the interfaces between the contexts.
There is though one technique I have used with success, Eric Evan's Context Maps, a technique thoroughly described in his book Domain Driven Design. In short a context map is an informal map of model context extracted from internals of existing systems and the relationships between the contexts. The value provided by a context map is the ability to communicate how an existing software landscape is wired, what belong together, and the interfaces between the contexts.
-
WORK IN PROGRESS - NOT COMPLETE
+
WORK IN PROGRESS - NOT COMPLETE (assumed completed by 22 May)
By [[Einar Landre]]
By [[Einar Landre]]

Revision as of 08:20, 19 May 2008

Architects focus is on the boundaries and interfaces

Since Lord Nelson destroyed the French and Spanish fleet at Trafalgar in 1805, "divide an conquer" has been the mantra for dealing with complex and difficult problems. The challenge is that its easier said than done, at least if your intension is a working system at the end. Hacking something to pieces is seldom constructive.

Therefore the architects focus should be on the boundaries and interfaces when a large problem is partitioned, and later integrated into a working whole. At the end, the final systems conceptual integrity and quality depends on this.

Eberhardt Rechtin's book "The Art of Systems Architecting, Second Edition, Cith Mark W Maier" provide a set of useful heuristics: "Choose elements so they are as independent as possible", "Choose elements with low external complexity (simple interfaces) and high internal complexity" and finally, in the jargon of a software developer: "Maximize cohesion, Minimize coupling".

Service Oriented Architecture (SOA) is based on the wisdom found in the heuristics listed above, but it has as well illustrated how hard it is to do in practice.

So the question how to do it in practice is still unanswered. There is though one technique I have used with success, Eric Evan's Context Maps, a technique thoroughly described in his book Domain Driven Design. In short a context map is an informal map of model context extracted from internals of existing systems and the relationships between the contexts. The value provided by a context map is the ability to communicate how an existing software landscape is wired, what belong together, and the interfaces between the contexts.

WORK IN PROGRESS - NOT COMPLETE (assumed completed by 22 May)

By Einar Landre

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools