EA as an application of general system theory

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 27/05/2019 15:24


This paper is one of four that parallel each other.

·         Introducing general system theory ideas

·         Complexity

·         EA as an application of general system theory

·         TOGAF as an application of general system theory


This paper shows how system theory ideas help us to understand what Enterprise Architecture (EA) is and is not - what it can and cannot do.

If you want longer discussion of the same system theory ideas then read the first paper instead.


The generality of system ideas. 2

Passive and activity systems. 3

Open and closed systems. 4

System as a black box. 4

Abstract and concrete systems. 5

Abstraction of systems from networks. 7

Coupling between systems. 7

Emergence (not found in individual components). 7

Holistic view of how components interact. 8

Hierarchy, and systems of systems. 8

Atomicity or “non-reducability”. 8

Dynamics (state change). 9

Dynamics (processes). 9

Determinism (state/history-dependent processing). 10

Chaos. 11

System archetypes, design patterns. 11

Unpredictability. 11

Adaptation (state change). 12

Adaptation (system mutation). 12

Self-organisation.. 13

Information.. 13

Goal seeking. 15

Complexity. 15

Conclusions and remarks. 15


The generality of system ideas

The general concept of a system became a focus of attention after second world war.

“There exist models, principles, and laws that apply to generalized systems or their subclasses, irrespective of their particular kind, the nature of their component elements.” Bertalanffy

This and some quotes below are from “General System theory: Foundations, Development, Applications” (1968), Ludwig von Bertalanffy.


General system theory incorporates cybernetics, a movement that also grew in the 1950s.

Systems concepts include: system-environment boundary, input, output, process, state, hierarchy, goal-directedness, and information."

This and some other quotes below are from Principia Cybernetica Web.


Business systems evolved over millennia by formalising the roles and rules, messages and memories, of social systems.

This table compares core concepts in one business system design method with core concepts in General System Theory.


Concepts in General System Theory

Core concepts in TOGAF’s meta model

A bounded structure of

A bounded organisation of

actors/organs that interact by playing

building blocks/components that interact by playing

roles in

roles in

behaviors to meet

processes to meet

goals, by maintaining the system’s

goals/objectives by maintaining the system’s

state and exchanging

data/information entities and providing

inputs/outputs with each other and with

input/output services to each other and to

entities outside the boundary, using

entities playing roles, using

system resources.

platform technology components.


Relevance to EA

Many general system theory concepts are taken for granted in today’s enterprise and software architecture methods.

This table defines some general system ideas found in enterprise and business architecture.


General system ideas

Business system ideas

Defined in terms of activities


Business goal

A testable target for the outcome(s) of business activities.


Business service

A contract defining the request for and result/outcomes of required activities.


A behavior that sequences activities.

Abstract structure


A group of services offered and/or activities performable by an actor.

Business function

A group of services offered and/or activities performable by an organisation.

Concrete structure


A person (or machine) who realises a role by performing activities in processes.


A managed unit that realises a function’s services by performing activities in processes.


The “Information Age” began when humans started using software to digitise the messages and memories of business systems.

Software architecture modularises an application (system) into components (subsystems).

Compare the tables above and below.


General system ideas

Software system ideas


Application requirement

A testable target for the outcome(s) of application activities.

Behavior (use case)

Application service

A contract defining the request for and result/outcomes of required activities.

Application process

A behavior that sequences activities.

Abstract structure

Application interface

A group of services offered and performable by an application component.

Concrete structure

Application component

A deployable unit that realises an interface’s services by performing activities in processes.

Passive and activity systems

Passive structure: a collection of inter-related things or parts, which can be acted on, but does not act.

E.g. a database, a table, a garden fence, a telephone directory, a necklace, and the Dewey decimal system.


System: an activity system, rather than a passive structure.

It is an island of orderly behaviors in the ever-unfolding process that is the universe.

The behaviors maintain or advance the system state and/or produce outputs.

E.g. the solar system, an organism, a software system, a choir, a tennis match.


Relevance to EA?

EA is concerned with the human and computer activity systems of a business.

These business systems have evolved over millennia by formalising social activity systems.

