Architecture and System (Description and Reality)

One of more than 200 papers at Copyright Graham Berrisford. Last updated 09/01/2017 13:48

And one of several papers on the home page about the terms and concepts used in architecture frameworks.

·         Enterprise & Solution Architecture   EA and the Digital Enterprise   EA and Strategy

·         Building Blocks, Interfaces and Services    Architecture and Design    Architecture and System    TOGAF-ArchiMate alignment.


Questions to be answered in this paper. 1

Separating architectures from systems. 2

Mainstream EA.. 3

Sequences in system operation and in system design. 4

General system theory and change control 4

Systems and architectures. 5

Answers to the questions. 6

Footnote on ISO/IEC 42010: 2011. 7


Questions to be answered in this paper

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

An architecture defines a system.” ArchiMate 2.1

“Architecture: a formal description of a system, or a detailed plan of the system at component level, to guide its implementation”. ISO/IEC 42010: 2007


Unfortunately, in different times and places, the three standards quoted above have confused “architecture” with “system”.

This paper explores these two concepts.


People studying architecture frameworks like TOGAF often ask questions like these:

·         Does “architecture requirements” = “system requirements”?

·         Does “architecture definition” = “system definition”?

·         Does “architecture implementation” = “system implementation”?

·         Does “architecture change management” = “system change management”?

·         Does “ensure the architecture lifecycle is maintained” = “ensure the system lifecycle is maintained”?

·         Does “ensure the architecture achieves its target business value” = “ensure the system achieves its target business value”?


This paper answers the questions above, starting from first principles.

Separating architectures from systems

You may not think you are a philosopher, but you have to start by distinguishing descriptions from realities.

Realist philosophers say realities have descriptions, which describers can discover.

Idealist philosophers say describers create descriptions to help them deal with realities.

The practical idealism applied by enterprise architects separates describers, descriptions and described realities.

Enterprise architecture


<create and use>           <idealise>

Architects  <observe and envisage>  Systems


Architects define and use architectures of systems (past, present and future).

Architectures are descriptions that abstract concepts from (encode properties embodied in) systems observed and envisaged.

Systems embody structural and behavioural concepts that are describable by architects.


More generally

A system can be natural: be it physical (a solar system, a hurricane), biological (a tree), or social (a beehive)

Or else it can be designed: be it social (a tennis match) or technological (a bicycle, a computer).

If it ain’t described before it exists, then it designed.


People abstract descriptions from observed realities.

E.g. cartographers draw maps of territories.



<create and use>                   <idealise>

Cartographers   <observe and envisage >    Territories

& map readers


At creation time, a map is drawn to model a real-world territory.

At usage time, the map is read by people to find their way around that territory.


People also instantiate descriptions of realities that have been envisaged.

Some descriptions are designs - created with the intention of constraining how real things are built and/or behave.

·         Mozart wrote the score of a symphony to describe and constrain an orchestra’s performance of that symphony.

·         Engineers describe a “real machine” before that description is instantiated.

·         Building architects draw architectural drawings to describe and constrain the construction of buildings.


Enterprise architects document architectures to describe and constrain the construction and operations of operational business systems.

Enterprise architecture

Architectures and designs

<create and use>           <idealise>

Architects  <observe and envisage>  Systems


Note there is fuzziness, business systems don’t always conform exactly to their architectures.


Normally, the things that instantiate a type are only partly described by that type.

There is an exception, in software design, the attributes and behaviors of objects that instantiate a class are completely described by that class.

OO programs


<code and read>     <instantiated by>

Programmers   <test and envisage>    Objects

Mainstream EA

A business system can be seen as formalised social system in which business actors include both humans and computers.

To define a business system, it is not enough to enumerate the actors, or typify them.

A sociologist may presume a social group does what it does (activities) to satisfy what the social group is (actors).

By contrast, in a business system, the requirement is for actors to do things, to perform roles in processes as required by system sponsors/stakeholders.

Business system behaviors are defined in terms of services provided by value streams/scenarios/processes/activities.


Mainstream EA is about business systems describable in abstract models of repeatable behaviors and the actors/components that perform them

It is about designing and planning changes to business systems in which it is presumed that:

