lustratus LiteBytes

Oh dear. Once again I am about to be drawn into a row about vendor claims around SOA. Oh well – so be it.

I saw a link recently to a White Paper available through Information Week, by Metastorm Inc., which started off

While an SOA can go far in addressing the important security, reliability, and re-usability of services, SOA is nonetheless a technical approach. Thus, the challenge of SOA — and the key to achieving business value — is elevating service enablement beyond just technology functions. The reality is that SOA has limited value unless it encompasses disparate applications and platforms, and most importantly, it moves beyond technology and is orchestrated and controlled in the context of business processes.

OK, I see where the BPM vendor is going with this. But there is a glaring issue here in my mind. Stating that SOA is a technical approach, and discussing the need to move beyond technology (via the use of BPM) creates the false impression that SOA services are technical pieces of functionality as opposed to business services, and that implementing an SOA is jsut a technical exercise. This is absolutely not the case. I have discussed this many times, even in this blog. SOA services lie on business rather than technical boundaries – they execute a piece of business functionality as opposed to a technical one. Indeed, as I have also stated previously, this leads users into a position where they may be ‘backing into’ BPM through building orchestrated SOA services, but this does not require a BPM suite. In addition, a successful SOA implementation is almost NEVER just a technical exercise – it has to involve all sorts of disciplines.

I am not against BPM suites – in fact, I think they can add a lot of value when users have the enterprise-wide maturity to realize the full range of benefits they bring. But let’s make sure we keep the facts straight.

Steve