The anatomy of the reference model

This paper is published under the terms of the licence summarized in the footnote.

 

Abstract

In 2008, the British Computer Society (BCS) standard reference model for enterprise and solution architecture model was based on a model of essential general system theory concepts.

This model is clearly akin to the generic meta model that underpins the ArchiMate Language (later published as a standard by The Open Group).

The concepts in the two models seem to be in correspondence as the table below indicates.

And the concepts in TOGAF, though more loosely defined, can be roughly aligned with both.

 

View of system

Nature of element

ArchiMate

generic meta model

BCS

reference model

TOGAF

External

Behavioural element

Service

Event / Service

Service

External

Active structural element

Interface

Interface

 

Internal

Behavioural element

Behavioural element

Process

Process

Internal

Active structural element

Structural element

Component / Role

Component

 

Since 2008, some have interpreted the concepts in BCS and ArchiMate models differently.

Are the models the same or different?

 

This paper is the second of three addressing that question

It was written primarily to clarify the BCS model, but it may help you interpret ArchiMate concepts as well.

This paper is deliberately written along the same lines as “The Anatomy of the ArchiMate Language” by Lankhorst, Proper et al. (2008).

Contents

Enterprise system elements (recap)

Further generalisations

What it means to treat the enterprise as system

A naïve illustration

Ambiguities

Behaviour: transient processes and services

Structure: persistent components and interfaces

Conclusions

Appendix: finding the core concepts in other sources

Appendix: Limits to the mechanical-human system analogy

Appendix: Limits to enterprise architecture

 

Enterprise system elements (recap)

The word “architect” comes from the Greek “master builder”.

In enterprise and solution architecture frameworks, the buildings are “systems”.

“Enterprise architecture regards the enterprise as a system, or system of systems” (TOGAF)

Architecture descriptions are formal descriptions of a system.” (ArchiMate® 2.1 Specification, The Open Group.)

 

The ArchiMate standard employs a conceptual framework of generic system elements, presented in a simplified form below.

After ArchiMate

Behavioural view

What a system does

Structural view

What a system is made of

External view

requirements of

external entities

Events/Services

each encapsulates the processing

of a discrete event or service request.

Interfaces

each is a facade that presents

services for access by clients

Internal view

the workings of

the system

Processes

each comprises one or more activities that

respond to an event or meet a service request.

Components/Roles

each is a subsystem that

performs process steps.

 

One architect’s whole system is another’s component in a wider system, so this model can be applied at any level of granularity.

There is a fifth kind of system element: an object: an item or structure that is used, moved or made by processes.

Further generalisations

Here are few generalisations about the concepts above.

·          Every process and service runs from a start or trigger to an end or result.

·          Processes and services are called behavioural (aka dynamic) elements.

·          Behavioural elements are performed by or accessed via structural elements.

·          Components, roles and interfaces are structural elements - designed to deliver the behaviour required of the system.

·          Structural elements are deployed in locations to do work.

 

Architectural entities can relate to each other in various ways, for example:

·          A component/role can execute one or many processes.

·          A component can be decomposed into smaller components.

·          A process can be executed by one or many components/roles.

·          A process can be decomposed into shorter processes.

·          A process can be encapsulated behind a service.

·          A component can be encapsulated behind an interface.

·          A service can be accessed via one or more interfaces.

·          An interface can expose (make accessible) one or more services.

 

In what is sometimes called "realisation", the external view of a system encapsulates and is implemented by its internal components and processes.

More specifically, services are implemented by processes, and interfaces are implemented by components.

 

In what is sometimes called "construction", the behavioural elements of a system are assigned to structural elements.

This means services are assigned to interfaces, and processes are assigned to components.

What it means to treat the enterprise as system

In terms of general systems theory, a system has components that cooperate in processes to maintain the state of the system and enable it to meet its goals.

 

COMPONENTS

PROCESSES

Heart

Blood vessels

Lungs

Liver

Transport oxygen

x

x

x

 

Transport and detoxify waste

x

x

x

 

It is probably obvious that each component in the table above can be decomposed into smaller components.

And each process can be decomposed into shorter process steps.

Both abstraction and its opposite, refinement, are necessary in describing a large and complex system.

 

In EA, enterprise components and processes are recorded in EA description artefacts – usually in matrices and diagrams.

For example: an enterprise’s organisation structure of likely composed of many units (structural elements).

Such as: Executive, Marketing, Sales, Delivery, Finance, Human Resources and Procurement.

 

These structural components cooperate in “end-to-end” processes that can be divided into process steps (behavioural elements).

E.g. the table below shows which components cooperate in a marketing campaign process.

COMPONENTS

Campaign PROCESS STEPS

Executive

Marketing

Sales

