Getting Process to work with Service

One of the big questions that comes up over and over again is how to get Process and Service to work together. I tend to find that there are a few keys. Firstly to understand that process is one of the possible "how" languages for defining the implementation of a service. Some services are best defined in process, others can be defined by their KPIs (for instance "increase forcast accuracy by 1%) or by their behaviour (e.g. by using UML). Where process (or any approach) is used there are some key rules

1. Service boundaries are absolute they "how" techniques can
1. Alter internal state
2. Invoke external services
2. They cannot
   
1. Contain activities that are internal to another service

Now for Process this means that the objective of a process is to deliver a capability for the service and an activity in a process is the invocation of a capability on another service or the alteration of the state in a service.

In this way there is no Process to Service mapping, but Service acts as a container for process, and process is the mechanism via which the capabilities of that service are realised.

The next challenge is how to model these processes within a service context. First challenge is the current tools aren't set up to do this, they like to model process as the ultimate goal and they haven't yet got to modelling business as services. This means we have to do a few work arounds. The first option is to use service models, as per the methodology, to indicate the orchestration of services to deliver capability.


If using BPMN rather than modelling the whole end to end process model the overall execution process (the numbers on the diagram) and model EACH of the invocations as individual process. Do NOT try and model this has a massive process with lots of swim lanes. This will make the transition to services harder as these process models will cross service boundaries within one process model. The challenge is to be able to create these end-to-end processes as views rather than as models, again the tools don't really help here at the moment as they are process oriented rather than service oriented.

All this is at the level at which process is a series of activities. This isn't the only level at which process and service need to interact, the other level is where process describes a broad area like "buy" which means all of those processes releated to buying. At this level the terms service and process can be reasonably interchangable because they both are used to describe broad areas. The key therefore is to identify the points at which process stops being about broad areas and about stringing activities together.

In an enterprise model this often occurs between level 2 and 3, but this isn't a fixed point so you need to be careful.

So in summary : Broad area process is pretty much interchangable with service, activity and orchestration processes are contained by services and implement capabilities of those services.

Technorati Tags: SOA, Business Process, BPMN, Service Architecture

Keep the crap out of JavaSE 7

Okay I said that JavaSE 6 wasn't for the enterprise, but hoped that JavaSE 7 would be. Well guess what, it turns out that Sun's JavaSE team want to create an even worse version of Java with the Dolphin release. Yet more multilanguage support, hey why not use Basic... BECAUSE ITS A RUBBISH LANGUAGE, yet more bells yet more whistles and nothing at all for the enterprise customers. The basic idea seems to be that if you lob enough stuff into the basket that it some how becomes better. This basic idea has a fatal flaw, namely that it is bollocks. Its aiming for the "cool" and Joe Average, to tick the boxes and generally create a steaming pile for professional developers and architects.

What do I mean by professionals? People..

1. who have learnt how to search for libraries that do what they need
2. who like to control what the platform their application sits on does
3. who like to make absolute choices in what should be done
4. whose applications are rarely 100% purely the core Java platform
5. who build things for lots of other people to use
   
6. who plan for applications to be supported, not just developed

What I mean are people who use Spring, J2EE, Jini, Rich Client Platform, Swing and are able to make the right choice about the technologies on their project. I'm not interested in more bells and whistles, I'm interested in the following

1. Turning off the stuff I don't need, this means not having to install it in the first place
1. No Midi, Java2D etc in the core. If we need it we'll install it
   
2. No JAX-WS, if we want Web Services we will select how we want to do them
   
3. No scripting - if we need it we'll tell you
   
2. A standard way of describing both the Java standard and 3rd parties libraries I want, and where to get thefromalalala Ivy and Maven)
3. A core platform that is just that the
   
4. few standard profiles that provide a standard base for different uses of Java
   
1. Core Java
   
2. Basic Desktop - no comms
   
3. Full Desktop - comms, video, everything desktop
   
4. Kitchen Sink Java with the whole shebang for those who admire only size and where the JavaSE team can dump the new crap they seem to be so keen on.
   

Right now I'd settle just for having 1 and 4, although I think 2 also has merit. The problem is that big companies, of whatever sort, don't tend to complain about things like this. There is a reason for that, they consider (quite rightly) the technology to be something to use and assume that given they are paying billions for it that people would be trying to deliver what they want.

