Enterprises as systems - or rather, containers of systems

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 12/05/2019 12:00


The role of enterprise architects is to observe baseline systems, envisage target systems, and describe both.

General system theory helps us to make sense of what enterprise architecture is about.

It gives us insights into other disciplines and theories of information and communication.

It leads towards answers to philosophical questions about description and reality.


Formalisation of messages and memories. 1

Change management 1

Holistic optimisation. 1

System description. 2



Formalisation of messages and memories

Enterprise architecture is about:

·         Open (rather than closed) systems, which deliver services to consumers.

·         Designed (rather than natural) systems, which need analysis and design effort.

·         Purposeful (rather than accidental) systems, which have measurable objectives.

·         Information (rather than material) processing systems, which formalise messages and memories.


Enterprises are social entities in which actors exchange information.

Business activity systems can be seen as formalised social systems.

The actors perform activities according to messages received and memories retained.

The contents of memories and messages are defined as data structures composed of business data types.

Change management

A meta system is one that observes, envisages or describes the roles and rules of another system.

An enterprise architecture function is a meta system for changing an enterprise's business systems – under change control.

The social impacts of changes are usually addressed in parallel, by a business change team.

Holistic optimisation

Some say "enterprise architecture regards the enterprise as a system, or a system of systems."

What does that mean? And is it true?


People do often point to an institution (such as a church or cooperation) and call it a "system".

They might mean merely "it contains things that are interrelated in some way or another" (which may be said of the entire universe).

Or they might mean, a tad more specifically, "it is a social entity in which people receive directions from above and communicate with each other."


An enterprise architecture function takes a holistic view of business activities that create and use business data.

Architects take a cross-organisational and strategic view of the enterprise’s business systems.

They strive to standardise and integrate discrete business systems.


However, seeing the whole enterprise as one system is a vision rather than a reality.

Partly because different functions/capabilities have their own domain-specific languages.

And partly because large businesses suffer the diseconomies of scale.


Generally, an enterprise is as many different activity systems as you are able to describe and test

Calling an enterprise a system without reference to a particular system description means next to nothing.

Not only can an enterprise be conceptualised as countless different systems.

But also, those systems may be nested, overlapping, disparate, cooperative or antagonistic.


E.g. IBM is a corporation that employs many actors who interact in many activities.

There are infinite ways to divide IBM into systems.

Every system description is a highly selective partial description of IBM.

There are countless disparate activity systems (research, production, sales, accounting, corporate reporting).

Systems in different regions or divisions may duplicate, conflict or compete with each other.

Its countless disparate actors and activities cannot be joined up in one holistic description, and tested as a coherent whole.


IBM may be seen as the same entity today that it was last year – as is made evident in its name and in legal documents.

But IBM is surely not the same system today.

Simply pointing to IBM and calling it a system has no useful meaning.

Because IBM can be represented in countless system descriptions, depending on the perspective you take of it.

You can only say "IBM is a system" with reference to a particular system description, against which the behavior of IBM can be tested.

System description

Architects identify, design, plan and govern changes to business activity systems - under change control.

They describe a system in a way that can be used to test an operational system, and analyse the impact of changes.

They describe a system from several viewpoints.


External views help us scope or bound the structures and behaviors of interest to stakeholders.

E.g. An interface (aka boundary, service portfolio in TOGAF) encapsulates one or more internal active structures (building blocks in TOGAF).

A service (as may be defined in a discrete service contract) encapsulates one or more internal behaviors.


Structure views help us understand and describe how things in the system relate or connect to each other.

Behavior views help us understand and describe how things in the system act and change over time.

E.g. Structure/behavior contrasts include: actor/activity, entity/event, object/operation, stock/flow, function/process, and capability/value stream.


Logical views help us abstract essential facts from more physical descriptions, and from the concrete reality of an active system.

Note that external views may be seen as logical views.

Physical views help us translate between logical views and the concrete reality of an active system.

Note that some elaborate the logical/physical distinction into four levels (conceptual/logical/physical/real) or even six levels (as in the Zachman framework


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


Note that while people do sometimes name instances of physical active structures, they rarely identify instances of physical behaviors in the run-time system.

Footnotes on system structure and behavior

This table distinguishes structures in space from behaviors over time.


Structure: passive structures and actors in space

Behavior: atomic actions and processes over time

In natural language

In natural language

Structures are shaped or directed by behaviors.

Entities are created, changed and destroyed by Events.

Stocks are incremented and decremented by Flows.

Components perform Processes and deliver Services.

Behaviors are performed by active structures.

Events create, change and destroy Entities.

Flows increment and decrement Stocks.

Processes are performed and Services are delivered by Components.

In the Unified Modelling Language (UML) standard

In the Unified Modelling Language (UML) standard

A structural entity may be an active actor (with a thread of control) or a passive object.

Actors respond to messages generated by actors performing communication actions.

All behavior is triggered by and composed of actions performed by actors.

An actor instantiates an entity type/role by performing the behaviors of that type/role.

An action is the atomic unit in the specification of behavior.

An action converts a set of inputs and into a set of outputs.

Repeatable behaviors are often modelled as discrete event-driven processes.

The time between events can small enough to simulate continuous behaviors.


EA techniques are specific examples of general system theory concepts.

An entity-attribute-relationship model is uses to describe the passive structure of a business information system's information state.


EA treats a business as a system whose current state can be represented as a large and complex vector containing thousands of variables.

Of course, this vector is not only very large, but also distributed across scores or hundreds of business data stores.

And so, the architect has to study dis-integrity between databases, and consider where and how to reduce it.

EA strives to ensure the integrity of business system state data.

It looks to improve the consistency and quality of information available to people.

And make it accessible wherever it is needed (cf. the BoundaryLess Information Flow principle of The Open Group).


A business is stimulus-response system; it must respond to discrete events and service requests.

So, EA regards the enterprise as a discrete event-driven system in which the system’s state changes in discrete steps.

It also looks for way to analyse and exploit information that has been remembered in information state.


EA presumes processes can be “digitized” and described in flow charts.

Service-oriented specification of business processes is discussed in other papers.

Note that architects need service contracts to include measurable non-functional requirements.


The primacy of behavior is seen in many approaches to systems analysis and design.

They start with required services and end-to-end behaviors (aka value streams, business scenarios or business processes).


EA assumes the behavior of actors in a system is event-driven and shaped by business rules.

But this does not mean the overall behavior of the business is predictable.

There are several reasons why the behavior of a business may be, or appear, unpredictable.


·         Humans are ignorant of system rules or state

·         Rules involve fuzzy logic or probabilistic formula

·         External market forces

·         The “chaos” (in the mathematical sense) that results from multiple micro-level interactions


That “chaos” may not be revealed in system testing or pilot running.

This table mentions two system micro-level modelling approaches that might be used to simulate long-term outcomes.


Modelling approaches

Heterogeneous population

Homogeneous population

Micro-level modelling

System Dynamics

Agent-Based Modelling

Macro-level modelling

Enterprise Architecture (EA)





All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

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