1.      Understand product to be sold

x

x

 

2.      Design advertisement(s)

 

x

 

3.      Get executive approval

x

x

 

4.      Publish advertisement(s)

 

x

 

5.      Record responses

 

x

x

6.      Distribute responses to sales people

 

 

x

 

Note again that abstraction, here by hierarchical composition of fine-grained components and processes into coarse-grained ones - is necessary in describing a large and complex system.

An enterprise architecture usually describes system structures and behaviours at a very abstract level.

A naïve illustration

Consider a restaurant as a system, as a fuzzily-definable human activity system; one can identify

 

·         Business interfaces: menus presented to customers, perhaps in the window, perhaps by waiters

·         Business services: requestable items (starters, main courses, desserts and drinks)

·         Business processes: ordering, serving, taking payment, cooking.

·         Business components (functions or roles): waiter, cook, oven, dishwasher.

·         Business objects: food ingredients, pots and pans, orders, payments, receipts.

 

A restaurant menu can be likened to an application programing interface (API).

The role a waiter plays in presenting a menu can be likened to the facade role a software module plays in presenting an API.

 

A system employs façade components to realise its external interfaces.

A restaurant can employs waiters to present menus and take orders.

A software system can employ “web services” to present APIs.

Ambiguities

Given the meta model is so generic, so simple, there are inevitably some ambiguities.

 

Can an active component be a passive object?

An active system element, called a component, does work, it executes processes.

A passive system element, called a passive object, is an item or structure acted on by processes.

The notion in natural language is that subjects perform activities on objects.

The notion in architecture description that active structural elements perform behaviour on passive structural elements.

 

However, when an active component is transported somewhere, or placed in a position, then is being treated as a passive object.

E.g. An application appears twice in the ArchiMate meta model – as an activity component – as a passive deployable artefact.

 

Is an interface passive or active?

The conceptual framework suggests an interface is active structure;  but in practice we allow that an interface can be:

 

·         Passive: e.g. a menu, a WSDL, an SLA.

·         Active: embodied in a facade component that forwards events or service requests (e.g. a waiter, a web page, a help desk).

 

As long as a facade component has no intelligence except where to send messages, it is convenient to call it an interface rather than a component.

 

Can components behave spontaneously?

All human and computer activity system models we build are event-driven.

Entities and activities in the wider environment may act in what appears spontaneous behaviour.

But within our systems of interest, a component never executes a process without a trigger event.

And its behaviour  is deterministic, meaning its response to an event is determined by the current system state.

 

Suppose a person is employed to play a role in a system acts spontaneously, outside the role defined for them in the system description.

Then that action is outside the system boundary according to the system theory applied here.

 

(However, a component can act in an apparently spontaneous way by using a random number generator to select between actions in response to an event.)

Behaviour: transient processes and services

In natural language, we often form sentences in which subjects perform activities on passive objects: for example, boys climb trees.

The passive objects in one sentence can be subjects in another sentence: for example, trees consume water.

Processes

Process: One or more activities, triggered by an event or service request, leading to a result or output.

The activities can be arranged under a logical control flow, and are performed by one or more components.

Architects have various ways to define a process: a flow chart, use case definition, interaction diagram or service contract.

Business process: a process performed in a business, terminating in a service or result.

Application process: a process performed by a business application in the course of a human use case or fully automated service.

Platform process: a process performed by a platform application, usually invisible to an architect.

 

How to document a process?

To complete the definition of the process, an architect may describe how to make the process start, why it exists, and other characteristics.

A use case template wraps the description of a process flow inside the attributes of a service contract (highlighted in yellow below).

The process flow itself can be documented in various styles.

Find a general process definition template in this paper.

 

Although non-functional requirements are commonly applied to a whole component or interface, the customer requirement applies to each kind of discrete service they request.

 

Services

Inside a system, components perform and cooperate in processes.

In the wider environment, from outside the system, all that can be seen is the system boundary and the events that cross that boundary.

Systems are designed to deliver “services” requested by external clients.

 

Service: The external view of the process that responds to a singular event or service request.

Named examples include: check customer credit, provide weather data, consolidate drilling reports (from TOGAF), policy creation, premium payment, claim registration, claim (from ArchiMate).

A service encapsulates processes needed to deliver the desired result, and is describable using a service contract.

For the external users, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant.” ArchiMate.

Business service: a singular service (e.g. order, pay, report, weigh) that can be requested of a business by customers, suppliers or employees.

Application service: a singular service that can be requested of a business application; a human use case or fully automated service.

Platform service: a singular service (e.g. transaction roll back or user authentication) that can be requested of a platform applications by business applications.

 

Find a general process definition template in this paper.

 

Structure: persistent components and interfaces