Unfortunately with JavaSE 6 and it looks JavaSE 7 Sun have decided to go after people with no money, or talent, but lots of noise, and make the world worse for professional developers. So the rally cry starts here, I've already posted to the JavaSE 6 list at my wish and desire for 7 to have a clear split between enterprise and the bells and whistles. There are some supporters but of course nothing as yet from the JavaSE 6 team.

Java is pretty much baked for the enterprise, a few extra things like reflection of parameter names would be nice, but mainly its about the choosing right libraries and frameworks rather than adding more crap into the language and base platform.

So the campaign for Straightforward Java starts now. What we need is LESS in the core not more, but a standard way of getting in those pieces that we need. This is why enterprise people use Maven and Ivy, not Basic.

Technorati Tags: J2EE, Java, JavaSE 6, JavaSE 7, JavaSE

Google Analytics isn't reentrant

Recently I've lobbed Google Analytics onto this site, it started when Andy Hedges put me on his profile, which was nice. Later the same day I received my own code and decided to see if there would be any difference between what the two recorded.

Just slightly, the first one records everything, the second records nothing. Google Analytics thinks that both are set up correctly but just isn't recording anything for the second call. Now clearly this is an edge case, and there is very little point to what I've done. But it does highlight one of the problems with services, namely the assumptions that people make on the consumers. I've no idea how Google do the recording, but assuming that a page only has one report to remove duplications, refreshes et al doesn't seem to unreasonable. Until a muppet like myself comes along.

This is part of the reason I'm a big fan of contracts as it can be used to place constraints on the consumer as well as the producer. In this case the constraint would be "only one tracker per page". Consumers are going to use the service in ways, some stupid, that you didn't expect without a way to define functionally what is acceptable its liable to result in support calls or a loss of confidence in the service.

Remember, consumers won't know its them that's wrong.

Follow-up
Only a day later from the folks at Google....

Installing multiple instances of the tracking code on your site is not a supported implementation, as it may result in incorrect reporting. We are not able to guarantee the accuracy of reporting with this kind of implementation.

So yup it isn't reentrant. It would be interesting to understand what the paticular implementation problem is. Now I have no clue at all how they've coded it but I do know that

1. There is a unique profile ID set before each call
2. The page information is only collected once on the successful stats page (no double counting)
   
3. Google thinks that both analytics elements are working when you check

So therefore I'm going to take a punt that the first thing that analytics does is take the profile ID and map it to a specific site, this is then used to remove duplicates that occur for what ever reason and then the information is passed on. Because the second call however maps to the profile ID it is assumed to be a duplicate and therefore ignored.

I'm not complaining about the service which is superb, but using this to give an example of how consumers do things you don't want, and currently have no way of stopping other than after the invocation. In effect Google is filtering out the data after the fact meaning that the second call has no real world effect, hence by the SOA RM definition is not considered a capability.

This gives an interesting point, is a capability always a capability or is it only from the perspective of the consumer. In this case a non-reentrant capability only exists for a single call and then ceases to exist. Not sure quite how you'd model that.

Technorati Tags: SOA, Google, Service Contract, Google Analytics

There is no such thing as IT Strategy

Its been a rant of mine for a long-time that IT strategy should be consigned to the scrapheap. Unless your companies business is truly just IT, in which case IT = business, all there should be is business strategy and then IT should work out the best way to implement it.

IT Strategy is the thing that decides to build the big "EAI Infrastructure" or "SOA Infrastructure" or basically "cool stuff we'd like on our CV".

If you are thinking about embarking on an IT Strategy project, just stop and ask yourself a simple question:

Is this a strategy for IT or a business problem that needs solving?

If its just for IT then stop, you are about to embark on the traditional waste of money in the creation of Powerpoint, at best, or the spending of millions, or tens of millions, of pounds in pointless IT solutions.

A critical point of the business driven approach to SOA is that it needs to be driven by the business view. This means that its time for the Powerpoint to take a backseat and IT to ask the simple question

What does the business what to do?

All that IT should be doing is looking to solve this problem. This means that IT should be feeding back opportunities for the business that matter to them and not bother with great big strategies that start with the premise that everything can be solved with technology.

