Missing layers of SOA

Attention is starting to shift from the lower levels of SOA — where people argue about ESB, SOAP vs REST, security and other message-level minutiae — up to layers that merit a lot more thought than they've so far enjoyed in SOA debate. I'm talking here about things like registry, policy, governance, semantics and — most important of them all — business process management.

Talking to vendors like Digital Evolution and Blue Titan, both of whom have a somewhat broader view of the SOA fabric than vendors with less of a specialist commitment to SOA, a picture has emerged of four separate layers to the SOA stack. To my mind, that still misses out another, fifth, layer that has to be added before you get the full picture. These vendors miss out that layer because it's more application than infrastructure, which is fair enough. But to their customers it's the most important one because it's where they earn the payback for implementing SOA (or not, as the case may be).

So let's work through those five layers and see how they stack up. I'm going to start from the bottom up (ie, in reverse order). And since this will probably end up as a powerpoint slide in a presentation (and indeed a diagram in a report), I've decided to label each of them with a short, generic term that describes the principal actors in each layer.

5. Routers. This is the layer that gets the lion's share of the attention at the moment. It's where all the messaging takes place, as directed by the routers. It's a crucial layer (as they all are), which is why there's so much focus on ESB at present. But it is just the base. You need much more before you have a fully functioning SOA.

4. Monitors. This covers classic monitoring and management products, the focus of our new SOA Management 2005 Report. They make sure that policy is being properly enforced by the routers and report back on what's going on down in the messaging layer.

3. Registries. This is where everything gets recorded. Some people might class it as two layers; there's certainly a lot going on here. The recording includes identity information as well as policy settings. There may be taxonomies here too. The common factor across all these functions is that we're talking about a trusted system of record, which is why we use the word 'registry', with its implication of some kind of formal registration process.

2. Governors. This is often conflated with the registry layer but it's too important to get lost down there. We're going to be hearing a lot more about this layer over the course of this year. As the name suggests, governors do governance. They administer the setting and changing of all the shared information that's then stored in the registries and enforced by the monitors. This includes adminstration of policy, identity, business semantics, process flows, and everything else the infrastructure needs to function. Note that I've started to introduce business logic elements here as well as infrastructure settings, because all these elements need to be driven by business requirements and ought not to be isolated from business oversight.

1. Decisioneers. Somehow this layer seems to have been forgotten in all the excitement about SOA technology. But it's where the real action happens. It's where all the decisions are taken that then flow down through the architecture. It has often been known as BPM (business process management) but I think it needs to move away from that term. BPM has too many overtones of people sitting in ivory towers drawing up flowcharts that bear little resemblance to business reality. Also people think it has something to do with BPEL, which as an execution language resides in the governors layer in this schematic rather than this top layer. Finally, BPM as a term doesn't take into account key decision-making about elements such as security and quality of service. And yes, the resonance of the word 'decisioneers' with what used to be called 'decision support' software is deliberate — it probably does look like some sort of dashboard. This layer is where business people interact with the infrastructure to adapt it to their needs. It's where SOA actually delivers utility to the business.

Do you agree? I'd welcome your comments.

posted by Phil Wainewright 4:10 PM (GMT) | comments | link