My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Tuesday, June 20, 2006
« IBM + WSDM + Open Source == What is the ... | Main | How to prepare for Service Orientation -... »

Todd has a pointer to Brenda Michelson who is facilitating an online discussion around “..how to prepare your IT organization for service orientation”.

I concur with Todd’s comments and add that the one thing that I noted with MarkG’s question was the emphasis on “… prepare your IT organization..”.   The issue that I often see with IT or a Technology Group driving a SOA implementation is that there is more than likely going to be an emphasis on technology implementation rather the improvement of business processes. As a technologist it pains me to admit this, but SOA is NOT about technology. It is among other things, identifying the capabilities that are offered by the business unit,  having a clear understanding of the processes that make up those capabilities, and making those processes available for reuse via standardized interfaces to the enterprise at large.  In short, unless you fit the identification, design and development of services within the larger context of what the business is all about, it is very possible to end up with a bunch of services and not a SOA. 

Where IT driving the bus makes sense is in the design and development of Infrastructure Services. What I mean by that is that in any implementation of a SOA there are going to be cross-cutting concerns that should be centrally managed and abstracted away from the business. Implementation of a security infrastructure is a good example of this type of functionality. These types of implementations, which should have very low coupling with business processes, are something that makes sense for an IT/Technology Organization to drive.

As to the governance that was mentioned, it does not necessarily follow that an organization that has a deep expertise in AppDev translates to an organization that has a good governance process in place.  I do think that it makes sense that if the culture already has a good governance process in place as part of its Enterprise Architecture, adding the bits that enable governance for SOA is an incremental addition and not a big culture shift. And this addition very much improves the chances of success of the SOA implementation, given that lack of governance has been cited as one of the prime reasons for the failure of SOA implementations.

Tuesday, June 20, 2006 11:38:50 PM (Eastern Daylight Time, UTC-04:00)
Great points, Anil. I gave a presentation at a conference on steps to successful SOA adoption, and one of them was "think outside the box." This equates to understanding of business processes. That's an extremely difficult thing to do on its own, as seeing the forest for the trees is not easily taught. Now add the typical pressures from a project manager to meet schedule, which typically means reducing scope, not increasing it, and we can see why it's so difficult.

I also agree that governance processes are probably a good indicator of the road ahead for the organization. In a very simple sense, governance is nothing more than someone from outside a project taking a look at a project from a broader perspective. This is exactly what's needed to be successful with SOA, provided you're doing it at the right points in the project.

I have some additional comments to Mark Griffin's response on my original See: http://www.biske.com/blog/?p=52#comments.
Comments are closed.