IT strategy is for people who want to do Powerpoints. Business Strategy Delivery is for people who want to get the job done.

Technorati Tags: SOA, IT Strategy, Architecture, EA

BEA to solve world hunger

A beauty from the register

BEA to go organic on SOA tools The Register: "Aside from a common look and feel, BEA needs a single composition environment that is simple enough for line-of-business managers to build applications and services that wrap up security, data integration and messaging functionality buried in BEA's AquaLogic middleware layer."

Now I know the folks at BEA relatively well and I doubt that their aim for Aqualogic is quite so high as being the mythical "business people can build IT directly" solution.

Previous claims to this throne include the likes of COBOL, SQL, Business Process tools, UML and lots of other elements. Its undoubtably true that new tools are helping the business get better control over IT systems and make certain, controlled, changes to workflows and paticularly business rules. But using a quote my father was told when he got into IT

"The end to programming is 3 years away, thats as true today as its always been"

The mythical world where business people start doing system mashups to create new organisational dynamics and deploy them into production at the flick of a switch is the philosopher's stone of IT. Its a great sales pitch, but don't bet the business on it becoming a reality. All that happens every time is that IT moves up a notch of abstraction and the business demands ever more complex and dynamic solutions.

Nice marketing line though.

Technorati Tags: SOA, BEA, BEA Aqualogic, The Register, Myths

Selling SOA to the business - its selling

One of the most common questions about SOA that I get is how to "sell" it to the business. Well the first point here is that selling SOA isn't different to selling anything else and certain things apply.

1. Look and act professionally
2. Present clearly
3. Have a clear message that your audience cares about

Its hard to imagine presentations that are worse than some of the ones I've seen in IT. Some of the low-lights I've seen include

1. Lots of words on a slide - then just reading them
2. XML documents on a slide - and reading them
3. Lots of woeful colour use - clashing colours
4. Animations that take ages to build
5. No actual messages - or far too many

And that is just the powerpoints used to explain things, in terms of presentations styles I've seen

1. Heads down and mumbling
2. Dressing like the IT geek
3. Reading from the slides and POINTING and LOOKING at them from a distance
4. Disappearing into a rat hole talking about things that don't matter
5. Talking so quickly that they finish in 1/4 of the time
6. Running over by MULTIPLES of the allocated time
7. Repeatedly saying "I'll answer that on a slide in a moment"

The point here plays to something that Peter Quinn said at the OASIS event, I paraphrase from memory but it was sort of

"If you want to be taken seriously you need to dress seriously and lose the pony tail and sandals"

Now clearly I'd disagree about the hair comment :) and I guess that Jonathan Schwartz might have an issue too! But the basic point is simple, if you want to sell to the business you need to play the game on their terms and approach it as a proper sales campaign in the same way as anyone else in the business has to sell their ideas. If someone from Marketing, Finance or whatever was asking for strategic investment and changes in the way people work they would be crucified if they presented the way most IT people do. IT people don't get crucified, its worse, they get ignored, patted on the head and told to go away.

So if you are looking at selling SOA to the business start by ignoring the fact that its SOA. Think about how you'd sell ANY idea to your business, think about what they want and how your proposal addresses those problems. You need to link your SOA sales campaign to the challenges of the business as they see them and explain how SOA will help solve their problems.

Then when you get that sorted start crafting the presentation, and I mean craft. Don't just lob it together and remember a few key points

1. Pictures not words - reading words off slides is rubbish
2. When you present you are allowed to TALK about things that AREN'T on the slides, the slides should just EMPHASIS certain points
3. Present to them - Heads up, clear voice and look them in the eye like you believe it.
4. If they ask a question - answer it, if you have a slide on it soon then answer it briefly saying "and I'll cover what that means in more detail in a second" and if its the next slide say "I'm very glad you asked that because....", "good question.....", "exactly...." IF THEY ARE TALKING THEY ARE ENGAGED AND LISTENING... don't dissuade them.

There are lots of resources out there to help with crafting presentations (here, here, here, etc) so there isn't much of an excuse. And if your company has a training budget I'd strongly advise that you think about taking your part of it to help you present better rather than learning about that new shiny technology. After all if you convince the business that SOA is the way, you should be able to convince them that the new way needs more training.

