Chapter 2. Drawing SOA Architecture

Let's get organized! In Chapter 1, we challenged the prevailing view that SOA is really just a tidying-up of application integration, which, for too many years, has been built haphazardly, without a carefully-conceived architectural blueprint. SOA, according to this interpretation, is not about building new business functionality but about organizing existing systems. The purpose of an SOA architecture document, if you take this view, is not to describe how to build a challenging new application, but to present what is already there as methodically as possible. There's an alphabet soup of architectural documentation approaches that go hand-in-hand with this brand of SOA (MDA, TOGAF, DODAF, MODAF, and the less ostentatious non-acronym Zachman), and each system integrator has its own variant.

But, as we have already argued, SOA is more than merely getting organized. Its principal mandate is to build something new; indeed, SOA is fundamentally about building new processes. We consider an approach to SOA architecture that is, yes, methodical, but has the burden of actually designing new and challenging orchestration and ESB processes. We use the strange but effective combination of UML, BPMN, 4+1, ARIS methodology, and Service Control Architecture (SCA) to explore how to draw SOA architecture. (It's a cocktail that's never been served in the application integration world!) We focus on one aspect of the architecture: the processes and services of the Logical view.