Thursday, May 25, 2006

Capability vs Service: What's the difference? Does it matter?

So what exactly is a Service? If we are seeking a common definition of what SOA is (and much is made of the lack of this on the web), then we could at least start by defining the 'S' (in SOA).

There is some emerging consensus in some SOA communities that 'services are a way to gain access to, or make use, of a capability'.

The uninitiated might propose that this sounds rather cryptic, but it is actually important because defining the difference between a service and a capability is one of the key concepts to get to grips with, in order to design an SOA that actually is workable.

To illustrate this we need to look at a business example, as making IT architectures more business-meaningful what SOA is about. (I've written before on my Enterprise IT blog about how the implicit goal of SOA is to create IT architectures that are structured explicitly like the business they support, rather than being structured explicitly in IT construction terms I.e. systems I build, data I store, software I deploy, hardware I install, etc). So let's look at a business example.

Imagine I run a practice in a consulting business. I offer services externally to my clients (defining supply-chain strategies, say). I also offer services internally to other parts of my consulting business (maybe sales-support to the sales team, solution audits to the delivery management team, etc etc). Against all of those services I need to know what my value proposition is to those who consume my services. I need to carefully define the quality of service (or service levels) that I can offer. And I need to know how I’m going to generate 'value' for me (directly as revenue, or indirectly) and what my 'costs' are going to be for those services (again directly or indirectly).

Of course I will require some capabilities that I don't have, or don't want to carry myself, which I can obtain through consuming services from others (maybe HR and Finance services from the common back-office for example).

But the services that I offer to others, and the ones that I consume from others, cover a fraction of the capabilities that I or they need to have in order to operate. For example, I need to have a management capability for a start, but it’s not some thing I'm ever going to be to offer as a service to anyone, externally or internally. But it's still a capability I need to operate. In particular I need it in order to deploy my resources optimally, to grow my practice's capabilities appropriately, and generally run efficiently.

So I define the services that I offer, and I define the capabilities I need to support them. They are not the same thing, and it is important to differentiate. The services that I offer define my value proposition to my customers, partners, or other consumers. The capabilities I have define my operating model, internal mechanisms, ways-of-working, and even technologies. Of course, of the capabilities that I need, I may have them in-house or I might source from somewhere else via a service that they provide to me (at a service level that I find acceptable for my needs).

The key point is here that if you treat everything as services (as some SOA dogma would either have you do), then there’s a strong argument to say that you’re devaluing the concept of service to the point where it becomes meaningless.

If you were to do so, you'd be treating your capabilities as services, which they are not. The two have very different characteristics, and need to be defined in different ways. Furthermore you'd be massively increasing the number of services you need to manage, which is just asking for trouble as services are complicated things, with overheads that you need to manage around the service levels, policies, contracted interoperability etc. I would advocate that you only want as many as it is valuable to offer. The rest are better served as capabilities.

So if you're having trouble defining your services with sufficient clarity and rigour, take a minute to check whether that's actually because the service you're looking at is not meaningful to the outside world. Maybe you're actually over-reducing the service being offered to the level of the process it uses internally - maybe it would be better treated as a capability?

I should mention that Steve Jones has also recently put down some of his thoughts on a similar subject in his blog. He has some interesting thoughts on how you draw the boundaries.

Technorati Tags:

4 comments:

Sam Lowe said...

Anyone interested in this would probably enjoy reading 'The World is Flat' by Thomas Friedman like I recently did.

I was expecting a largely political book on globalisation with some cleverly argued points.

But actually, I was pleasantly surprised by how more than this, there is significant informed explanation of how technology is enabling collaboration, and therefore globalisation.

So what? Well this involves commentary about outsourcing and off-shoring (which of course are key facets of globalisation) are enabled by distributed provision and consumption of services, as is 'in-sourcing' whereby organisations offer new services to the outside world based on capabilities they’ve developed for their internal operations.

Steve Jones said...

For a more detailed, and potentially definitive, definition around capabilities and service I'd also recommend the OASIS SOA Reference Model group. Its heading towards public draft two and very clearly puts itself on the side of the Service provides access to capabilities argument.

Steve

PS Cheers for the plug :)

York Earwaker said...

IBM’s Component Business Modeling makes exactly this point. For an overview of CBM see http://www-935.ibm.com/services/us/index.wss/ibvstudy/imc/a1017908?cntxt=a1005266 . The CBM talks about services external and internal to the business, or business unit component, and the capabilities they expose for consumption by others. For a more concrete example which uses the IT capabilities of the IT organization see
http://domino.watson.ibm.com/tchjr/journalindex.nsf/495f80c9d0f539778525681e00724804/d4d986d0842b91938525732c00660345?OpenDocument . Both also talk about removal of duplication and improved agility of services offered by enterprises internally within themselves and externally to others. Where the services are cohesive value offerings through loosely coupled business components. Applying the object oriented ideas of high cohesiveness and loose coupling to the capabilities exposed by business unit components. Exposing the value propositions (capabilities) that the business unit component offers as externally facing (human and ICT) services.

York Earwaker said...

IBM’s Component Business Modeling makes exactly this point. For an overview of CBM see http://www-935.ibm.com/services/us/index.wss/ibvstudy/imc/a1017908?cntxt=a1005266 . The CBM talks about services external and internal to the business, or business unit component, and the capabilities they expose for consumption by others. For a more concrete example which uses the IT capabilities of the IT organization see
http://domino.watson.ibm.com/tchjr/journalindex.nsf/495f80c9d0f539778525681e00724804/d4d986d0842b91938525732c00660345?OpenDocument . Both also talk about removal of duplication and improved agility of services offered by enterprises internally within themselves and externally to others. Where the services are cohesive value offerings through loosely coupled business components. Applying the object oriented ideas of high cohesiveness and loose coupling to the capabilities exposed by business unit components. Exposing the value propositions (capabilities) that the business unit component offers as externally facing (human and ICT) services.