Selling SOA is selling, remember that needs it needs to fix your client's (the business) problems, not be about you asking for what you want.

Technorati Tags: SOA, Selling SOA, Steve Jones, Presentation

JavaOne thing now as a podcast too...

Well I've just noticed that the JavaOne thing is now available as a podcast. And I've decided to test out these Technorati Tag things to see how they work. Might start using them as a standard in future to link to other articles et al.

I remember way back when in 2000 when they talked about having everything available for Free from JavaOne, back then it was a huge deal and considered financially a bad move for Sun, its amazing now that its actually a key part of many of these events to get the message out. We'd find it odd these days if they didn't have podcasts and vodcasts.

Which brings me back to service architecture, delivery channels might change, and the importance and drivers of those channels might change but the actual logic and information doesn't change as quickly. A conference is still a conference, even if its delivery mechanisms have changed, its the same core business service it always was.

Technorati Tags: Jeff Jackson, Java, Steve Jones, Charles Beckham, BPEL, JavaOne

SOA about the business - is the word spreading?

Over at the OASIS Symposium two weeks ago now myself and Mark Pettit talked about how SOA should be about IT delivering what the business wants rather than being about what is the current cool technology. From this we put out a press release to push the message of SOA being about the business not the technology.

Well the SOA blog over at ZDNet has picked it up, and I couldn't resist commenting.

» SOA — business or pleasure? | Service-Oriented Architecture | ZDNet.com

Mainly the blog has focused on technology concerns, but recently and again in this article he references a recent seminar by David Foster who appears to be saying similar things.

Hell you never know, maybe it might catch on one day....

Thoughts from the front of the Keynote

So its over, presenting in-front of what seemed like a legion of people. I was up on stage with Charles and Jeff Jackson who was hosting the demo presentations, which were focused almost entirely around the J2EE platform, with a bit of Swing thrown in at the end. They demo'ed Microsoft Indigo (WCF) working with interoperable security between it and the Glassfish J2EE platform.

So as per yesterday, what goes into a presentation to what was described as "maybe the biggest JavaOne yet"?

So this is what it all looks like before it kicks off. Remember the I Robot bit? Like that with chairs. It was pretty relaxed at this stage thanks to the rehearsal day the before. Then as it fills up... well it really fills up. Its huge.

Now for what is backstage and remember this is all done either from my video camera or a Nokia Camera phone, hence the woeful quality.
So it looks a little dark, but all of those lights and screens, probably about 40 or so computers are in the production element, and then there is all the various camera, audio and other kit that is about. I have to admit that I was expecting about 10 computers and a bit of config, after all how much does it have to do, amazing to see how much actual effort is required to run a bunch of powerpoint and cameras!

Then there was the presentation itself. What I was presenting was on the new BPEL and XML tools that Sun are releasing into Open Source, its stuff I saw last year in alpha and now at last its actually out there. Its BPEL 2.0, and pretty slick in how it works (although its still the same as everyone else with one WSDL per BPEL rather than being able to group things.
Here is Charles presenting the BPEL element, he also demonstrated some visual XPath functionality.

Now to be honest while this stuff is nice, and its BPEL 2.0, the stuff that was really impressive was the XML Schema work, paticularly one feature "uses" which graphs out what elements reference, use or extend a given schema element, very useful if you are looking into refactoring schemas or just to understand how someone has designed the schema.

Not sure if you can make it out but its there on the right hand side showing how elements in the schema relate. Its a very slick view on schema.

Then for the wow finish, I've been asking Sun to release this stuff for over 12 months now, and been bagging them for 2 years for not getting Charles' technology out there in the market quicker. Well boy have they listened. All of these tools are now available in Open Source, and available for free to download today over at netbeans.org so if you are interested in understanding if its smoke and mirror or a little bit more, get it here. Certainly pushes Sun up a bit on the tooling side, BPEL 2.0 support and proper enterprise tooling (amazing how one bit of Sun understands, while the JavaSE guys continue to go after the Slashdot crowd).

-- Update
Its on the JavaOne Website now, 8:30 in on segment 4 (High | Low res). And before anyone asks... yup it was scripted :)