A system description usually assigns active structure to perform behaviour, that is, it declares who or what components will perform which processes.

 

The paper “The Anatomy of the ArchiMate Language” suggests an actor is an individual and a role is a collection of individuals.

However, general system theory draws an even more fundamental distinction between concrete individuals and abstract types.

A role is not so much a set (a group of individuals) as an abstract type (a generic description of an individual set member).

Components (Roles)

Component: a subsystem that executes processes.

A persistent component that performs activities or gives access to behaviour.

It can be specified in a component/role definition.

Business component: an organisation, human role or machine capable of performing business activities and offering business services.

Business application: a software system capable of offering use cases or automated services.

E.g. Billing, CRM.

Platform application: an infrastructure component capable of offering the platform services business applications need.

E.g. Operating system, message broker.

 

Components are sometimes called actors or roles, and commonly, the terms are used interchangeably.

Here, roles are types and actors are instances.

As a crude generalisation, EA is a description of component types rather than instances.

The instances of the components in an operational system may be recorded in a Configuration Management Database (CMDB).

 

Role

a general component type; it defines a general responsibility for performing a defined group of activities or offering a defined group of services.

A role can be played by one or more actors, but a role is type rather than a set.

Actor

a specific component instance (e.g. an insurance company, a person, a mainframe, etc.) that is capable of playing a role.

If a role is played by only one actor, you may use the actor name for the role.

 

How to document component types?

A complete definition of a component or role defines both external and internal views, so it includes an interface definition.

Find a general process definition template in this paper.

 

Components cooperate in processes that act on passive objects.

EA is concerned with the description of passive object types (whereas passive object instances are recorded in the corresponding operational system).

Passive objects

Inside a system, components perform and cooperate in processes that act on passive objects.

 

Passive object: An item or structure that is used, moved or made.

An entity that is the object of an activity.

In EA, the passive objects are commonly parcels of information.

Business object : a parcel of unstructured data processed by business people.

Data entity: a parcel of structured data items processed by application components.

Platform artefact: a parcel of data deployed to a technology component.

 

It is possible to model physical objects and goods as well as information objects, but the passive objects addressed in EA are often information objects.

Some information objects are made or used inside a system, and some move across the system boundary into or out of the system.

 

Components cooperate in processes, which are behavioural elements rather than structural elements.

Interfaces (note the ambiguity)

Note the earlier discussion of ambiguities.

Perhaps the biggest debatable question in these papers is whether an interface is best described as one or both of:

·         a menu – a passive structural element - an abstract specification listing service offered

·         a water – an active structural element - a role that presents a menu - a facade component that accepts service requests and directs them for processing

 

In ArchiMate, it appears that an interface is the latter, it is a point of access, found at a specific location.

We allow both meanings.

An interface can be a facade - a point of access to a collection of one or more discrete services – including location and connection details.

An interface can expose (make accessible) one or more services.

Every component can be encapsulated by an interface.

 

Interface: a facade that presents a system’s services for access by entities in the wider environment; it constitutes an external view of a system’s active structure.

Business interface: a facade where external entities can request services offered by business components, or external events are recognised.

It could be defined in some kind of SLA.

Application interface: a facade where business components (and other applications) can request services offered by business applications.

It could be defined in a user interface or an API.

Platform interface: a facade where business applications (and other platform applications) can request services offered by platform applications.

It could be defined in the form of an API.

 

The logical part of an interface is a menu of services.

When a service has been assigned to an interface, this assignment must be mirrored (inside the system) by the assignment of relevant internal components to relevant internal processes.

 

Having assembled a menu of cross-system-boundary events or services, the logical interface can be made physical when it is published at a location where clients can access the services.

Further, the interface may be assigned to a façade component that holds and publishes the menu, accepts input and delivers output.

The interface can be extended with other attributes, such as protocols for message transmission, and the physical channel or medium via which input and output objects are transported.

Find a general process definition template in this paper.

Conclusions

In short, human and computer activity systems can be described using the same general concepts and descriptive artefacts.

And the general concepts can be specialised for each architecture domain.

 

System description concepts are most readily distinguished by the attributes and relationships we use to describe them.

Find a general process definition template in this paper.

 

Appendix: finding the core concepts in other sources

The table below is an attempt to resolve some terminology confusions.

 

Generic concept

I propose Ref. Model should use these terms

ArchiMate terms

TOGAF terms

Process

 

Business process

Process/Function

Business process

Application process (internal flow of application service)

Application function

 

Platform process

Infrastructure function

 

Service

 

Business service

Business service

Business service

Application service  / Use case

Application service / Automated service

Application service

Information system service

Platform service

Infrastructure service

Platform service

Component

 

Business component / Business function

Business component / Organisation unit

