The relevance of systems to EA

Copyright 2016 Graham Berrisford. One of about 100 papers on the System Theory page at Last updated 03/09/2019 16:13


Systems architects should understand the properties that characterise a system.

Because if it can't be described as having the properties of a system, then it ain't a system, and it can’t be designed as a system.


Preface (recap) 1

On “architecture” in EA.. 1

On hierarchical composition and decomposition. 1

More on behaviour specification. 1

Conclusions and remarks. 1


Preface (recap)


General system theory

General system theory emerged from considering what systems in different sciences have in common.

System theorists did this before and without consideration of business systems or software systems.

“The same concepts and principles of organization underlie the different disciplines (physics, biology, technology, sociology, etc.), providing a basis for their unification.” Principia Cybernetica


Generally, a system can be described as actors interacting in orderly activities to maintain the system’s state and/or transform inputs into outputs.

·       The actors are structures (in space) that perform activities - in roles and processes that are describable and testable.

·       The activities are behaviors (over time) that change the state of the system or something in its environment -  governed by rules that are describable and testable.

·       The state is describable as a set of state variables - each with a range of values.

·       An open system is connected to its wider environment - by inputs and outputs that are describable and testable.


Classifying the systems of interest to EA

There are many kinds of system, including physical and biological systems.

However, the systems of most interest to EA are one or more of the following:

·       A dynamic system, noting that it can maintain a passive structure, such as a record of system state data.

·       A designed system in which actors perform activities to meet given aims. E.g. a cyclist pressing pedals to move a bicycle forward.

·       An open system which consumes inputs and produces, noting that the boundary is always a matter of choice.

·       A social system in which actors exchange meaningful messages. E.g. a business activity system.

·       A scripted system in which actors perform prescribed activities. E.g. some violinists following the score of a symphony.


This table is an attempt to arrange system kinds in a taxonomy.

It is flawed, since (for example) social systems can be designed and open systems can be natural.


Discrete entity


disorderly entity

chaotic (and so

not describable)


organised, orderly, stable (in described ways)

Passive structure

does not act

Dynamic system

acts an orderly or rule-bound way

Natural system


Designed system

e.g. symphony or software system


e.g. solar system


e.g. tree,


Social system

e.g. bee hive,

hunting party

Closed system

e.g. System

Dynamics model

Open system

I/O exchange

across boundary


On the relevance of system theory to EA

EA is concerned with systems that can be characterised as above.

It is concerned with business systems that are open, meaning they transform inputs into outputs of value.


EA frameworks and standards presume we can model business systems in terms of roles and processes that create and use business data.

·       The actors include people and applications (not to mention sensors and microservices).

·       The activities include creating and using data in memories and messages that describe or direct things of importance to a business.

·       The state of the business is recorded in the data structures of persistent data stores.


In traditional building architecture, architects predominantly define structures.

By contrast, enterprise architects usually start by defining some required behaviors – some required services or processes..  

EA presumes human and computers actors will be employed to perform activities in defined roles and processes.

Of course, people do much of value that is not defined in roles and processes

But that is, by definition, not architected.


Modern EA frameworks and standards expect architects to define systems in terms of:

·       Behaviors

o   Services - provided to external entities (as declared in service contracts).

o   Processes – which order activities to deliver services

·       Structures

o   Active structures – actors and components that perform the behaviors

o   Passive structures – which are made, modified, moved or used by behaviors (mostly, data in messages and memories).


E.g. in TOGAF, architecture definition documents contain both:

·       behaviors (services, value streams, scenarios, processes, use cases) and

·       structures (organisation, function and capability decomposition hierarchies, applications)

On hierarchical composition and decomposition

To manage complexity, architects impose hierarchical structures on system elements.

They can do this from the top down and/or bottom up.


Structural system decomposition

Systems occupy space; larger systems are decomposable into smaller systems.

Enterprise architects

Decomposition stops at “atomic” actors or components whose internals are taken for granted by stakeholders interested in the system.


·       In defining a tennis match, we ignore the cardio-vascular systems of the players, give no thought to the complexity therein.

·       In defining a cardio-vascular system, we ignore the contents of the cells that the heart and lungs are composed of.

·       In an enterprise’s organisation chart, we cannot see the internal structure and behaviour of each employee.

