In preparation for this year’s Building Business Capabilities (BBC) Conference (http://goo.gl/6JcB9) and its new Business Architecture Summit (http://goo.gl/5hnzh), I’ve been doing some background research on how professionals in the space view ‘capability’. Here’s a good exchange I had with Alexander Samarin (http://goo.gl/DNGLp).
RGR: What is meant by ‘capability’ in the context of enterprise architecture?
Samarin: ‘Capability’ is the proven possession of characteristics required to perform a particular service (to produce a particular result, which may include the required performance). Capability needs to ‘understand’ the mechanics of delivering that service for expected demand. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service.
There are three options to ensure a service has the required characteristics:
1. By contract (“re-active” approach) – acquire a service with the required characteristics, use it, check that its performance is acceptable and replace it if something is wrong with it.
2. By measurement (“active” approach) – implement a service, use it, measure it, improve or re-build it, etc.
3. By design (“pro-active” approach) – build a service model, run a simulation test, improve the model, build the service, use it, measure it, improve it, etc.
RGR: By contract do you mean ‘contract’ as a business person would understand it (legal), or as understood in object/component IT methodologies? Other?
RGR: By service do you mean a business service, a system service, an eCommerce service … other? All the above?
Samarin: A service is a consumer-facing formal representation (i.e. explicitly-defined) of a self-contained (i.e. operationally-independent) provider’s repeatable set of activities which creates a result for the consumer. (It is considered that there are internal [even within an enterprise] providers and consumers.) It is important that the internal functioning of a service is hidden from its consumers, so that some parts of the enterprise can be changed independently. For example, a ‘proper’ service can be relatively easily outsourced. Services are expressed in terms of expected products, characteristics and delivery options (cost, quality, speed, capacity, geographic location, etc.) – this is the Service Level Agreement (SLA).
RGR: How does the notion of business service apply to a company that sees itself selling widgets, not services in a conventional sense?
Samarin: An enterprise creates a result which has value to a customer who pays for this result. The enterprise acts as a provider (supply-side) and the customer acts as a consumer (demand-side).
There is a (business) transaction between the provider and the consumer. From the point of view of the consumer (the outside-in view) the transaction is bounded by the pair ‘request and result’, e.g. from making an order to receiving goods. From the point of view of the provider (the inside-out view) the transaction is a set of several distinct activities (or units of work) which function together in a logical and coordinated manner to satisfy / delight the consumer. These activities are carried out in response to the consumer’s request which is an external business event for the provider.
The main ‘problem’ is the coordination of activities (remember – they have to evolve). Processes, services, capabilities are, finally, the tools to improve the coordination (and the final outcome). For example, services are building blocks which are ‘glued’ by processes in bigger services. Capabilities are measures for how solid those blocks should be.
RGR: In the approach you describe, how is the how-how handled? Surely know-how is essential to ensuring repeatable, ‘delightful’ results, gluing services together, etc.
Samarin: As much as possible, ‘things’ (e.g. artifacts and relationships between them) should be made explicit and executable. For example, coordination of activities can be expressed in different techniques: template-based, event-based, data-based, rule-based, role-based, intelligence-based, community-based, etc. Also it should be known how to use those techniques together – similar to changing gears.
RGR: Sounds a bit vague to me. Let me try a different angle. The problem with BPMN is that it is token-based. It doesn’t externalize the state of business things. But talking about the state of business things is exactly what business people want and need to do (and do informally in everyday conversation). Structured business vocabulary (fact models) is how you externalize state so business people can talk about it. Business rules are how the business encodes its know-how so as to constrain the states of things (and derive classifications) … and retain the know-how. Business processes attempt transforms and add value. Thoughts?
Samarin: You consider that BPMN is token-based, but it also provides some event-based coordination. For me, this is not a problem, but just a building block to execute some coordination techniques. I don’t think that BPMN is designed for externalizing states of business objects. You emphasize that business people want to know state. And, in addition, I am asked by business people to show them a course of actions to obtain the result and to warn them in case of potential problems. Different people have different needs.