thanks for your last two posts. Taking the two ideas from your previous posts along with an idea from Marketing 101, do we not get a more accurate picture?

1. From your “Activities vs Results” post. Companies don’t pay for activities, they pay for results.
2. From this post, capabilities are more powerful than processes, it’s the capability people want.
3. From Marketing 101, people don’t buy drills, they buy holes in walls. It’s the hole in the wall that people want, not the drill.

Combining these three ideas, when companies pay to execute a project, it’s not the project they want, it’s the result. They want more revenue generating customer relationships, not processes around a CRM system or even the capability to look up customer names. What they want, is the result.

Results can be defined in six ways:
1. Financial – How much did it cost us, what was our return on investment? (Possibly the most terrifying question you could ask of most IT projects…)

2. Capabilities – What can we do today that we could not do before? (The corollary to this is “How does this help us?”)

3. Customer Value – How does this enrich our customers experience with us enough that they want to do more business with us?

4. Productivity Improvement – How does this decrease the amount of work our employees have to do and can we translate that into employees doing additional productive work? (I believe Peter Drucker had a maxim that if productivity improvement didn’t make people 10x more productive, it wasn’t worth the effort. I now understand this in a way I didn’t before.)

5. Engagement – How does this empower or enrich our employee’s experience enough that they embrace rather than reject the change? And is there enough benefit to overcome the cost of the resisters being forced to change or leave the company?

6. Visibility – Does it give decision makers accurate visibility into what is really happening in the company?

7. Controls – Does it give decision makers controls to influence what happens in the company?

Thanks for your comments, I am on vacation this week so I have been a little late in reading comments and posting responses. Its great to get off the grid for a few days.

Thanks for pointing me at your extensions to Zachman, I tried to follow the link but did not make the connection. I will take a look when I get back from vacation next week.

From reading your comments I think that we are talking about different things using the same words. I am looking at capability as a higher level and unifying force for the way the company works, rather than a lower level – technology independent framework — which is what I am taking away from your comments.

I take it from your post that there are potentially 100’s if not 1000’s of capabilities. that is not what I am advocating. In contrast I think that I can define any business in about 24 – 30 capabilities at their most complex and under 12 for many. That is part of the reason why the post talks about capability as being more powerful than process as a capability can contain many processes.

The idea is to find a way to manage the business from as few – meaningful points of control as possible. We already have the alternative of 100’s of services that is producing mixed results.

Look forward to your response and I will follow the link when I am back from vacation.

Thanks, Mark

Thanks for your comments and there is a connection between the idea of capability and service oriented approaches. I can see where there is a connection between the idea of service level and composite capabilities.

I can see value in having a capability be able to adjust its performance level, but I think the idea of composite capabilites (nested according to service level) is an unecessary complication as it would call for basically replicating resources to have them perform at different levels. I think that this is what you are getting at from your post. If I am wrong then please let me know.

One of the other things that I may be reading into your comments is that there is distinction between a company’s capability model and its technical state.

If that means that there is an enterprise technical model that sits alongside the business capability model, then I disagree quite strongly as having separate models enables the enterprise to justify and build complexity into their operations. One of the points about a capability is that it can be thought of whole and all inclusive as a unit in the enterprise to the extent that you could define a capability, then outsource it and not disturb the other capabilities in the enterprise. Having parallel models for the business and technology will not enable this to happen.

Happy to continue the discussion. Thanks Mark

In my architecture work (see, for example, PDF of an extended-Zachman at http://http://tetradianbooks.com/2008/12/silos-frame-ref/ ), I draw explicit distinctions between function, capability, service and process:

- function: a point at which assets/resources may be accessed and optionally changed (i.e. function in the mathematical sense, as a=func(x,y) )
- capability: an ability to act on and, optionally, change something (i.e. closely aligned with competence, skill, etc), often clustered into defined ‘roles’
- service: a point at which a function and a capability are brought together
- process: a choreographed path through a sequence of services, creating a sequence of changes to a set of assets/resources, usually intended to add value

A function is closely aligned with a service, but cannot do anything without a matching capability; interchanging capabilities for functions provides alternate implementations of functions (eg. manual vs machine-based vs IT-based sub-process). In this context, a capability on its own literally has no function, but is a key determinant in the organisation’s ability to deliver value.

Service-orientation allows us to identify items within interfaces, SLAs, performance-metrics etc which should be common for the ‘function’ part of the service (i.e. common to all capabilities) and the specific parameter-values that would be appropriate for different implementations (i.e. via different capabilities).

I think there are ample opportunities for composite capabilities as well as capabilities that can be varied based on service level agreements, sales/distribution channel, or based on agreements with value-added partners.

In my view recognizing capabilities – from a business sense – and tying them to your enterprise’s technical state is a starting point for exploiting the full potential of capabilities. Service-orientation is a way to model, realize, and enhance these business capabilities using a combination of in-house and rightsourced technology assets.
I am looking forward to follow up posts on this interesting thread!