They feature business roles and processes that create and use information in the form of messages and memories.

The messages and memories contain passive data structures.

The actors play their roles by performing activities when triggered to do so by messages received and memories retained.

Open and closed systems

“Closed and Open Systems: Every living organism is essentially an open system. It maintains itself in a continuous inflow and outflow…” Bertalanffy.

A closed system is one modelled without reference to its wider environment.

An open system is one modelled as consuming inputs from its environment.

System as a black box

System environment: the world outside the system of interest.

The environment of one system may be a wider system.

The environment of a business system is sometimes called its market.


System boundary: a line (physical or logical) that separates a system from is environment

It encapsulates the system’s internal structures and behaviorsencloses them in input-process-output “black box”.

If you expand the system boundary then external events become internal events, passing between subsystems.

If you contract the system boundary then internal events become external events, crossing that boundary.


System interface: a description of inputs and output that cross the system boundary.

An interface defines the system as it is seen by external observers.

An interface may be defined in a contract defining services provided or required.

In social and software systems, the primary inputs and outputs are information flows.


Relevance to EA?

EA is concerned with business systems that are open - they consume input and produce outputs.

And with systems definable as a “black box”.

The encapsulation and specification of systems by their interfaces is a fundamental tool.

Bear in mind that the inputs and outputs to be described depend on the concerns of interest.


Inputs to IBM

Outputs from IBM



Electricity and food


Money from customers and investors

Salaries and dividends

Raw materials and components

Concrete products

Questions and requests

Answers and documents

Raw information

Integrated or advanced information


EA is concerned with how business systems relate to customers and suppliers in its environment.

A business maintains itself in a continuous inflow from suppliers and outflow to customers.

EA sees a business system as a bounded input-process-output mechanism.

·         It receives messages about the state or needs of entities in its environment

·         It processes information in the light of the current state of the business and/or environment.

·         It sends messages to help external entities produce desired effects or outcomes.


SIPOC is an acronym that captures ideas used in business analysis, design, process and quality improvement.

The conventional business system design process defines the system-environment boundary thus:

1 Customers - entities in the environment that need outputs to meet their goals

2 Outputs – products and services customers need from the system

3 Inputs – the system needs to produce the outputs

4 Suppliers - entities in the environment that will supply the inputs

5 Processes - to produce the outputs from the inputs.


To which one might add:

6 Roles - actors play in process steps

7 Actors – hired or made to play the roles

8 Organisation – deployment, motivation and management of actors to perform the processes.


An EA function tends to focuses on steps 1 to 6

Some social systems thinkers speak more to the business management concerns in steps 7 and 8.

Of course, the system design steps are entangled and iterative in practice.

And the actors may have a say in what the EA function focuses on.

Abstract and concrete systems

Abstract system: a description or model of a concrete system (also called a soft system).

Concrete system: a system that runs in reality; a real world entity that can be tested as meeting an abstract system description – well enough..


Abstract systems are realised by concrete systems; concrete systems realise abstract systems.


Abstract  system


A set of roles and rules (the logic or laws actors follow)

The stickleback mating ritual

Concrete  system


Actors playing the roles and acting according to the rules

Countless pairs of stickleback.


Relevance to EA?

To exercise change control over changes to systems, there must be description of those systems.

EA abstracts system descriptions from baseline systems (observed) and target systems (envisaged).

An “architecture definition” is collection of descriptive artefacts, often including graphical models in which diagrammatic symbols substitute for words.

The definition is detailed only in so far as stakeholders need it to be.


EA is concerned with the many abstract systems realised by a business.

You might hear it said that enterprise (say IBM) is a system.

However, IBM can realise many abstract system descriptions, in parallel, some of which are disconnected or in conflict.

So to say IBM is a system is meaningless unless you point to your chosen abstract description.



System descriptions

<create and use>                       <realised by>

System describers <observe and envisage> The behaviors of IBM


This table classifies and relates some viewpoints used in system description at an EA level.


System viewpoint

Behavior (activities, events)

Activities in sequence from trigger to result.

Active structure (actors, entities)

Groups or performers of related activities.



A discrete transformation from input/request to output/result.

TOGAF Business service, IS service, Technology service


