Contribution 22

From WikiContent

Revision as of 13:59, 28 May 2008 by Rmonson (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

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