Keynoting at JavaOne

Thanks to Charles Beckham I've been invited onto the Keynote at JavaOne on Tuesday to talk about some of the rather cool things that Sun are working on in the tooling space. Historically I've always been very impressed with what I've seen from Charles, but they've never made it out into the wild too often or its taken a long time to get there. So tomorrow could be interesting ;)

Anyway today was practice day, you get the nice black "all access" badge, so in I wander to the Keynote room. Different logistics to previous years its a long-room rather than a wide room, but with the massive screens all over the place to make sure people can see. The door was right at the back so I had to walk all the way past the empty chairs, its like I Robot on a smaller budget. Up on stage at the time were James Gosling and John Gage doing their bit, or rather discussing their bits.

So Charles took me behind the scenes, and to be honest I was gobsmacked, we aren't talking about a production set-up with 10 people or something, its massive with the sort of set-up you'd expect at a sports event outside broadcast. The resolutions of the screens is pretty amazing up close, not the blurred effect I'd expected. We did the walk-through and kept to our 7 minute slot and Charles showed some rather nice elements, look out for the XML tool he demos there is the foundation of something really special there, especially in terms of performance on big XML docs and schemas.

Now I'm pretty used to presenting, but I have to say standing on a stage with thousands, maybe tens of thousands, of people in front of me is filling me with the screaming heebie jeebies.

I'll blog again tomorrow about what it is like behind the scenes, and this time I'll make sure I recharge my camera phone.

Treating IT as a business domain

One of the elements in the Service Methodology that was released last year was the idea of support services, this talked mainly about considering things like HR et al as support services rather than as core business elements.


Well there is another area that IT needs to consider, namely itself. What are the capabilities that IT provides and what are the services that provide access to those capabilities? In the same way as the HR services and capabilities enable business units to undertake certain key elements, so must IT provide services for business elements to be automated.

The key here is that these elements are not the services that the business wants, they are those that are required to host the business services to be automated. These are purely support services in the same way as most HR services are support services. They are only required because the business needs them, either explicitly or implicitly, rather than having business justification on their own (e.g. there is no point having employee on-boarding without business departments to get them into).

So for IT what are these services? In part this is what the SOA Reference Architecture subcommittee will probably look to address, but before we get a formal definition I thought I'd outline what is meant by IT as a domain. Simply put most of the vendors when they talk about the "services" they offer to the business are really talking about IT services, things that support the view of the business not actually things directly offered to the business.

So when IBM talk about their ESB model and they talk about Process and Interaction Services, or Event Process or Workflow. Or some of the elements that BEA talk about, these are all about the IT services, which has nothing to do with the business services.
And its pretty common out there on the vendor front. The pattern of ESBs being about linking different technical services together rather than business services is becoming accepted wisdom, and for those that have read Freakonomics this doesn't mean its actually right.

So you should think about IT as a different business domain, with its own services and own approaches. But you shouldn't let this change the way you view the business services, and here is the challenge. Too often people start trying to split services into "Process","Rules" etc. Thanks to Edwin Khodabakchian who helped me frame what was really wrong about this.

The challenge isn't just the fact that from a business domain perspective that all the IT infrastructure is about is exactly that, infrastructure the place where its hosted, considering this important is like considering the floor of a building a person sits at as being a way to classify their job. The point is that these IT Services represent just the hosting element for a single capability, not always for entire services. A process engine for instance is just one way in which activities can be strung together, and this is completely separate to how two services will interact.

So the way to think about this IT domain is that its just another support service, it hosts individual capabilities for services, but doesn't have anything to do with the capability of the service itself.

For those who do Java or C#, think about the JVM and the CLR, they do a huge amount of things for your code, but when one class calls another that stuff just "happens", as a developer you don't care. Equally from a business service perspective you shouldn't care about the IT Services they should just "happen".

Dark SOA

At the SOA Reference Model dinner last night, after a some rather nice sake we were discussing things to go into the RM, this was in part kicked off my an "ovaries" diagram that nearly made it into the RM during the day.

So after a few more glasses of sake and thanks to some discussions about maths and physics that flew mainly over my head I proposed that the term "Dark SOA" should be stated as being out of scope for the Reference Model.