A collection of services made accessible to clients

TOGAF, Interface, Service portfolio



specification or type

Logical behavior

A specification of a behavior.

TOGAF Value stream, Business scenario, Process

Logical active structure

A group of activities that a real world entity can perform.

TOGAF Business function, Capability, Role, Logical (data, application, technology) component


realization or instance

Physical behavior (locatable in time)

A performance of a behavior

TOGAF (n/a)

Physical active structure (locatable in space)

A real world entity with the ability to perform activities.

TOGAF Organisation unit, Actor, Physical (data, application, technology) component

Abstraction of systems from networks

This section is an exception in that it discusses a distinction not drawn in the early development of general system theory and cybernetics.


Social networks and social systems are different things

General system theory and cybernetics can be applied to the roles and rules of a social system.

Note however that a social network (a collection of communicating actors) is a different concept.

One social network can realise several distinct social systems.

And one social system can be realised by several social networks.


Relevance to EA?

EA is concerned with business systems that employ human actors.

EA works alongside others concerned with management and motivation those actors.

Coupling between systems

Coupling is the relating of systems (as subsystems) in a wider system.

The actors in a system can interact by forces, energy, matter or information, the last of which is the main interest here.


Relevance to EA?

EA is concerned with business systems that create and use information.

And concern to integrate those systems to the benefit of the enterprise.

Emergence (not found in individual components)

Emergence primarily means the appearance of effects (state changes or outputs) that arise from coupling subsystems in a wider system.

Even in the simplest system, its emergent properties are not deducible from the properties of its components.


Relevance to EA?

EA is concerned to couple subsystems to produce emergent properties to the benefit of the business.

Holistic view of how components interact

“General System Theory… is a general science of wholeness… systems [are] not understandable by investigation of their respective parts in isolation.” Bertalanffy

Holism means looking at something in terms of how its parts join up (e.g. bicycle and rider) rather than dissecting each part.

Holistic view: a description of how parts relate, interact or cooperate in a whole.

Reductionist view: identifying the parts of a whole, naming or describing parts without considering how the parts are related in the whole.


Relevance to EA?

EA takes a holistic view; it looks to integrate business systems to the benefit of the wider enterprise.

It grew out of the need to reduce the cost and quality issues caused by “silo systems”.

Silo systems are not standardised, not integrated, and don't share common services.

“EA is concerned with “system implementations, extending in scope and complexity to encompass an entire enterprise.” (Zachman).


In other words, EA strives for systemic coherence, which implies:

·         System integration and standardisation

·         Integrity: data consistency, single version of the truth

·         Coordination: sharing of information

·         Rationalisation: parts should not duplicate, conflict or compete with each other.

Hierarchy, and systems of systems

System theory concepts include “hierarchy”.

With his background in biology, von Bertalanffy wrote of a concept he called organicism.

Organicism: the idea that systems are describable at multiple hierarchical levels.


A body <is composed from> organs <that interact in processes to sustain> the body.

An organ <is composed from> cells <that interact in processes to sustain> the organ.

A cell <is composed from> organelles <that interact in processes to sustain> the cell.


Relevance to EA

Hierarchical structures are used extensively to help people understand and manage complex estates of systems.

Atomicity or “non-reducability

Complexity is matter of perspective.

It depends on a) what your interest in a thing is and b) what you regard at the atomic components.

So, to compare the complexity of two systems, they must be described a) in the same style and b) at the same level of decomposition.


Atomic element: an element that is not further divided in a description.

System describers choose how far to subdivide a system of interest.


Relevance to EA?

EA is said to view the enterprise as a system, or system of systems.

This does indeed explain what EA strives for, though integration of all systems is impossible in practice.


EA frameworks define an enterprise as a recursively decomposed structure of business functions/capabilities.

They use this logical structure as their touchstone, rather than the organisation’s management structure, which is relatively volatile.


The atoms in a software system model are modules/classes and the procedures they can perform.

The atoms in an EA model can be a thousand or more times more coarse-grained, for example a whole application.

Dynamics (state change)

In cybernetics: “a system is any set of variables which he [the observer] selects” Ashby 1956.

