“The most important work on EA and applied System Theory today.” 

“Makes EA more powerful, coherent and usable.”


Enterprise and solution architects are supposed to observe baseline systems, envisage target systems, and describe both.

So, you might assume they are taught about system theory and systems thinking; but this is far from the case.

System theory is good to know, good for the soul, and practically useful in all kinds of thinking about systems.


Millions of years ago, animals evolved to conceptualise the world in their brains.

To remember information, they encoded it in their memory structures; to recall information, they decoded those memories.

Later, animals evolved to communicate concepts to each other.

To exchange information, a sender encodes it in a message, and a receiver decodes it from that message.

In a social system, senders and receivers must share the same code for encoding and decoding messages.


Business systems evolved out of social systems.

To conduct business, people formalised what had been fuzzy memories and messages.

When a business system is formally described, it can be changed under change control from one generation to the next.


Today, the human activities in business systems are supported and enabled by software systems.

System architects observe, envisage and describe changes to the business systems of an enterprise.

They work in the meta system that is often called enterprise architecture.


In the 1970s, business systems were often analysed and designed by people in an Operational Research department.

At the start of the Information Age, many Operational Research departments were absorbed into IT departments.

The PRISM report of 1986 divided the work of business system description into four domains.

The table below positions those four domains in the columns; each divided into three levels.

It positions descriptions of human activity systems to the left, and computer activity systems to the right.

The two kinds of system meet wherever digital data is created and used by humans.







Infrastructure technology



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(s) 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

IT production environment


In 2011, a “systems thinker” asked me what theory underpins enterprise architecture.

I was surprised he didn’t know that general system theory underpins enterprise architecture.

And later, surprised to find how loosely the term "system" is used today in much systems thinking discussion.

So, the work introduced here sets out to provide a stronger theoretical foundation for enterprise architecture.


If every problem or situation is a system, if everything we name or point to is a system, then the term “system” is meaningless.

This work explores what means to call something a system.

Also, how "general system theory" and "systems thinking" can differ, and even can be contrary to each other.

Certainly, seeing a business as a social network is important to effective business managements.

But to call a social entity a "system” means more than that


Various puzzles are addressed and resolved in this work.

Much is owed to the biologist Charles Darwin and W Ross Ashby.

The work relates system theory to biology, psychology, sociology and the philosophy of science.

Moreover, they may provide food for thought for philosophers about the description/reality distinction.