Architecture and Design - Nine Abstraction Varieties

One of more than 300 papers at Copyright Graham Berrisford. Last updated 24/08/2017 23:13


Grady Booch has written that all architecture is design, but not all design is architecture. What does he mean?

This paper is mainly about ways to abstract an enterprise architecture from more detailed design.


Preface. 1

Abstraction of behaviors from structures. 3

Abstraction from detail 3

Abstraction by composition. 4

Abstraction by encapsulation of system behaviour, structure and data. 4

Abstraction by separation of parallel views. 5

Abstraction by delegation from clients to servers. 6

Abstraction by generalisation of features. 6

Abstraction by idealisation of features. 7

Abstraction of data from applications. 7

Conclusions. 8

Footnotes. 8




A few points to get us started.

An “architect” (from the Greek for “master builder”) is typically defined as one who designs and supervises of the construction of a building.

And “architecture” is defined as the art of designing and constructing buildings, or the style in which a building is designed and constructed.

But discussing building architecture doesn't get us far, since EA is about activity systems rather than visible concrete structures.

The “buildings” are business activity systems in which humans and computers play roles in the performance of processes.


Business systems

“Enterprise architecture… regards the enterprise as a system or system of systems.” TOGAF 9.1

Business systems can be seen as formalised social systems, in which the principal actors are humans and information/communication technologies.

EA is about why, when, where and how business roles and processes create, store and use information.

It defines business activity systems by typifying inputs, outputs, actors and activities that capture and use business information.

These systems are unlike concrete buildings in several ways, for one, they are recursively composable and decomposable.



The meaning of “architecture” in relation to business systems has been a cause of debate from the outset.

John Zachman did not introduce the term in this context; the term was already in common use.

“In 1978, Zachman stated: “architecture is a term that is rapidly losing meaning".


Here, an architecture is an abstract model of an operational system (which reifies or realises the architecture).

Obviously, documented models are more stable and shareable than mental models.

Professional architects can’t and don’t keep their architectures in their heads.


Zachman put it thus.

“If… you can’t remember everything… you have to write it down (Architecture).”

“If you are not building primitive models, you are not doing Architecture. You are doing implementations.”

Zachman proposed maintaining architectural documentation at 5 levels of abstraction from operational systems and in “excruciating detail”.

This elaborate proposal has (so far, at least) proved impractical.

Nevertheless, architecture is more abstract than detailed design.



Abstraction as two general meanings:

1.      Abstraction from reality (physical matter and energy) to description of it.

2.      Abstraction of description - from more detailed descriptions/models to less detailed ones, sometimes called architectures.


This table illustrates the first - abstraction from reality to description of it.

Abstraction in system theory

System descriptions/models

<create and use>                  <abstract from>

System describers <observe and envisage > Systems in operation


The second definition – abstraction of description - masks many varieties of abstraction.

Zachman proposed architects should abstract from detailed designs in one particular way called idealisation

In practice, architect use several kinds of abstraction at once, both consciously and unconsciously, when describing an operational system.

They may abstract in these ways more by artistic intuition than by scientific reasoning, but skilled architects do consciously manipulate them.

When you are done reading this paper, for more on abstraction, read “Abstraction in TOGAF”.

Abstraction of behaviors from structures

“The principal heuristic innovation of the systems approach is what may be called reduction to dynamics’ as contrasted with ‘reduction to components’ ” Laszlo and Krippner.

"Cybernetics does not ask "what is this thing?" but ''what does it do?" It is thus essentially functional and behaviouristic.” Ross Ashby.


Building architects design physical and persistent structures - concrete buildings.

Business systems feature logical and transient behaviours – they can be seen as formalised social activity systems.

·         Passive thing: a structure that is described as being acted on or in.

·         Active thing: a structure that is described as acting on other things; it performs behaviours.

·         Activity system: a collection of structural entities (e.g. planets) that perform orderly behaviours (e.g. orbits).


In operation, social and business systems feature actors (structures) performing activities (behaviours).

A social system may be designed with the requirement that the activities should satisfy given actors.

However, mainstream EA is about designing and planning of changes to business systems.

In most businesses, the requirement is for actors to perform given activities to provide required services.