So what is Dark SOA? The agreed definition was something like

"The SOA Reference Model defines what good SOA looks like, there is a large mass of other work that exerts either a attractive or repulsive force on the SOA RM, these elements are currently not well understood and are extremely hard to quantify as being SOA but are currently given that label until they are better classified."

Dark SOA is therefore analogous to Dark Energy or Dark Matter, it is all of those elements which create a massive amount of noise around SOA without actually moving us forwards, its those things that just put "SOA" in front of old thinking in the hope of fooling people.

Dark Matter could be the thing that stops the universe collapsing and helps sustain those of us who live in the non-dark part. I'm not sure that Dark SOA has those benefits.

SOAP v REST more pointless than vi v emacs

I'm over in San Francisco at the moment for the OASIS Symposium which has had some interesting elements. One thing that cropped up, yet again, was SOA as technology v SOA as thinking differently. In a side discussion on this I was talking to a couple of folks who worked from a couple of vendors, my point was that I shouldn't be caring about SOAP v REST or the myriad of wire protocols and syntax that these people seem currently obsessed with, all I want to do is link up Consumers with Producers. As a business choice is pointless, in the same way as the WiFi market has agreed on the 802.11x standards and the Telecoms industry has agreed on things as diverse as Billing (OSS/BSS) and the actual infrastructure (GSM, WCDMA, PBX etc), we don't WANT lots of different choices at the base level, we want that to be commodity.

The comment I received was "why would we want to make it commodity so you can switch Vendor [X] with Vendor [Y]'s product". And here in is the problem, the vendors are missing the point, helped on in no small part by the "Web 2.0" crowd and people arguing about REST v SOAP et al.

Lets be clear, I want to define the capabilities that are required, I want to define the information that will be exchange to help with those capabilities. And I want consumers to be able to easily interact with that service.



The only things that matter to me are simplifying the modeling and management of these links and enabling the actual invocation to take place, because its that invocation that delivers actual value (a service with no consumers is pointless).

The mechanism that makes it happen is pure cost. Now this is why I want it to be a commodity, but so should the vendors. Why?

Because simply put, it already is.

RPC, async calling etc have been done for years, we know how to do them. The only thing stopping them being standardised into a single solution is the fashion followers in IT and the vendors. But it doesn't matter. Look at something like OBIX which I heard about for the first time today. These guys are defining standards to enable the control systems in building to link up. Lighting, power, fire alarms etc etc all able to communicate with each other and be controlled using standards. And they are using the WS-* standards to do this, and the same is true of lots of other industry groups trying to solve actual business problems.

Its time for the vendors to wake up and realise that all the arguments about SOAP v REST v whatever are pointless. All that matters is that a standard is good enough not that it is perfect. Tools should be what makes interaction between a consumer and producer simple, not the thing that makes a developers life slightly easier or slightly harder, we shouldn't be developing things that have no actual value and which could easily be done automatically. Defining an interface and an end-point is both logically and physically simple, is ridiculous that we are arguing about the specifics of how you shift and XML document from A to B and what is "easier" to develop with.

The process should be

1) Design interface and documents - UML style of thing
2) Generate exchange format of those interface and documents - WSDL and XML Schema type of thing
3) Right-click generate consumer, right-click generate producer
4) Develop
5) Deploy
6) Infrastructure to enable management of routing, policy, QoS etc
7) Repeat as required

If this sounds far fetched then think of designing an EJB using the latest tools or XDoclet, effectively this is what they do already, all of the crap is generated and you can focus more on the actual logic and consumption.

All of the current trendy arguments about SOAP v REST and the like miss the point here, we are still coding RPC and async calls in multiple different ways, by hand 30+ years after they started and since the syntax and semantics have been well understood. Shipping an XML document is a trival element, and its about time we stopped jumping on another trendy bandwagon of technology and looked towards solving the actual challenges of making the technology invisible.

Because as was brilliantly pointed out today by Robert Carpenter, its that step that will make it ubiquitous, and sure commoditisation is next, but there are a whole heap of companies making huge amount of money in commodity markets. Will that mean software vendors might have to think like hardware vendors? In part, but also it means they will be able to attack the challenges that add real value to businesses, which is surely where higher margins are to be made.