·       In an enterprise’s application communication diagram, we cannot see the internal structure and behaviour of each application.


Business architecture is based on the "atomic activity" performable by a human.

Atomic activities are sequenced in behavioural ways (process, value stream).

And otherwise grouped in structural ways (role, organisation units).


Behavioral process decomposition

Behaviors run over time; a process is sequence of steps or actions.

Longer processes are decomposable into shorter processes, since every step/action in a process is itself a process.

Decomposition stops at “atomic actions” that are taken for granted by stakeholders interested in the process.


·       In defining a tennis match, we ignore how the players strike the ball, give no thought to the complexity therein.

·       In an enterprise’s value chain diagram, we cannot see the internal processes of “in-bound logistics”.

·       In an application use case description, we cannot see the internal processes of the application (say, on an application or data server).


In a natural systems, the processes have evolved without any given aims.

In a designed systems, processes are designed to delivering results of value.

·       Result = desired effect = output or system state changes.

·       Value = desired outcome = the use of results by external entities to meet their goals.


More on composition and decomposition of systems and processes

Some methods obscure general system theory by confusing system and process views.

Or comparing system and process views at different levels of granularity.

But in general, the two views are orthogonal.

·       A higher-level subsystem can encapsulate several lower level processes.

·       A higher-level process can span several lower-level subsystems.


The level of the system and process you describe is entirely up to you.

Having bounded system A, you can describe processes performed entirely within system A.

You can also describe higher level processes that coordinate system A with systems B and C. 


Subsystems at low level of system decomposition perform processes at a low level of process decomposition.

To complete a higher-level business process, subsystems must be coordinated - by orchestration and/or choreography.

The smaller the subsystem, the larger the inter-subsystem communication overhead.

The more loosely-coupled the subsystems, the greater the complexity of completing a higher-level business process.

(Read "What are the trade offs" in  the first section of this paper on microservices

More on behaviour specification   

EA is about the design of systems in which each process delivers results of value.

At any level of decomposition, a process can be defined procedurally or declaratively.


External or declarative view of a behaviour

If the preconditions of a process are met, and the process completes successfully, then the post conditions of the process will be met. 

This "Hoare logic" encapsulates a process – hides its internal process steps.         

To define a process thus is to express the requirement for that process.


In EA, a process that delivers value to a consumer may be defined declaratively in a "service contract".


Internal or procedural view of a behavior

To define a process as a procedure is to express its internal design as a sequence of steps governed by control logic.

However, a procedure may divide into several parallel paths (which may maintain several parallel state variables).

And higher-level processes tend to feature many parallel actions.


In EA, for this and other reasons, people tend to define the procedures of:

·       higher level processes less formally (say, in a value stream diagram)

·       lower processes more formally (say, in a flow chart).


Realisation of required behaviors by designed behaviors

One required process may be realised by differently designed procedures.

Moreover, one procedure can be realised in different ways:

·       by a single actor

·       by "orchestration" of actors by a higher entity

·       by "choreography" of several actors who inter-communicate.


Whenever actions performed by actors are coordinated sequentially (whether by orchestration or choreography) then there is a higher-level process.

How you document that higher-level process (as a whole, or piecemeal) is a different matter.

Conclusions and remarks

EA frameworks give us various ways to describe/model business activity systems.

Architects usually describe systems at a higher level of granularity than designers and builders.

The “right” level of granularity is a matter of considerable debate.

But the essential nature of the systems is the same at all levels.

At every level, a system can be defined from both structural and behavioural viewpoints.


The vision of EA is sometimes expressed as “the enterprise as a system of systems”.

In a business, fragmented system development tends to create silo systems that do not interact with other systems.

EA was and is a reaction against the difficulties caused by silo systems not interacting as they should do.

The four main difficulties are duplications, disintegrities, delays and difficulties with cross-organisational data analysis.

However, the vision can never be fully realised, partly because EA is so difficult politically and technically.

And also, because it inhibits the more agile system development an enterprise also needs to respond to changing conditions.


Perhaps, more modestly, the vision of EA is “the enterprise as an ecology of systems”.

Allowing that there may always be some duplications, disintegrities, delays and difficulties with cross-organisational data analysis.




All free-to-read materials at are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to in whichever social media you use.