SOA Service Ownership

We've been having some internal discussions about service ownership.  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.

In addressing the question of service owners, Ali Arsanjani of IBM uses the concept of Service Domains:

Business/IT alignment. Great.

Each business line goes about their way to achieve it, but soon will find out that there is one conspicuous issue: who is the Service Owner? If I build this service and it is used in multiple places, who pays for the changes if the changes are those I do not specifically "care about" in my line of business?

Thus appears the notion of Service Domains, where a domain defines a set of related services that some "one" can own, maintain, support and (obtain) fund (ing).

To make a [change] to a service, contact the Service Domain Owner.

I guess it depends on the size of your organization and the number of services - I can certainly see large organizations with many services needing to take a Service Domain approach.

Ronan Bradley examines this in SOA Architect required: Only superheroes need apply

The key artefacts within a SOA are of course the service definitions (and their related data models). The benefits of reduced cost and increased flexibility rely on these being maintained, evolved and most importantly used as often as possible. So what is the role of the owner and what does he/she own? To my mind ‘owning’ in a business-aligned SOA environment should be in the sense of being responsible for making sure the services are used and used in the way to give most benefit to their business. This person can’t be our super-SOA architect who has all those other jobs!

The solution to me seems quite obvious – if a SOA is business aligned, the business must be more involved in SOA. this suggests that the owners of the service need to be directly aligned to the business owners of the associated business services. How this is done in practise will depend on the organization and its structures and goals. What will be true in every case is that the focus of this role should shift towards business skills and away from technical skills. The service owner can always go ask the architect for help and the architect can then focus again on ensuring that principles and guidelines are followed.

I think this is useful - the owners of the implementation should work with the business owners of the business services.  I am not convinced though that this means the implementation owner skillset must inevitable move towards a business focus - I think the implementation owner must retain a deep technical understanding, in order to be able to best advise the business of the impacts of changes.  If the implementation service owner is going to come to the architect all the time, you might as well just make the architect the implementation owner - the whole point of having a separate service owner is that the implementation owner has the power and ability to make decisions about the service (in consultation with stakeholders).  So to me, implementation owner is a primarily technical and coordination role.

I wonder if we can agree on some terminology.
business service seems fairly clear
but below that?  IT component owner?  implementation owner?  implemented service owner?  IT service owner?  What are you using in your organization?

Bradley points to a useful Gartner article that exposes some of the transformational impacts a fully-implemented SOA may have on your organization - The Organizational Impact of SOA

Then the idea of quality of service comes into play. Because an organization is going to a service-oriented architecture, one of the biggest transformations is going to be in delivering services that do what they are supposed to do, when they are supposed to do it. In other words, quality of service is more important now than the services that are actually delivered because quality of service is what determines whether someone can actually use what has been delivered.

The organization has to be ready and able to stand up and say, "Ah, we can track, manage, and deliver or guarantee delivery of a certain quality of service." In some organizations that may mean, actually bringing in or using part of the staff to be service providers, to become a service provision organization, as opposed to an application provision organization.

Two other issues come to mind – ownership and distributed transactions. Who owns what? Who owns the data, services, and processes, and how does one bill back for those processes? Who is responsible for the system that those processes run on? In terms of distributed transactions, an enterprise has processes that span organizations, business applications, computing systems, and even companies. And you have to understand when you are doing this transaction across a lot of different boundaries, how are you going to handle that?

Another issue comes as you build capabilities out of BPEL orchestrations of services.  Do the orchestrations then have owners?  How do you avoid having layer upon layer of owners?