Visual COBOL and Process SOA

I just read this piece on SOA and process it contains the line

"It turns out that what BPM terms as 'processes' is, in reality, a superset of the 'services' concept of SOA"

Now I have to take rather big issue with this as the concept that Process is a superset of Service means that at the top of the tree process is invoked and process is the primacy in an architecture. To me this traditional BPM thinking sums up why lots of BPM projects fail. Services have to be the primacy in an architecture (if they have a hierachy) as they provide the containment and structure for process and the link between process, workflow, orchestration, integration, technical implmentation and all the other elements. Services enable other approaches like Agent BDI (Beliefs Drivers Intent) to be integrated rather than relying on linear decision processes.

When will BPM people learn that containers are needed to link elements not just a series of Visual COBOL scripts that assume that everything is best done in a process. Its exactly the same as those folks who railed against OO in the 80s and 90s and preferred procedural code.

Releasing a Business SOA Method

Well thanks to the architecture community, CTO and partners I've managed to get the SOA Methodology released which has already had a degree of pickup from a few areas including some analysts saying good things about it. The SOA methodology is all about the creation of a Business SOA... As a quick summary its a methodology (which was first surfaced in the IEEE Software paper on definition of service) focused on business and IT working together to create the big picture Service architecture. This then has to be delivered using a full architecture and delivery approach, but at least everyone starts on the same page and understands the goal and direction of the business and IT that supports it. Its focused on creating pictures, with supporting text, that can be used as quick references so as an example the Level 0 and Level 1 for a manufacturing company could be as follows.

This is the Level 0 picture, its aimed at defining the overall context of the business and the primary service. Some organisations may have a few services at level 0, most however will have either 1 or 2 that really define what the business is all about. This is the "Chairman" and shareholder level picture

And this is the Level 1 that breaks the picture down to the next level of how the business starts to deliver for those services. This shows the "What" (Services), "Who" (external organisations/actors) and "Why" (reasons actors/services interact). Level 1 is the CxO level as its here that the high level trackers are defined. As an example the number of items shipped, outstanding invoices etc are all at this very top level. The method is very simple and doesn't talk about the actual "How". The purpose is simple, if you don't know what the big picture is, how are you ever going to know what needs to be delivered?

I'm going to be using this approach within Blueprints (for example we are working on an example SOA company to create an SOA business blueprint) and we're looking at working with the vendors around getting tool support.