« The 3 SOA styles and product selection | Main | Are SOA and plain speaking incompatible? »

With all the stories appearing around the level of reuse actually being achieved and even the level of reuse we should reasonably expect, what has caught my attention recently has been how the challenge of reuse plugs into the need for organizational change as part of a SOA program.

I covered this in passing in my previous blog posting on how the architect role seems to be greatly expanded by SOA and how business needs to be involved particularly in the area of service ownership. Richard Akerman, a technology architect with NRC CISTI, expanded this in his own blog saying:

“One of the things we found useful was separating the business-level service description, from the IT-level service implementation. What we're currently thinking is that the business should own the business-level service ideas, but the IT-level implementation should have an IT owner. This is important, because I think you can get a bit carried away in the "business drives technology" or "business-driven SOA" enthusiasm. Yes, the business is in charge of generating and validating the business ideas, but they shouldn't be deep within your IT organization making technology decisions.”

I agree with Richard’s point – we need to remember what we are trying to achieve with service ownership: it is not to make business people into enterprise architects or enterprise architects into business people (although there are some who are already both). It should be all about achieving the goals of SOA which in the case of service ownership is primarily about driving the rate of reuse up. The technical goals around perfecting the service definition, interacting with registries, repositories and governance etc. should all support this goal of reuse being achieved in a resource efficient, controlled and ‘safe’ way.

Similarly, we need to figure out in a given organization how to use business ownership in a way that increases reuse. The way this works will depend on the service in question and the structure of the business. In the case of some services (say a booking service for the logistics function), the service maps pretty well onto a business line and the purpose of the service is easy to communicate to a business owner. With others, the purpose of the service is less easy to map as they are inherently more technical – say querying a logging system about failed messages. It is still a valid service but ownership fits better within the IT organization – all be it with an owner who looks at his/her costs and sees how the service will reduce them. I will return to this topic again!

To change track a little, Jeff Schneider of MomentumSI looks at service ownership from another perspective in “Lessons from Planet Sabre”: He points out that some services will be built by units which are primarily in the business of providing services to others, while others will be built by a unit for its own use. Both are still valid and need to be handled with equal care. As Jeff puts it:

“The shared services group had a great process for managing the deployment and operational processes around services that THEY built. But what about ours? Doh!”

and

“Lesson: New services will be found on projects and in some cases they will be 'non-shared'. Understand who will build them, who will maintain them and how they will be supported in a production environment.”

However, he saves his best lesson for last:

“Lesson: SOA takes time to figure out. Once you do, you'll never, ever, ever go back. If you're SOA effort has already been deemed a failure it only means that your organization didn't have the leadership to 'do something hard'. Replace them.”

Posted by rbradley in SOA Organization Issues • SOA concepts |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/698