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