What a client requires of a business system are the products of activities, rather than the structures needed to perform those behaviours.

An architect that describes only internal structures fails to describe what matters to owners and customers of an enterprise.


Behaviour before structure

ArchiMate 3.0 says “it is often useful to start with the behaviors that the system must perform”.

Architects designing business activity system must clarify and define:

1.      Goals, desired outcomes (collecting problems, requirements and other motivational/contextual information).

2.      Outputs to enable the goals to be met (that is, the products/services required of the system to be built).

3.      Inputs needed to make the outputs (these resources include inputs taken from stores).

4.      Processes/rules to transform inputs into outputs using resources (that is, behaviours that will deliver the required products/services).

5.      Actors to perform the processes (that is, active structures that will perform the required behaviours).

6.      Technologies and other resources needed by actors to do the work.


Of course, a huge amount of the behaviour in an enterprise is very human indeed.

Enterprises depend on intellectual, intuitive and creative abilities, social skills and empathetic behaviour, and on manual labouring skills.

The human actors – who play roles in a business system - need management and motivation.

It is important to acknowledge that enterprise architects do not describe or design all that matters in an enterprise.

Abstraction from detail

In the 1980s, the work of architects was divided into four domains.

The aims and activities of architecture and design may be divided also into levels of detail, along the lines in this table.










Business roles & processes,

standardisation, integration

and road maps

Business data

standardisation, integration

and road maps

Business application portfolio

standardisation, integration

and road maps

Platform technology portfolio

standardisation, integration

and road maps



Outline design of a solution’s

required processes

Outline design of a solution’s

data architecture

Outline design of a solution’s

application architecture

Outline design of a solution’s

IT production environment



Detailed design of

processes & use cases

Detailed design of

data stores and flows

Detailed design of

software architecture

Detailed design of an

IT production environment


Most other kinds of abstraction (below) can be seen as hiding details in one way or another.

Abstraction by composition

Again, system descriptions are unlike building drawings in that they are recursively composable and decomposable.

Architects usually stop decomposing a system well before reaching atomic elements.

So what they describe are usually coarse-grained compositions.

Other people (designers or builders, perhaps even system actors) are left to define finer-grained elements.


Architects may decompose a large system (even an enterprise) from the top-down by dividing it into successively smaller subsystems (units, functions, capabilities, components).

But they rarely describe the lowest conceivable level – atomic, indivisible - actors and components.

They may decompose a long business process (perhaps a “value stream”) from the top-down by dividing it into successively shorter process steps.

But they almost never describe the lowest conceivable level – atomic, indivisible – actions performed by actors and components.


Architects are sometimes taught to stop system decomposition around the third level, but all is relative.

The granularity of a third level element is variable, since it depends on the scope being described.

An architectural description of a human society likely ignores the internal architecture of a human body.

An architectural description of a human body likely ignores the internal architecture of a human cell.

An architectural description of a human cell likely ignores the internal architecture of a molecule.


Encapsulation (below) can be seen as a kind of abstraction by composition.

Abstraction by encapsulation of system behaviour, structure and data

Architects are taught to define systems from out to in, starting with the input/output boundary.

First, they define the external view of a system - hiding details of internal behaviours and structures.


ArchiMate 3.0 distinguishes “an external (black-box, abstracting from the contents of the box) and internal (white-box) view is common in systems design.

The external view depicts what the system has to do for its environment, while the internal view depicts how it does this.”

ArchiMate classifies these ideas as shown in the table below.


Behaviour elements

Active structure elements

External view



Internal view




Services are discrete behaviours that clients can request of a system.

Services typically consume and produce data flows (they can also consume and deliver materials).

Their input and output data can be defined declaratively in service contracts that encapsulate (hide) internal process flows and components.


Architects define systems, “building blocks” and “components” by defining the services required of them.

They may go on to group services into interfaces.

An interface is a collection of services that are made available to specific clients.

An interface encapsulates the internal actors/components and processes that implement or realise services.


External before internal

You can “reverse engineer” interface specifications from existing, physical, operational systems and components.

But a basic principle of system design is to define the external view before the internal processes and structures.

E.g. ArchiMate (see 20016 reference) defines service accessible via interfaces in an external view.

