#bizarch artefacts definition; again

This post is written for the LinkedIn discussion "Whats the defference between, a Business Capability, a Business Function, a Business Process and a Service?"
In this post, I collected (and refined) several #bizarch definitions from the posts about #bizarch.

activity, noun
elementary or indivisible unit of work

function, noun
abstract and self-contained grouping of activities that collectively satisfy a specific operational purpose

Remark 1: Functions are unique within the enterprise and should not be repeated.
Remark 2: Some functions can be decomposed into smaller groups of activities, and thus the functional view has a hierarchical structure. (Without taking into account that one function may use other functions to accomplish its purpose.)
Remark 3: The structure of functions is not always the same as that of the organisation chart; in many cases, some organisational units can span several functions. Furthermore, organization charts may change while the function does not.
Remark 4: A business function typically has the suffix ‘management’ in its name (e.g. ‘Customer Relationship Management’), but it can also be a noun (e.g. ‘Marketing); usually, function name specifies something that is performed continuously.
Remark 5: The functional view emphasizes WHAT the whole enterprise does to deliver value to the customer (without the organizational, application, and process constraints). Usually, the hierarchical structure of business functions is very static (with a low rate of change).

service, noun
explicitly-defined, operationally-independent, and consumer-facing repeatable unit of functionality that creates a particular result for the consumer

Remark 1: It is considered that there are internal (even within an enterprise) providers and consumers as well as external consumers.
Remark 2: A service may wrap several functions. (In IT, we call them operations.)
Remark 3: A service is self-contained in some extend.
Remark 4: Complex services are created by means of the coordination of more simple services and/or activities (in the same way that an orchestra is a coordination of individuals and their actions). In this sense, an enterprise is a mega-service composed of a network of nano-services.

process, noun
explicitly-defined coordination of services and/or activities to produce a particular result

Remark 1: Processes are HOW of the business.
Remark 2: Services and processes can be considered to be intimately related since in real terms

• all processes are services, 
• some operations (or a very detailed function wrapped by a service) of a service can be implemented  as a process, and 
• a process includes services in its implementation. 

capability, noun
the proven possession of characteristics required to perform a certain kind of work (i.e. as a particular service to produce a particular result) with the expected performance

Remark 1: Capability needs to “understand” the mechanics of delivering that service. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service.
Remark 2: Capability is named after the expected result/performance (http://ingenia.wordpress.com/2010/10/19/modelling-behaviour/), e.g. “2CV”.

Why do we need all of them? 
Functions is an internal view of an enterprise (or supply-side). Services is a consumer view of functions (or demand-side). Capabilities is a performance view (or matching demand and supply) including both expected and realised performance.

Each service is associated with an owner who is responsible for delivering the promised results in all instances in which that service has been requested. That owner has

1.  to know/estimate the demand-side needs (the service may have many different consumers who will be using it with different frequencies), and 
2.  to design/organise/create in advance the supply-side capabilities to ensure those needs are satisfied. 

So, how can one ensure that a service has the required characteristics? There are three control options:

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. 

The first option works with some support services, the second option can work satisfactorily with lead services and the third option should be used for core business services. The core business services can’t be outsourced, can’t be bought and must not be “damaged”.

One of the models of the "mechanics" of provisioning a service is a business process. The explicit coordination brings several advantages.

• It allows planning and simulation of the behaviour of a service to evaluate its performance. If that service uses other services, then the demand-side needs for those services can also be evaluated. 
• It can be made to be executable, thus guiding how work is done. 
• It allows control that the actual behaviour of the service matches its intended behaviour, thus pro-actively detecting potential problematic situations. 
• It allows the measurement within a service of the dynamics of different characteristics, e.g. valuing, costing, risk, etc.

Thus a process is a way to guarantee a capability of a service to perform a function.

And architects are responsible for this how (see http://improving-bpm-systems.blogspot.com/2013/03/architects-are-responsible-for-how-thus.html).

Thanks,
AS