·         A collection of actors (structures) will perform roles in activities (behaviors) to provide required services.

·         The system changes externally when service types are changed.

·         The system changes internally when activity types or actors’ roles are changed.

·         The system does not change when individual actors are replaced.

·         An abstract description of the system should be accepted by its sponsors/key stakeholders

·         The description will be revised and approved before the operational system is changed.


Any observer may form a mental or documented model of an existing system in operation.

An observer may say their model represents the “design” or the “architecture” of the operational system.

But the observer/describer cannot reasonably claim to be the “designer” or the “architect” of that system.


The main job of an architect is not to describe existing systems; it is to design systems yet to be implemented

Given requirements to build or change a system, an architect defines the architecture of a system to meet those requirements.


A system description has no value to an architect if it cannot be instantiated by a working system

Conversely, a working business is not "a system" except where it can be described as one.


Without an enterprise-wide view, there is nothing describable as an “enterprise architecture”.

There is only a collection of discrete and diverse human and computer activity systems.


Human actors behave unsystematically in the workings of a business.

Much of that behavior is vital to the success of a business.

But it lies outside of what can be described as a system.

It lies outside of what enterprise and solution architects design.


It is important to acknowledge that enterprise and solution architects cannot describe or design all that matters in an enterprise.

A huge amount of the behavior in an enterprise is very human indeed.

Much if not most of what people do in a business is beyond any generalised description of roles and rules.

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

Sequences in system operation and in system design

At the risk of being simplistic, a business system operation works as in the left hand column of the table below.

And a natural system design method is to (roughly) reverse the run-time sequence - as in the right hand column of the table below.

After implementation, run-time actors should behave in reality as the design-time description directs them to behave.

A sequence in run-time reality

A sequence for design-time description


Input events/messages trigger…

Goals - desired outcomes


Actors to perform activities in rule-driven…

Outputs to enable the goals to be met


Processes, that consume inputs and use resources to make…

Inputs and resources needed to make the outputs


Outputs, and so enable the consumers of those outputs to realise the…

Processes/rules to transform inputs into outputs using resources


Goals, the desired outcomes, of the system sponsors.

Actors to perform the processes


Resources needed by actors to do the work

General system theory and change control

 “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 behavioristic.” Ross Ashby.


How to differentiate a system from any other entity might think about, describe or design?

General system theory sees a system as an entity whose processes are repeated or repeatable.

The processes cooperate to reach homeostasis or another goal.


You can describe an entity’s goals and processes.

But that remains only a theoretical systems until tests show the entity’s processes match your theory.


Suppose the processes change while you describe them?

Then the entity cannot be called, described or tested as a system.


What if some of the entity processes are not changing?

Then only those can be called, described and tested as a system.


Is IBM a system?

IBM does have repeated and testable processes.

But some are unrelated, some compete, and some undermine each other; so IBM is countless systems.


Surely IBM divisions cooperate by contributing to a profit/loss variable?

Yes, IBM is one system at this level, but it is a trivial one.


Surely IBM is a "complex adaptive system"?

You mean it is social group in which people do whatever they choose to make a profit?

A group of people doing whatever they choose to do, in a disorderly way, with no change control, is not a system..


System change control

“Darwinist evolution in biology is not goal-directed with a fixed forward-looking goal; rather, species adapt themselves to an ever changing environment.”

Natural physical systems (e.g. the solar system, a hurricane) may evolve continually.

Natural biological systems (plants and animals) evolve in discrete steps, by sexual reproduction.

A designed system also evolves in discrete steps, by design.

It cannot evolve continually because it is an instantiation of a system description (a theoretical system) which must first be changed.


The systems described and designed by enterprise and solution architects are usually under change control.

Change control means an operational system cannot evolve to a new version until a change to the system description has been approved.

Architecture frameworks presume that change requests are evaluated against a documented system model before they are accepted.

In practice, this idea is watered down, because the documented system models are so abstract - not complete or accurate enough,

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

Systems and architectures

A thing has as many descriptions as people make of it.

A house has as many architectures as are drawn of it.

A system has as many architectures as people think of or document.


Does every system have a description? Yes, because a system is a human construct imposed on reality.

