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

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

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*,... }

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

What do you think?


Linkedin: Top three Enterprise Architecture challenges?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36781&discussionID=9394300" />

1) Move from vendor/group/institute-centric EA to customer-centric EA.

2) Advance from just being DNA or “enterprise genotype” (a full nomenclature of enterprise artefacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance).

3) Develop a commonly-agreed reference model.



My new book about BPM, SOA and EA

Dear colleagues,

I would like to introduce you to my new book "Improving enterprise business process management systems" has just been published. This book looks at the following three concepts of BPM:

[the theory]
BPM as a management discipline;
[the tools]
BPM as a software (BPM suite);
[the practice]
BPM as a portfolio of the business processes of an enterprise, and the practices and tools for governing the design, execution and evolution of this portfolio (BPM system).

In particular this book concentrates on the last concept which is often neglected although all enterprises need it. This book will help you to industrialise enterprise BPM systems. It describes a holistic approach to the application of BPM and SOA for improving enterprise business performance, including

  • how to use architecture to reduce complexity,
  • how to use a BPM reference model and BPM artefacts,
  • tips on mastering the most difficult aspect – people,
  • guidelines on the modelling in BPMN,
  • recommendations for designing flexible systems, and
  • in-depth discussion about the link with enterprise architecture (EA).

Extracts and various useful links are available from http://www.samarin.biz/book