It defines process and components, to deliver those services, in an internal view.

Similarly, TOGAF (2011 reference) defines required services in an Architecture Requirements Specification.

It then defines the internal process and components to deliver those services in the Architecture Definition Document.

Abstraction by separation of parallel views

Architects commonly define parallel views of a system, each view omitting details found in the other views.

The architecture of a system may abstract by hiding other systems which run alongside it and interact with it.

E.g. an architectural description of the human nervous system may hide the blood system, lymph system, etc.


Delegation (below) can be seen as a kind of abstraction by separation of parallel views.

Abstraction by delegation from clients to servers

Architects often simplify a complex system by organising it into a hierarchy of client and server layers.

Clients abstract from servers by delegation - by requesting services without knowledge of the servers’ internal structure or workings.

This idea is used in network architectures, software architectures and business architectures.

The primary EA domains are often presented as client-server layers, as in the table below.


Required behaviours

Logical structures

Physical structures


Business Services

Functions, Roles

Organisation Units, Actors


IS or Application Services

Logical Application Components, Interfaces

Physical Application Components


Platform or Technology Services

Logical Technology Components, Interfaces

Physical Technology Components


Business before technology

Many speak of business and IT, without reference to IS.

Some then misguidedly classify IS under the IT heading rather than under the business heading.

But business processes and data are not owned by IT departments or IT services providers.

The business is responsible for ensuring it captures the data it needs, and maintains it sufficiently well for successful use.


Enterprise architects have to understand what information technologies can do.

Architects must attend to modern technologies and standards, if they are to digitise business operations that create and use information.

They may recognise opportunities that arise from technology innovations.

However, the technology is only there to capture and provide business data, and automate business rules.

And the data and rules are there to enable the provision of services by business roles and processes.

So architects ought to start from the business services, processes and roles, and the data they need.

Abstraction by generalisation of features

Architects are asked to comply with generic reference models, design patterns, principles and standards.

The “buy before build” principle steers architects in the direction of deploying generic systems and components.

They look for what is general to an industry (say telecoms), general to a function (say accounting) and common to all (say, email).

The generic components may be coarse-grained (packaged applications) or fine-grained (atomic data types).


Architects should specialise only where there is a significant advantage to the enterprise in having different or unique business systems.

Central government departments or agencies tend to have unique business systems.

Local governments are more likely to share business systems and components thereof.


Abstraction by idealisation (below) can be seen as a special kind of generalisation.

Abstraction by idealisation of features

Confusingly, the term “logical” is used by architects to mean abstract in any or all the ways above.

However, in the tradition of systems analysis and design methods, it means abstraction by idealisation.

The process of idealisation is commonly described as moving stepwise from real to physical to logical to conceptual.


ArchiMate 3.0 distinguishes between “conceptual, logical, and physical abstraction levels;

this corresponds with business objects, data objects, and artifacts, and the realization relationships between them.”


Architects draw various other distinctions between conceptual, logical and physical.

In the tradition of architecture frameworks, the logical level is usually considered to be technology vendor-neutral.

Logical architecture definitions often define system components in a vendor-independent way.

They are rarely if ever technology independent.


Logical before physical

You can “reverse engineer” a logical system specification from an existing, physical, operational system.

E.g. The modern OData standard protocol enables you retrieve a logical data model from a remote web data store.

But the natural design sequence is logical definition before physical definition.

E.g. TOGAF promotes logical (technology vendor-neutral) system specification.

It defines logical process, data and application components in the Architecture Definition Document.

It then proceeds to define physical components to realise those logical components.


When you are done reading this paper, for more on abstraction, especially idealisation, read “Abstraction in TOGAF”.

Abstraction of data from applications

Business systems retain memories; they store input data for future use.

Business system architects must address the location(s), confidentiality, integrity and availability of stored data.


Data before applications

You can purchase a COTS application with little or no prior analysis of its I/O data flows and data store.

The risk is that the application’s user interface, APIs and persistent data store will not fit your needs.

So, it is usually recommended you consider data architecture before applications architecture.


Business data can now include what can be transmitted to and captured from social media.

You may consider using social media applications to reach potential customers and gather information about them.