Does every system have an architecture? It depends.

If any system description can be called an architecture, then every system has an architecture.

If the architecture must be an abstract and documented description, then not all systems have an architecture (see “Architecture versus design”).


If the operational system changes to the extent that it stops matching that abstract description, then it stops having that architecture.

However, the match of an operational system to an abstract architecture can be imperfect, so may be a matter of judgement.


If two system descriptions have no point of correspondence, then they are descriptions of different systems – not views of one system.

If a real-world thing is described in two unrelated system descriptions, then it is two different systems at once.

Those two descriptions become one description when any point of correspondence between them is identified.

So, the more that the discrete business system architectures of a business are coordinated, standardised or unified, the more they can be regarded as enterprise architecture.

Answers to the questions

What do architecture framework authors mean by “architecture”?

A description is an abstraction (model, or theory) of an observed or envisaged reality.

A system description is an abstraction (model, or theory) of an observed or envisaged operational system.

An enterprise architecture is description of observed or envisaged business systems.


Descriptions in system theory

Architectures as in enterprise architecture

A system description is a model of an operational system.

An architecture is a model of a business system.

An operational system is a realisation of a system description.

A business system is a realisation of an architecture.

An operational system is only a system in so far as it matches a system description.

A business system is only a system in so far as it matches an architecture


Does “architecture requirements” = “system requirements”?

·         Yes. (The requirements for an architecture would be different, e.g. exposing issues and getting approval.)


Does “architecture definition” = “system definition”?

·         Yes. (To define an architecture would be to model the structure of a description.)


Does “architecture implementation” = “system implementation”?

·         In one sense no, because an architecture is implemented (via detailed design) in system procedures?

·         In another sense yes, because the system’s procedures are performed later, in operation, at run time?


Does “architecture change management” = “system change management”?

·         No. It means managing changes to architecture definition/documentation.


Does “ensure the architecture lifecycle is maintained” = “ensure the system lifecycle is maintained”?

·         No. It means maintain the architectural documentation in step with system changes.


Does “ensure the architecture achieves its target business value” = “ensure the system achieves its target business value”?

·         No. It means ensure the documentation is useful in future – benefits exceed costs.


It turns out that authors are sometimes referring to architecture definition/documentation.

And sometimes they are referring to an operational system described in such documentation.

“Architecture” as a distinct concept is redundant and best cut out using Occam’s razor.

Footnote on ISO/IEC 42010: 2011

An architecture defines a system.” ArchiMate 2.1

“Architecture: a formal description of a system, or a detailed plan of the system at component level, to guide its implementation”. ISO/IEC 42010: 2007


But international standards and sources are inconsistent, and the two standards above have at different times tended to confuse “architecture” with “system”.

ArchiMate 3.0 says “The ArchiMate language [focuses] on describing the architecture of systems that support the enterprise.”

And that change was probably made to reflect a corresponding change in ISO/IEC 42010: 2011 on the architectural description of software-intensive systems.

The standard now appears to suggest architecture is purely abstract concept, aside from a system and a description of it.

Five core terms in the standard are:

·         system of interest – the standard leaves the definition of “system” to the user of the standard, it offers no system theory

·         architecture description – a work product describing the characteristics, features and design of a system, for potential clients and others.

·         architecture - a concept that stands apart from both description (architecture description) and reality (system of interest).

·         architecting – which creates an architecture description (note, not “designing”)


The standard was written on under the presumption that architecture is different from design (the subject of other ISO standards).

But most people do not regard architecting/architecture as sharply distinct from designing/design in this way.


The standard includes this curious triangulation of 1 system to 1 architecture to 1 architecture description

ISO/IEC 42010: 2011

 1Architecture Description

<expressed by>       <identifies>

1 Architectures <exhibited by>  1 System


This triangulation is highly questionable.

Not only because the relationship between description (architecture) and reality (operational system) is many-to-many.

But also to suppose that architectures exist as ethereal concepts outside of systems and descriptions of them is to adopt an odd philosophy.

The more practical philosophy (perversely called “idealism”) is that architectures exist in mental, documented and physical models.

The architecture of interest here is a documented model that is agreed as describing an operational system that is observed or envisaged.