A principle of system theory is that a system has a current state.

A system can be analyzed in terms of how its state variables change over time, often in response to inputs from outside the system.


System state: the current structure or variables of a system, which may change over time.

System state change: a change to the state of a system,


Relevance to EA?

EA is much concerned with the data that records the state of things in a business and its environment.

And with the business roles and processes that create and update that data.


(Hoare logic underpins all methods for analysis of requirements and definition of business processes.

It describes how performing a process changes the state of a system.

The Hoare triple may be expressed as: {Precondition} Process {Post condition}.

The meaning of the triple is: IF the precondition is true AND the process proceeds to completion THEN the post condition will be true.

The post condition is a requirement; a result, goal or outcome of value to the business.)

Dynamics (processes)

Behaviors are processes performed by parts, often called actors or agents, that play roles in a system.

Behaviors change the state of the system or something in its environment.

Event: a discrete input that triggers a process that changes a system’s state, depending on the current state.

Process: one or more state changes over time, or the logic that determines which state changes lead to which other state changes.


Relevance to EA?

The US government’s EA Framework declared its aims as: “common data and business processes”, “information sharing” and “new and improved processes”.

“An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999).


In the popular book “EA as Strategy”, Ross, Weill and Robertson said.

"Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (“EA as Strategy” 2006).


Ross etc. used the grid below to promote the idea of standardising and integrating business processes across the enterprise.


Core business processes

High integration



Low integration




Low standardisation

High standardisation


In short, the purpose of EA has always been to optimise, integrate, improve and extend business processes – which produce results or outputs of value to some interested parties.

EA defines these behaviors in the form of “value streams”, “business scenarios”, “business processes” and “service contracts”.

Determinism (state/history-dependent processing)

Deterministic means that a system, in a given state, responds to a given input or event in a pre-determined way (be it natural or designed).


Relevance to EA?

EA is concerned with business processes that are regular, determinate or repeatable (as Ashby said of cybernetics in 1956).

Determinate means the responses of a business (to events and service requests) are determined by business rules applied to system state or memory.

To monitor and direct the state of the entities and activities it cares about, a business runs in a feedback loop with its environment.

1.      It receives a message carrying new information about business entities and activities

2.      It refers to its memory, holding the last-recorded state of those entities and activities

3.      Depending on the state, it “chooses” whether to update its memory and/or send messages to direct external entities and processes.


EA frameworks include viewpoints (data models, state charts, interaction diagrams) for modelling event-driven systems.

True, enterprise architects produce only sketchy models, but the roles and rules must be further detailed before the systems can be implemented.


Chaotic generally means disorderly, random, with no regular or repeated pattern.


Relevance to EA?

EA is about orderly processes, not chaotic ones.

It is rarely concerned with the long-term trajectory of state changes to business state variables.

E.g. the value of a revenue-per-month variable might be stable, increase steadily or change chaotically.

System archetypes, design patterns

There are many patterns for the design of systems.

There are design patterns for how system interactions are organised or controlled

The table below identifies some contrasting design patterns.


Centralised organisation

Distributed organisation

in one place or component. 

between places or components.


Anarchy or Network

Hub and Spoke

Point-to-Point or Mesh



Fork or Orchestration

Chain or Choreography


Relevance to EA?

EA is concerned with choosing design patterns by trading off their pros and cons on the light of given requirements.


The next action or state of a simple system may be unpredictable because

·         its current state is unknown

·         its rules include a random or probabilistic choice between actions.

·         interactions between actors at a micro-level lead to unpredictable state change effects at the macro-level.


And in the simplest human social system, how an actor responds to information received is unpredictable.

Because humans, having free will, can choose their response – either within the bounds of a system, or contrary to the rules of that system.


Exceptions occur when actors do not complete actions expected of their roles.

This is common in human activity systems, and happens also in mechanical systems when their components fail.


Relevance to EA?

EA is concerned to address exceptions to the main, happy, or straight-thru path of a business process.

Especially in processes in which human actors play roles.

The need to design systems with exception handling is a common source of complexity.

Adaptation (state change)

“Systems concepts include: system-environment boundary, input, output, process, state….”   Principia Cybernetica