But first, you have to think about what it is you want to say, and what you want to learn.


Business data can now include what can be transmitted to and captured from the Internet of Things.

You may consider using monitoring devices to collect “big data”.

But first, you have to understand what data can be collected, and find a good use for it.


Some descriptions of a reality model that reality more accurately or completely than others.

Some architectures of an operational business system model that system more accurately or completely than others.

In short:

·         an architect/architecture steers and constrains more detailed designers/designs.

·         an architecture is a relatively abstract design for how a new thing is to be built, or description of an existing thing

·         an architecture is a model that can take several forms - mental, documented and physical.

·         in its most definitive form, an architecture is documented for approval by clients and for use by designers and builders working at a lower level of abstraction.


This paper outlines nine ways to abstract an architecture from more detailed design.

For more on the nine abstraction varieties below read “Abstraction in TOGAF”.


·         Abstraction of behaviour from structure

·         Abstraction from detail

·         Abstraction by composition

·         Abstraction by encapsulation of system behaviour and structure

·         Abstraction by separation of parallel views

·         Abstraction by delegation from clients to servers

·         Abstraction by generalisation of features

·         Abstraction by idealisation of features

·         Abstraction of data from applications


For a list of EA sources and standards history, read “EA and Digital Enterprise”.

Footnote 1: Change control

Enterprise architects deal with business systems that are under change control.

A change request is first evaluated again a system’s description before permission is given to move from version n to n+1.

Analysing the impact of a requested change is facilitated by documented models.


Having said that, few rely only on documented models when evaluating change requests to a business system.

A building architect’s drawing visibly corresponds to a real building – a change to one directly corresponds to a change in the other.

A business architect’s process models (for example) are more abstract and indirectly related to reality.

So change requests are evaluated also against the mental models held by the members of a change advisory board (CAB).

Footnote 2: Building architecture v enterprise architecture

Physical space, measurements and locations are central to building architecture.

They are side issues in much EA work.

How often does an EA specify the length, breadth, height, weight or position in space of an EA model element?


Building architects define components related in a persistent structure.

Their drawings show the shape and structure of physical things, their locations and abutments in physical space.

Every view they draw (of walls, doors, windows, floors, lift shafts, plumbing, wiring etc.) corresponds visually to the physical reality.

By contrast, the buildings of interest to enterprise architects, the objects of design, are business activity systems.

These architects start by considering the business activities to be supported and enabled.

They draw views of business activities and software applications, but these views are not visibly like the things they represent.

Their drawings are abstractions, far removed from physical materials and locations.

Enterprise architects define activities related in a transient behaviours or process flows.
EAs rarely model physical human actors, but do model their logical roles.
EAs might model physical organisation units, but prefer to model logical function/capabilities.
EAs might position human roles or business function/capabilities in specific geographic locations.

But they more likely map them to logical location types (say, home or data centre).

Do you include server-side IT architecture in EA?
In today's virtualised and cloud computing world, it is difficult to map even server-side platform technologies to physical locations.

Footnote 3: the difference between ideal-to-real and delegator-to-servant

People commonly confuse realisation and delegation relationships.

A butler does not realise his master; he serves his master by realising discrete service requests.

The opposite of realisation is idealisation; the opposite of delegation is serving.

This table distinguishes the two relationships.


Client to server relationships

Application to platform technology relationships

Client view

A client actor <delegates to> servers.

An application <delegates to> platform technologies.

A client role <is realised by> actors.

(The actors perform actions that are the responsibility of that role.)

A coded application <is realised by> executables.

(Executables perform actions that are the responsibility of that application.)

Server view

A server <serves> clients that make service requests.

A platform technology <serves> applications that make platform service requests.

A server <realises> service requests made by clients.

(The server does not realise the clients themselves.)

A platform technology <realises> service requests made by applications.

(It does not realise the applications themselves.)

Footnote 4: other sources

Other sources also place architecture above – at a higher level of abstraction than - detailed design.

 “Architecture design is more abstract than detailed design.

“Detailed design focuses on … implementation details.
“The ultimate purpose is to create a system that fulfills a set of valid requirements.”


And here are some graphical images that place architecture above detailed design.