Its time for IT to grow up and cope with what we have rather than creating yet more technologies to solve the same problem in almost the same way.

2nd Crack at rating the vendors...

First time round to be honest its all just text so how does that help, so this time round I've gone for pictures. Odds are that once I start doing more evals (JavaOne is coming up so hopefully a bit of time to find out more details and understand more about the strategies) that this stuff might change, but its my current view.

The ratings are based on six different criteria

1. IT Vision - What are they going to do in IT, implementation of applications, integration with backends, sort of the technical end of SOA
2. IT Implementation - Great powerpoints guys, but what about the products...
3. Business Vision - What are the doing for the business, what is the content and how will it work for the business
4. Business Implementation - as before, what exists beyond the powerpoints
5. Standards - SOA implementation is massively about standards, how much does this company implement and drive standards
6. Stability - How stable is the current product set and roadmap, will they be shifting strategy and leaving you in the lurch, or going out of business and doing the same

Marks are given as percentages, this is basically how complete that element is. N.B. This doesn't mean this is their percentage for 2008, just for 2006, if they stand still the percentages would go down.

So to start with, and with six criteria, I've gone for six companies. IBM, SAP, Oracle, Microsoft, BEA and Sun. So how do they rate?

Bit hard to read on one diagram I know, so here is a quick over view with the pictures for each of the companies broken out.

IBM
	IBM have really cracked on around the technical elements of SOA, decent products, good strategy, trouble is its pretty much all about the technology, the business vision gets as far as business process modeling but it isn't an SOA vision. Since IBM have come clean(ish) around J2EE being their strategic direction you can be pretty confident that if you pick products on the J2EE stack from IBM then you should be okay.
Oracle
	Oracle have come a massive distance in the past few years, from a database company who did rubbish integration, to a decent middleware company. IT wise its getting there, integration is still a bit weak and they have to integrate the various purchases into a single suite, but its an impressive start. Business wise they have the advantage of having business applications, so they understand that there is a business, as well as technical, angle to SOA, but product wise its very early. Again its J2EE as the base and a solid base of products that should evolve rather than being replaced.
SAP
	SAP started a year or so later than Oracle down the road but again progress has been impressive, but not as evolved as Oracle yet, paticularly beyond SAPs traditional comfort zones. Definitely have a clear vision of the future with ESA and have really embraced the standards, and with their massive business content its a vision not just for technology but for business. Again a stable base in J2EE and a clearly emerging product stack based around that, which doesn't appear to be looking for major change, just major evolution.
Microsoft
	Microsoft are, IMO, the weakest of the bunch, waiting for Longhorn server is just a killer for SOA development, both technical and from a business perspective. Microsoft Dynamics might help them develop that business vision, and they do have motion which puts them ahead of most others in terms of actually thinking about the more pure business side of this. Stability wise the current flagship products are all going to go through pretty major revisions in the next few years, key elements such as the difference between Windows Workflow and BizTalk and the new technologies such as DSI and DSL have great potential, but are a long way away from enterprise ready. Woeful standards support, e.g. the lack of BPEL upgrade in BizTalk 2006
BEA
	The only company, at the moment, to have a clear differentiation between their technical (WebLogic) and Business (AquaLogic) product sets they've as ever been towards the edge of developing new technologies and approaches. Challenges such as the lack of BPEL support are being solved via buying companies, so the challenge of stability is how they will bring all these products together, its a firm base but the edges are a bit blurred. From a business implementation perspective they really need to raise the game around the modeling side, and these products are all new (within the BEA brand)
Sun
	Sun, well they now have a Software division with decent products after the purchase of SeeBeyond which gives them a firm base around IT. Nothing around the business side of note as yet, and a concern around the stability of their roadmap, will it be SeeBeyond evolution or will there be some more dramatic changes. Don't know, but 12 months ago Sun would have rated worse than Microsoft.

So that is how I see it right now with these six vendors, I'll start having a hands on and eval around the other products out there (any requests appreciated), and also what would be a sensible sectorisation of the SOA marketplace to see who really plays where and what are the biggest gaps (e.g. nobody really does Business modeling, only Microsoft have made an attempt).