Contribution 22

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Architects focus is on the boundaries and interfaces)
Current revision (13:59, 28 May 2008) (edit) (undo)
 
(2 intermediate revisions not shown.)
Line 1: Line 1:
== Architects focus is on the boundaries and interfaces ==
== 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.
+
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. This is for many reasons easier said than done, at least if your intension is a working system in the end.
-
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.
+
Any system, natural or man-made, consists of a set of nested elements connected in such way that they satisfy some purpose. From the viewpoint of the beholder the system is only useful when all elements fulfill their objectives and the system as a whole serves its purpose, be it transport of people, production of oil or controlling the memory and disk usage in a computer.
-
The next thing is, how to do this in practice?
+
In the process of developing systems, it is the architect’s responsibility to ensure that the systems purpose is met within the limits of acceptable cost and time. As all well designed systems are decomposed according to natural boundaries in the problem domain the architect’s focus should be on the boundaries and interfaces. At the end, the final systems conceptual integrity and quality depends on this. How important this is is best illustrated by providing examples of heuristics used to guide architectural work. From Eberhardt Rechtin's book The Art of Systems Architecting, Second Edition, I found the following 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.
+
In many ways Service Oriented Architecture (SOA) addresses the intent found in the heuristics above, but talking with SOA practitioners make you aware of how hard this is in practice. In my experience the hardship of SOA boils down to two things: 1) the partitioning of the problem domain ( i.e. defining the boundaries in your business at an appropriate level of detail) and, 2) Lack of practical useful tools.
-
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.
+
There is 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 belongs together, and the interfaces between the contexts.
-
So the question how to do it in practice is still unanswered.
+
The true strength with context maps are the fact that in practice you start with the as-is situation, which means that the subsystems in existing legacy IT systems are identified as logical contexts, and the interfaces between them as they are described. The first thing you typically discover is lack of clear boundaries and simple interfaces. Most often the different contexts blurs into each other with rich and complex interfaces, typically implemented as database links or relations between entities.
-
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.
+
 
 +
The strength of this technique is that you need to know reality before you can change it. The context map is just the map required to guide your work.
-
WORK IN PROGRESS - NOT COMPLETE
 
By [[Einar Landre]]
By [[Einar Landre]]
 +
 +
(Edited RMH 5/28/2008)
This work is licensed under a
This work is licensed under a

Current revision

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. This is for many reasons easier said than done, at least if your intension is a working system in the end.

Any system, natural or man-made, consists of a set of nested elements connected in such way that they satisfy some purpose. From the viewpoint of the beholder the system is only useful when all elements fulfill their objectives and the system as a whole serves its purpose, be it transport of people, production of oil or controlling the memory and disk usage in a computer.

In the process of developing systems, it is the architect’s responsibility to ensure that the systems purpose is met within the limits of acceptable cost and time. As all well designed systems are decomposed according to natural boundaries in the problem domain the architect’s focus should be on the boundaries and interfaces. At the end, the final systems conceptual integrity and quality depends on this. How important this is is best illustrated by providing examples of heuristics used to guide architectural work. From Eberhardt Rechtin's book The Art of Systems Architecting, Second Edition, I found the following 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".

In many ways Service Oriented Architecture (SOA) addresses the intent found in the heuristics above, but talking with SOA practitioners make you aware of how hard this is in practice. In my experience the hardship of SOA boils down to two things: 1) the partitioning of the problem domain ( i.e. defining the boundaries in your business at an appropriate level of detail) and, 2) Lack of practical useful tools.

There is 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 belongs together, and the interfaces between the contexts.

The true strength with context maps are the fact that in practice you start with the as-is situation, which means that the subsystems in existing legacy IT systems are identified as logical contexts, and the interfaces between them as they are described. The first thing you typically discover is lack of clear boundaries and simple interfaces. Most often the different contexts blurs into each other with rich and complex interfaces, typically implemented as database links or relations between entities.

The strength of this technique is that you need to know reality before you can change it. The context map is just the map required to guide your work.


By Einar Landre

(Edited RMH 5/28/2008)

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools