How Many Architectures Do You Need?
Not long after we debunked the distinction between Event-Driven Architecture (EDA) and Service-Oriented Architecture (SOA) did we become aware of yet another architectural TLA (three-letter acronym): Process-Oriented Architecture (POA). Proponents of POA describe an architecture that leverages processes as the fundamental element of the architecture. POA leverages SOA, to be sure, but relegates SOA to a technical role that deals exclusively with exposing IT functionality as Services.
If your jargon alarm is ringing in your head at this point, well, you’re not alone. SOA, POA, EDA, not to mention n-tier architectures — just how many architectures do we need, anyway? It seems that as information technology (IT) finally gets a handle on what software architecture is, now everybody wants to create a new one. The danger of this trend is clear: if different camps within IT fragment along architectural lines, then we run the risk of adding siloed architectures to siloed operating systems and siloed applications — and the last thing we need is more silos. A natural reaction might be to proclaim that “my architecture is better than your architecture,” and being ZapThink, you know we’ll trumpet SOA. The truth of the matter, however, is more complex than some “us vs. them” situation. The real problem lies in subtle shadings on the definitions of terms. As long as the IT world can move beyond such relatively trivial misunderstandings, then we’ll be able to avoid the fragmentation of architectures, and move toward a single, broadly acceptable architectural approach.
Shades of Meaning
The confusion begins with subtle distinctions in the meaning of the word architecture. Architecture can mean a set of best practices, or a discipline — in other words, something you do. The other meaning of architecture is a particular model or design of a system — something you create. Putting these definitions together, the practice of architecture (meaning 1) consists of creating architectures (meaning 2).
The second point of clarification we must make is the distinction between architecture and an architectural view. An architectural view is essentially one perspective on the architecture of a system. A great way to understand architectural views is to consider the fable of the four blind men and the elephant. As you may remember, four blind men were asked to describe an elephant, and each one touched a different part of the animal. The one who touched the trunk thought the elephant was like a hose, another who grasped the trunk concluded it was a snake, the one who touched the leg thought the elephant was like a tree, and the fourth blind man, after discovering the elephant’s side, concludes that it was like a wall.
Well, architecture is much like the elephant, and most people are much like the blind men who only see the architecture from one point of view. People who focus on computers, networks, and applications see architecture in terms of the organization and principles guiding those computers, networks, and applications. However, people who focus on writing software see architecture in terms of the organization of the applications and other software components. Likewise, if you’re focused on business processes, then you’ll likely see architecture as the design and organization of processes that occur throughout the organization.
As with the blind men, all of these points of view have some aspect of the truth, yet none of them is complete. A sighted person would see the elephant has parts that look and function like a hose, tree, snake, or wall, but the elephant is not entirely like any of these. When it comes to architecture, it’s important to have people who are experienced with viewing IT in different ways, but it’s also important to have people with the big picture as well. Architectural views can be especially confusing, because people often consider the views to be architectures in their own right. For example, systems architectures, technical architectures, and information architectures are all architectures in their own right, but are also simply different views of a broader notion of architecture that encompasses all of the views.
Here’s where the confusion occurs: POA is actually one view. Sometimes people think of SOA as a single view, but ZapThink considers SOA to be the broader, encompassing notion that brings together all of the views. If you define SOA in an overly narrow sense as solely being a bottom-up approach, then you’re essentially identifying SOA as a technical architecture view. As a result, you would need to define a separate process-oriented view, which you could call POA. Since ZapThink’s definition of SOA is broader, we include POA as an integral part of the definition. For us, SOA is process-centric, and it’s a best practice to tackle architecture both top-down as well as bottom-up. Neither approach is sufficient on its own — you shouldn’t have SOA without POA, and you also shouldn’t have POA without SOA.
The Role of Reference Architectures
Fortunately, ZapThink is not alone in our efforts to clear up all this confusion. Groups such as SOA Blueprints and the OASIS SOA Reference Model Technical Committee are hammering out reference architectures and frameworks — essentially, sample documents and other tools that architects can use as starting points for their own architectural initiatives. But there is still the open question of whether we need a single reference architecture model that encompasses all of the views, or separate models for different views. Let’s say for the sake of argument you do go with three reference models, one for SOA, one for EDA, and one for POA. Then wouldn’t you need some sort of overarching reference model that encompassed (or at the least, coordinated) all three? And wouldn’t that broader reference model be fundamentally Service-oriented in nature?
ZapThink’s perspective is that the broader principle of Service Orientation should lead to the single, encompassing reference model — one that is Service-oriented, process-oriented and event-driven all at once. The real argument then is over what to call the encompassing model. Do you restrict the “SOA” term to the narrower, more technical model, or do you expand the term “SOA” to the broader model? You could call it Fred for all we care — we just care that the terminology doesn’t get in the way of successful architectures and their associated implementations. Sometimes too much time is spent arguing over the terminology, and not enough over the best way to do things!
Then there’s the additional question as to whether the narrower SOA, EDA, and POA models should be distinct models — does that distinction really clear anything up, or does it just add to the confusion? If SOA should be event-driven and process-oriented, and EDA should be Service-oriented, and POA — you get the picture — then is it really a useful abstraction to distinguish these three into separate models? The answer is, it depends on what the models are attempting to represent. If these narrower models actually represent separate views within the context of a broader coordinating model, then they promise to be quite useful. The last thing we want to do, however, is fragment the practice of architecture into several TLA silos.
The ZapThink Take
ZapThink has actually been talking about architectural views for a few years now, but we didn’t invent them by any means. In fact, Philippe Kruchten first described views in his 1995 article The 4+1 View Model of Architecture. ZapThink has taken Kruchten’s original 4+1 View Model and modified it for SOA. The biggest difference for us is that in his model, the extra “+1” view is the Use Case View, but in SOA, the architecture doesn’t address individual use cases, but should rather be designed to respond to as-yet undefined business requirements. So the Use Case View takes on a greater importance, as the Service-oriented architect must coordinate the other views to maintain the agility benefit of the architecture over time.
Clearly, when we talk about SOA in this context, we’re referring to the broader perspective that encompasses all of the individual views. However, above all else, when we talk about SOA, we’re referring to the practice more than the creation. If you think of architectures as static creations, you’re not likely to build flexibility into the architecture. SOA, however, must be flexible enough to provide agility in the face of unpredictable business change. The only credible way to explain SOA, therefore, is not to explain what it is, but rather, how to do it.