SOA v POA, EDA, GDA

First of all a warning... I have an SOA hammer and maybe everything does look like a nail.

SOA - Service Orientation - I tend to see SOA has the bit where I stand looking at the toolbox wondering what I should use to get the job done, its key aim isn't to do the detail, its to help select the right tool to do the detail. In this SOA attempts to define the broad areas and capabilities, not to focus on specifics at the start. So starts by understanding the "What" of the enterprise, the broad "what do we do" questions, it then worries about "who" do we interact with and finally "why" do all these things work together. It doesn't deal with the "How" of implementation it just creates the framework within which that can be done.

There are other options as to where you start of course, and I'd like to start by saying if it works for you then fine, but I'm not liable to be joining you.

POA - Process Orientation - This is IMO the most broken model of all, often building on business school work of the 1990s it suggests that organisations are oriented around their processes and that by understanding the end-to-end processes. The problem is that businesses aren't oriented like this, processes go across many areas and process based implementation tends to lead to brittle and inflexible solutions. Organisations aren't process oriented. POA also actively prevents SOA as its a bugger to try and retro-fit decent service granularity into a process model, and equally if you just have lots of small components managed by big processes then its just Visual Cobol with components.

EDA - Event Driven - Identify the events first says this approach and then you can understand the business. The problem I have here is that this is to me just the capabilities bit of SOA, you need the encompassing service for two reasons. Firstly to provide context as to what the event is about and what is its surrounding business environment, and secondly to provide a place into which new business events can be added. Viewing businesses based on their events quickly creates large lists of events and its pretty tough to add a structure, even if you do event chaining, because it is just single events calling other single events. While not as bad as POA this approach still takes the approach that organistions operate based around single events rather than taking a more holistic view.

GDA - Goal Driven - Identify the business goals and you will then be able to move onto how to deliver against them. This isn't that bad an approach as Goals are often complex composite things for a business and they do help you understand the key drivers and principles of an organistion. The trouble is, particularly if you are more extreme and gather goals in a "flat" way rather than concerning yourself with the domain within which the goal is managed or attained means that you again have a set of singletons interacting which can make creating simple architectural solutions a bit of a challenge.

The good news is that all of these things are great second steps if you take a good business service oriented view. If you have one service that is best modeled by thinking of it as processes then POA within that service is a good thing. If you have a reactive system based around events then EDA will work within that service. If you have a goal oriented area that is best described in terms of its outcomes then GDA is right within that service. if its best to model Beliefs, Drivers and Intents then BDI is liable to work within that service. You could even say that SOA models the services, EDA the capabilities and the POA how some of those capabilities are implemented, but either way its the service that needs to come first.

EDA, POA, GDA and BDI and even OO are great ways to model how a service should work, or more specifically how the capabilities on a service should work. This is the key, EDA, POA and GDA are all aiming to define the capabilities that an organisation, enterprise or project should have, SOA aims to provide the mechanism for containment and abstraction for those capabilities and this is why it needs (IMO) to come first.

You don't start modelling an Object Model by listing out all the methods and attributes then trying to fit them into classes, you start with the classes then wonder what the methods and attributes should be, then worry about how to model their implementation. Its no different with SOA but operating at a business rather than a technical level. The first question is what are the containers, the buckets, the blobs... the services, then and only then should we worry about the capabilities, and once we have them we should worry about how you implement them.

Like with Web 2.0 v SOA its not actually one or the other. SOA provides the context, the others worry about the details.

Technorati Tags: SOA, POA, EDA, GDA, Service Architecture