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.

Simplicity and SOA

I've noticed with the rise of SOE (Intel, Service Oriented) that people who didn't know how to sell SOA are now hiding that by selling an even less clear Big Picture. SOE = SOA + SOI is a powerful message, but only if you understand what each of the elements mean.

SOE, its a powerful concept, but if you don't know what SOA is.... it doesn't help make it clearer.

SOA is it business or technology...

I'm personally getting fed up of seeing another article, or presentation from a vendor, which equates SOA with technology. Its very like those articles in the 90s which tyalked about a technology as being "OOD". Object Oriented Design was about a shift in how people designed systems, away from process oriented design, towards placing the domain model at the centre of any system. By making the domain model of primary importance in a system meant that you modelled the data and "things" of your environment how they actually happened. This was an immensly powerful metaphor that represented a shift in the way the average system was built.

SOA is a shift in a different area, its about changing the way we think about architecture. Its complete rubbish to say that SOA is an approach that started only with Web Services, as with OOD (which started with Simula back in the 60s) SOA is a concept that has been around for quite a long time, in fact it would be fair to say that most very large IT builds have been using Services since the year dot. So if SOA is an old architectural pattern why is it more important now? I'd say for two reasons, firstly because more organisations and projects are at a level of complexity where an architecture is actually required, and secondly because it is now simpler to translate that architecture into reality.

The key message on SOA therefore always has to be that SOA is about architecture, not about technology. And the purpose of architecture is to define the framework and context for the solution, this means that it must be focused on what the people who request the system want. This means it MUST be focused on the business.

Some recent presentations and publications of mine...

I've been doing more and more stuff around SOA recently, most of which to be honest can't be published yet. But there is some stuff I've managed to get out there into the public domain. Apart from the definition of service one in IEEE Software I've also been out with BEA talking about Delivering SOA (which got a nice review off Radovan Janecek Why SOA Works, and Miko over on Yahoo's Service Oriented Architecture group). There is of course the work around JBI, where its a shame that the Industry Panel video isn't available (every little bit helps the Google count though!). I'm due to be presenting at BEAWorld in London, which will include a bit more around how you really do SOA, and also coming up is a specific presentation around SOA and Local government for the folks at IBM. To add to the "its not new" stuff it was partly this that was the basis of a presentation I did with Steve Meyfroidt @ Saint 2003 on Java and Web Services we talked then about the fact that WS was only one part of SOA. Hopefully we will get some more stuff out at work over the next few months, as SOA is becoming an ever hotter topic.

The reason for lobbing this up is I'm hoping to get more time to write around SOA and its good to get the background material in early. Should Blogs have bibliographies?

Snake Oil SOA

I just read this piece of Snake Oil SOA from a VP of Web Services (one assumes describable via a WSDL), where there are a few choice phrases my favorite of which is certainly

The key technology behind an SOA is Web services, a poorly named term for easily identified and encapsulated business processes delivered over the web

If ever one sentence failed to describe what was important in SOA and what Web Services are then it is this one. Its an absolutely classic in the genre of "SOA will solve everything" and attributing that change to a technology (Web Services). This is exactly the sort of thing that is getting SOA a bad name with business people because its just another technology being thrust at them as a silver bullet for the enterprise.

I mean "An SOA can also handle more elaborate tasks. A retailer, for example, could reroute trucks automatically based on a weather report."

You can do that using a phone call, or indeed with quite a few packaged solutions. Its got bugger all to do with SOA enabling that, you can write a non-SOA solution to exactly the same problem. It would of course help if the industry analysts started calling people on this sort of "snake oil" approach to SOA and start pushing a fundamentally different message, namely one about SOA being an ARCHITECTURAL approach to solving problems that works from the BUSINESS perspective, thus enabling everyone to agree on the solution at all levels, and provide a mechanism for monitoring and managing the systems in a way that the BUSINESS wants.

I'm just picking on this one article because its pretty typical of the work that is out there, "Buy SOA, also solves baldness". SOA will fail miserably if it continues to be about the underpinning technologies rather than IT actually changing the way we work with our customers (the people who pay the wages).

OASIS standards and SOA

Whey hey we've joined OASIS. It actually didn't take much convincing and that means we've now joined both the JCP, OASIS and Open-group (the later had nothing to do with me). And already we've started getting engaged. Its amazing how many people are really keen to get envolved and help out. I've decided to look at two at the moment, firstly SOA Reference Model which is already well underway and I just want to understand more, the second (and for me most interesting) is the SOA Blueprints which talk much more by demonstration. One interesting point is that no-one knows which group is to define the actual structure for services and how the blue prints, especially industry ones, will be constructed. I'd expect that to be a keen point of debate in the coming months as structure is, to my mind, essential to a successful SOA implementation.

The great thing about OASIS is that its nice and public so everyone can see what is going on. Could be an interesting ride.

The wonder of the obscure bug

I've just spent a highly entertaining(?) couple of hours trying to debug some Hibernate access code. The basic problem is that I have a primary key on a database with two elements, one called ATTRIBUTE_ID the other called ATTRIBUTE_VALUE, and I was getting exceptions about not being able to set the values or perform the mapping. I change the latter to ATTR_VALUE and everything works.... I've done a quick grep over the source to see if I can see what is doing this... but I can't find it.

But this has brought to mind finding other obscure bugs over the years, mainly I have to say with Java, elements like running JMS, MQSeries and AIX and finding out that it just doesn't work, and the reason was that AIX had a strange shared memory model and IBM had decided to use the same number for the JVM and MQSeries... muppets. And as for experiences using wonderful elements like early releases of various app servers, MQSI in a heterogenous environment (with MQ Pub/Sub).

I'll let the folks at Hibernate off though as its an all around cracking product and it was a minor fix. But it just goes to show...

Some times it isn't actually your fault when the code goes wrong... oh and that most vendors don't appear to have a unit test framework.

How do you define a Service ?

I've been using various tools from different vendors over the past 12 months, all claim that they are for "Service Oriented Architecture" and yet none have an effective way to define what a service is.

Some, like BEA's Weblogic Platform or the unbelivably large install of WBI-SF 2GB for godsake, provide a software container (BeeHive for BEA and WS-IF for IBM) but these are really developer tools rather than architecture tools to define a service. The objective of a service definition should be to define a discreet boundary within a system, this should then be de-composable into further services which can be co-ordinated together. The key is that service comes before process. Most of these tools (especially ones like WBI-Modeller) stress a "Visual COBOL" approach to systems design where the process is more important than the service....

So when vendors say they do SOA, right now every one I've seen means "We do Process Oriented Architecture", it was wrong with COBOL, and its still wrong now.