Why is there no WS-Contract?

Bit of a self plug but... Macehiter Ward-Dutton: Blog on IT-business alignment and related things is by a co-presenter on an ESB Webinar, its got an interesting set of questions around the different vendors on the blog though, and a paticular pet peeve of mine, namely there is neither WS-Contract, or WS-SLA so in terms of defining the "ilities" of applications and the KPIs there is still nothing, its all focused on Transactions, reliability and a series of other elements that businesses don't care about.

Sun puts Tin as the only part of infrastructure

Reading SOA Best Practices: A Conversation With Sun Microsystems Distinguished Engineer Mark Hapner its interesting that only Sun appear to consider the infrastructure platform to include only hardware elements. Most of the other vendors would consider the software elements, such as ESB to be part of the SOI, with the applications being SOA.

Service Component Architecture

IBM's Service Component Architecture (SCA) is a cracking new solution to the issue of "what represents the service", a definate improvement over WS only technologies it starts from the basis of assuming that the container at invocation should be standardised, but that the implementation and container at the produce can be variable. This really helps from a conceptual and logical architecture perspective as it gives a level of consistency that WSDL, and even WS-IF struggled with. Most interestingly around SCA are the companies who have said that are going to adopt it. BEA, IBM, Oracle, SAP, IONA, Siebel and Sybase, now while the idea of SCA is not Java only, pretty much all of this camp is in the Java world, I guess its like how JCA isn't Java only as it connects to lots of external applications, it just "happens" to run in Java. Definately worth a look and something that I'd expect to gain rapid adoption. Its already in the wild in IBM's new Process Server and their Integration Developer.

SCA is in someways an extension of the work that BEA did with Beehive so I'd expect them to be able to move relatively quickly, as should Oracle as they are moving from a similar technique using WS-IF, which IBM used in the previous version of their product too.

Strong technology with a very devent future.

The myth of the "Enterprise" Service Bus

Remember when EAI vendors talked about the single EAI product that you'd need, the "central" broker that ruled everything? Remember when 3 years later you had three of these products in your system, sometimes from multiple vendors sometimes just different versions that don't play well together, and the toughest job was bridging the gaps between them? Now we have the "Enterprise" Service Bus, and yet again the vendors, including the old EAI vendors, are talking about how you only need "one" ESB which means the proprietary extensions they have and the lack of active process sharing and service definition standardisations don't matter either. This is another great example of an IT salami fraud where they are able to continually "tax" your future projects because they "own" the information. As with the EAI plan however this is just plain wrong and bonkers for companies to sign up for as it will never actually materialise.

Enterprise wide software always assumes that you've chosen the right product for today and tomorrow and that you will never have a merger or acquisition who has chosen something else. The only sensible strategy is to work on a federated model for ESB which means while you have a product that works today you should work on the assumtion that other products will be consuming its services in future. Enterprise wide single product standards in EAI didn't work, and they aren't going to work in ESB either.

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.