Adaptation is an ambiguous term, it can mean either system state change (as in homeostasis) or system mutation. Here, it means state change.


Relevance to EA?

EA is much about business roles and processes that create and maintain persistent state data.

It is much concerned with the data that records the state of things in a business and its environment.


Hoare logic underpins all methods for analysis of requirements and definition of business processes.

It describes how performing a process changes the state of a system.

The Hoare triple may be expressed as: {Precondition} Process {Post condition}.

The meaning of the triple is: IF the precondition is true AND the process proceeds to completion THEN the post condition will be true.

The post condition is a requirement; a result, goal or outcome of value to the business.

Adaptation (system mutation)

Like every other entity, a system has a discrete life time, which can be short or long

Evolution: inter-generational system mutation, changing the nature of a system.

Evolution can be organic (a virus) or designed (a software upgrade).


Relevance to EA?

EA is very much concerned with system mutations made under change control.

It designs, plans and governs the migration from baseline systems to target systems.

See the next section.


Some system theorists (notably Ashby and Maturana) have said the concept of a self-organising system makes no sense.

However, the term is widely used, and has been interpreted in an extraordinarily wide variety of ways.


·         the absence of a design or pattern

·         decentralised control

·         growth by accretion

·         flocking behavior

·         morphogenesis

·         business reorganisation


Read Foerster’s ideas on second order cybernetics more detailed discussion of self-organisation.


Meta system: a system that defines a system or changes it from one generation to the next.

In nature, the processes of sexual reproduction define a new organic system generation.

In design, people define the next generation of a machine or business system.


Relevance to EA?

EA does not focus on processes that actors are expected to define themselves, are ad hoc, or are performed without regard to business data.

It focuses on when, where and how regular business roles and processes create and use business data.

It is a meta system to the business systems that it observes and envisages.

It helps an enterprise to change those business systems in response to external and internal forces.

It is about the designing and planning the changes to business systems - from one generation to the next.


This table presents a version of the WKID hierarchy.



The ability to respond effectively to knowledge in a new situation.


Information that is accurate or true enough to be useful


Meaning created or found in a structure by an actor


A structure of matter/energy in which information has been created or found


Information: a meaning created or found by an actor in any physical form that acts as a signal; any description or direction that has been encoded in a signal or decoded from it by an actor.

Information flow (aka message): physically, a signal passed from sender to receiver, logically, a communication.

Information state (aka memory): see “state” above.


Relevance to EA?

Businesses processes have always depended on information.

To drive a bus, you need to know the route.

To deliver a parcel, you need the sender address and receiver address.

To write cheque you need the payment amount, and the identity of the recipient.


EA focuses primarily on business operations that create or use information.

"EA as Strategy” (2006) says the “foundation for execution” includes well-managed information systems.

Why? Because you can't integrate business processes without passing business data between roles and activities.

And you can't standardise business processes unless the actors in those processes are monitored and/or directed by information systems.


EA is concerned with inputs and outputs that are information, and with materials accompanied by information.

Many authors have put the quality and use of business information at the heart of EA.

“Architecture planning is the process… to improve data quality, access to data, adaptability…, data interoperability and sharing, and cost containment.” (Spewak, 1993 reference)

“The domain of information-intensive organisations…is the main focus of the [EA modelling] language” (ArchiMate standard v2.1)

"Today’s CEOs know that the effective management and exploitation of information… is a key factor to business success.” (TOGAF 9.1, 2009 reference)


EA is concerned with information/meaning encoded in memory and message data structures by human and computer actors.

The usual presumption is that other actors will find the same information/meaning in those data structures.

It can reasonably presumed that communication works when

·         data structures are preserved perfectly

·         translations of data structures from one form of language to another are perfect

·         senders and receivers apply the same language to writing and reading of messages and memories.


Communicating patterns

There are patterns for communication between message senders and receivers.


Communication pattern



Point to point

Sender knows the Receiver’s address and talks directly to Receiver

Look up

Passive directory

Sender looks up the address then finds and talks directly to Receiver

Direct broker

Active directory

Sender requests the address then finds and talks directly to Receiver


Indirect broker

Message broker