Business component / Business role

 

 

Business role

Business actor

Business function

Organisation unit

Role

Business application

Application component

Application  component

(Logical and Physical versions)

Platform application

Node

Node / System Software

Node / Device

Technology Component

(Logical and Physical versions)

Interface

 

Business interface

Business interface

 

Application interface

Application interface

 

Platform interface

Infrastructure interface

Application platform interface

Passive object

Business object

Business object

 

Data entity

Data object

Data entity

Deployable artifact

Artifact

 

 

And note FYI.

 

Generic concept

WSDL terms

Windows terms

Application service

Operation

 

Business application

 

Process, Application

Platform application.

Node. 

 

Process, Service

Application interface 

Service

 

 

Appendix: Limits to the mechanical-human system analogy

There is a limit to how far you can push the analogy between mechanical and human activity systems.

There is a difficulty with extending the analogy to human activity systems.

Formal system descriptions cannot adequately accommodate the self-awareness, creativity and unpredictable flexibility of human components

 

Not only are human components are inventive and flexible, self-directed and multi-talented, far beyond any role that might be documented in any system description.

But most enterprises rely on this, at least in those humans who play more senior roles.

 

Consider, again, a restaurant as a fuzzily-definable human activity system.

A great deal of what happens in the system is implicit, understood without any need for communication.

But here are some services involved.

 

·         Customers implicitly make an unspoken request for a general service: “please give me a pleasant dining experience, along with any companions that join me.”

·         Customers may voice a request for more specific meta service: “please show me the menu”.

·         The menu lists the more specific services a customer can request – via an actor playing a waiter role - from the restaurant.

·         In answering those requests, a customer or manager may request subsidiary services from a waiter actor: take order, serve meal, clear dishes, take payment.

 

However, everything in a human activity system is flexible.

The human (actor) playing the waiter (role) may

·         initiate and complete required services without being requested to do so.

·         be asked to play another named role (e.g. dishwasher).

·         invent a new role and play it.

·         behave spontaneously in ways unforeseen in any prior system description.

 

A human actor is an amazing general-purpose component, capable of providing an infinite variety of ad hoc services to anybody who asks.

E.g. “please take a photo of my wife and me”.

Such ad-hoc services could never be defined in a formal system description.

Appendix: Limits to enterprise architecture

Enterprise architecture (EA) is focused on enabling and improving business roles and processes that are repetitive and deterministic enough to be systematised and digitised.

In other words, it does not focus on roles and processes that are informal, ad hoc and continually changing.

 

There must be some rules: e.g. executive approval must be sought for adverts.

You can design a marketing process to be flexible; you could:

·         Design alternative process paths. E.g. executive approval may be skipped for adverts costing less than a threshold value, say 1 thousand dollars.

·         Include adjustable variables in the rules. E.g. The approval threshold can be an adjustable variable.

 

However, the kind of flexibility that employing humans naturally brings to a process is not normally addressed by an enterprise architect.

Obviously, the marketing process relies on human intelligence and creativity.

Yet at the level of abstraction described by enterprise architects, as illustrated above, the marketing process remains a designed, repeatable and deterministic process.

 

Humans are not machines.

In operation (at run time) a human actor playing the marketeer role might deliberately ignore the designed process steps, break documented rules, subvert the organisation structure, whatever.

E.g. They might publish a 1 million dollar advert without executive approval.

Or, they might sell advert responses to a rival company.

 

So while the description-time enterprise architecture remains an orderly system of repeatable, deterministic processes, the run-time operational enterprise may depart from that system.

That may be desirable; in fact most businesses depend on human flexibility.

The question here is how far an enterprise architecture, or any system description, can or should reflect such human flexibility.

 

Suppose enterprise architects documented that the organisation’s human actors can ignore designed processes, break documented rules, subvert the organisation structure, do whatever they choose.

Then, what the enterprise architecture describes would no longer be a system; it would no longer prescribe the system’s structure or behaviour.

Nobody reading the enterprise architecture could predict what the enterprise will do.

 

The enterprise may depend on human intelligence, self-awareness, creativity, flexibility and the ability to act in undocumented and unpredictable ways.

But, by definition, those actions are not systematic; they cannot be captured in an enterprise architecture artefacts; they lie outside of the enterprise architecture.

 

Enterprise architects set out to treat the enterprise as a system in which the processes are designed, repeated and deterministic.

Behaviour that is not designed, repeatable or deterministic is simply not recorded in an EA description.

 

 

Published under the Creative Commons Attribution-No Derivative Works Licence 2.0                                          29/01/2015 19:55

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” at the start and include this footnote on each page .

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this paper, not derivative works based upon it..

For more information about the licence, see http://creativecommons.org.