« Stress-Oriented Architecture | Main | Mashups and processes »

Just back from SOA India 2007, where I gave the keynote.  The conference was a fascinating experience.  In particular, it was interesting to talk to delegates from many different sizes and types of organization who are actually doing SOA!  Not just talking about it :-)

India really is where it is all happening, IT-wise.

And the discussions I had over the week, both with delegates and with other speakers, bear witness to an urgent need for a deeper understanding of SOA governance.  Many people working in the field are technically savvy, and have a good understanding of SOA techniques and tools, but still possess little or no appreciation of governance issues.  I heard some startling things ...

In the end, the sole justification for SOA is change.  In particular, SOA should enable you to align business change with system change - if you don't expect to attempt this, there is little or no point doing SOA.  However, change in an SOA environment is deeply risky - analogous to rewiring an F16 in mid-flight.  Scary stuff, considering that standard software QA techniques such as static analysis and automated testing have yet to mature for systems that are assembled rather than programmed.

Hence, if you're going to do SOA, you can expect to be doing on-the-fly transformation - and in the absence of standard, systematic control techniques you need to have a very good understanding of how to control change manually.  In other words, you need to define your governance processes, and manage their implementation,  very carefully indeed.  Such processes are not routine, and are only partial candidates for automation - they are, in fact, exactly the kind of processes dealt with by Human Interaction Management (HIM) (collaborative human work processes).

However, no-one I spoke to last week seemed to understand the need for process control in SOA governance, however sophisticated their ideas on SOA in general. Certainly none of the vendors in the governance space have yet incorporated HIM techniques into their tools. The next step for SOA governance tools is to integrate the functions of a Human Interaction Management System (HIMS) such as HumanEdj into an existing, repository-based offering - and the first entrant in this space will have the market to themselves.

TAKE AWAY

I suspect that understanding of the need for process control in SOA governance will only become widespread once there have been a few public disasters - and these cannot be far off.  Soon, early adopters of SOA will attempt to use their brand new system environment in the way promised by its original advocates - namely, to make rapid changes to align IT with new business requirements.  And without effective process controls, reconfiguration of a hugely complex network of interacting services is bound to bring problems.

I see no reason why the impact of such problems should be limited.  Rather, they are quite likely to break some organizations entirely.  It may be that for now, SOA change problems have been covered up - but large-scale operational or financial disaster is not so easy to hide.

So why wait until it happens to you?  Would it not be better to bring some order to the chaos?  In other words, take responsibility for your SOA!  Do not treat SOA governance as if you were going out to dinner with colleagues - each choosing a few items from the menu on a whim.  Rather, treat SOA governance as if you were all working together in the kitchen - collaborating with just enough structure to ensure efficiency, and adjusting your work patterns from day to day as necessary to meet requirements.

You may be interested in my slides from the keynote, which addressed these issues.  Also, following discussions at the conference around data management, I have prepared a new version of my Balanced Scorecard for SOA Governance.  The organizers, SDA India, videotaped a long interview with me which will be online in due course - when I know the link, I'll post it to this blog.

In my next post, I will discuss a related topic - namely, mashups, of which there are more than one kind.  Stay tuned.

Posted by keithhb in Service-Orientated Architecture |Digg This|Add to del.icio.us