Sender requests a broker to convey a message to a named Receiver

Publish subscribe

Active mediator

Sender requests a publisher to convey a message to all interested Receivers

Shared data space

Passive mediator

Sender leaves a message in a structure accessible by all interested Receivers

Goal seeking

There are natural and designed (accidental and purposive) systems


Natural system: a system that runs before it is envisaged as a system.

It evolves without any intent; it repeats behaviors without any externally-defined drivers or goals.

E.g. a solar system, weather system or biological organism.

The solar system evolved so that the planets repeat stable orbits.

These outcomes are not goals, they are the unintended consequences of evolution.


Designed system: a system that is envisaged before it runs.

It is created by intent, with aims in mind - though its outcomes may diverge from its aims.

Its reproducible behaviors are defined in response to externally-defined drivers or goals.

E.g, a cuckoo clock, a motor car, an accounting system, a choir, a tennis match.


Relevance to EA?

EA is concerned with designing and changing systems to meet business goals.


Complex is a term with scores of different definitions.

Read Complexity for more detailed discussion of the topic.


Relevance to EA?

EA is concerned with software systems, arguably the most complex systems designed by mankind.

And with systems that involve roles played by human actors, who are arguably the most complex systems in nature.

Conclusions and remarks

To facilitate the transactions of government and commerce, EA formalises inter-actor communication and behavior.

Information in messages and memories standardised using data types.

The behavior of actors is standardised in roles and rules.


EA is about designing, planning and governing “transformational changes” to business systems.

Business systems are describable and testable using system theory ideas.

And when the system is put into production, it will be further tested throughout its run-time operation.


Design activities that reflect system theory

EA applies system theory concepts when, for example:

·         Abstracting a system description from a baseline system (observed) and a target system (envisaged).

·         Bounding systems (and subsystems or components) behind system-environment interfaces.

·         Defining goals for a system to be designed.

·         Defining system outputs or services that will meet or serve the goals.

·         Defining processes and roles needed to deliver required outputs or services.

·         Defining interfaces in terms of services required and provided.

·         Defining data (state variables maintained) created and used by business processes.


The primacy of behavior

In the operation of a business system, events trigger actors to play roles and perform behaviors.

All EA frameworks are based on two presumptions made explicit in the UML 2.1 standard

·          “all behavior in a modeled system is ultimately caused by actions executed by so-called “active objects

·         behavioral semantics only deal with event-driven, or discrete, behaviors”  UML 2.1



In the operation of a business system, external actors request services.

So, the starting point is to define those service requests – to encapsulate the internal actors and behaviors.

You start with the services or outputs you want from the system of interest.


Formalising a social system into a business system typically follows this sequence:

·         Define discrete events or service requests to be recognised and processed

·         Define the necessary behaviors, and group them into roles

·         Hire, buy or build actors (active stuctures) and deploy them to act in the defined roles.


Design sequences that reflect system theory

Four design sequences can be found in architecture frameworks:

·         Logical to physical: Abstract specification before concrete implementation

·         External to internal: required services/products before internal processes and roles/actors/components

·         Behavior to structure: services and process sequences before roles/actors/components.

·         Business to technology: human actors before computer actors.


There are reasons to deviate from these sequences in practice, and to “reverse engineer”

But methods for governing design and implementation against a specification usually start with these presumptions.


System reengineering

A general process for rationalisation of a messy system estate runs as follows:


Analyse the baseline

1.      Catalogue baseline actor/components (organisation units, functions, roles or actors).

2.      Abstract the discrete services provided by those baseline actor/components.

3.      De-duplicate baseline-provided services.


Design the target

1.      Define required services

2.      If need be, design processes to deliver the required services.

3.      Assign required services and/or process steps to logical interfaces, functions or roles.

4.      Change, hire, buy or build physical actor/components to realise logical interfaces and perform processes.


In all the ways discussed, EA can be seen as applying the core ideas of general system theory to business systems.

It describes systems in a way more compatible with general system theory than with social systems thinking.

Contrarily, as a meta system, EA is often towards political end of management consulting.


All free-to-read materials at http://avancier.website 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 avancier.website in whichever social media you use.