Linking concepts and expressions used in Enterprise Architecture (EA)

The purpose of this article is an attempt to link some concepts and expressions used in Enterprise Architecture (EA). Some material from discussions at LinkedIn was used for this post.

First, the famous columns from Zachman framework

WHAT – assets (physical and electronic ones, e.g. business objects)

WHO – roles (e.g. people, organizations, governing bodies, other actors)

WHERE – places (physical and virtual ones)

HOW – functions (actions of making some assets from other assets, adding value to assets, etc.)

WHEN – events (temporal, systematic, spontaneous, external, internal)

WHY – reasons (e.g. motivation, rules, internal and external constrains including desired performance, principles)

maybe to add also
WITH WHAT RESULTS – KPIs (derived from audit trails as actual performance)

Next, two overused terms

Service is an explicitly-defined and operationally-independent unit of functionality. Service is a black box to produce some assets. Service is an external perspective of a function. One or many distinct functions can be fulfilled by a service.

Process is an explicitly-defined coordination of services to create a particular result. Process is a white box to produce some assets. Process is an internal perspective of a function. Process is a composite from many different artefacts (roles, rules, assets, functions, etc.).

Remark: Services and processes can be considered to be intimately related since in real terms

• all processes are services,
• some functions of a service can be implemented as a process, and
• a process includes services in its implementation.

So, at an enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

And a very controversial term at the end

Capability is the possession of characteristics required to produce a particular outcome. The latter is a pair “right things” (assets) and “done well” (performance, reliability, etc.) as the result of work of a function (regardless how this function is implemented). So, a capability combines functional and non-functional characteristics (timeliness of outcome, data accuracy, quality of result, efficiency, effectiveness, impact on stakeholders, SLA, SLE, etc.) of a function. Important to note that a capability describes some kind of expected characteristics of a function, but not actual results demonstrated in particular cases. This is similar to normal cars are which capable to do 200 km/h, but they rarely go faster than 130 km/h.

Are capabilities the building blocks (easy to move, reorganize, outsource, etc.) of business? Only if a corresponding function is exactly a service (so, the function is operationally-independent and it can be improved without causing any negative effects).

Functional characteristics are known from a function itself. Non-functional characteristics can be obtain from specifications (as defined in a contract or a description), by measurements (performance testing) or by design. The latter option means that a function (a part of the whole service) can be implemented as a process for which performance characteristics can be obtained from the performance simulation of the process template. In some cases, obtaining non-functional characteristics by design is the most practical way.

A possible scenario

Stakeholders:
OK tell us about your brilliant idea.

Future CEO:
We plan to provide to the market a product WHAT1 manufactured from WHAT0 with the performance WHY1. This will be fullfiled by function HOW1 implemented via service ServiceHOW1

WHAT1 = ServiceHOW1(WHAT0) // Magic happens here

Stakeholders:
Sounds good. But, is ServiceHOW1 capable to operate as required by WHY1?

Business architect:
The desired performance of ServiceHOW1 is guaranteed by its implementation via ProcessHOW1. In some way, WHAT1 is decomposed into a set of WHAT2x. WHY1 is decomposed in a set of WHY2x. All together will be coordinated by this process.
ProcessHOW1 = {coordination1, HOW2*, WHAT2*, WHY2*, WHO2*, WHERE2*,... }

Stakeholders:
Please continue until black boxes become too trivial so they can be bought, rented, outsourced and easily implemented.

What do you think?
Thanks,
AS