“The most important work on EA and applied System Theory today.” “Makes EA more powerful, coherent and usable.”
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.
The role of enterprise architects is to observe baseline systems, envisage target systems, and describe both.
So, you might assume it is universally agreed what a "system" is; but this is far from the case.
The work introduced here sets out to provide a stronger theoretical foundation for enterprise architecture (EA).
It turns out that, to provide that foundation, we have to explore wider questions and theories:
· what it means to call something (a hurricane, a human being, a society, a business, a radio) a system
· why "general system theory" and "systems thinking" differ, and can be contrary to each other
In 2011, in a meeting of “systems thinkers”, one asked me what theory underpins enterprise architecture.
He said he couldn’t find any theory, other than the Zachman Framework (which we agreed was not a satisfactory answer).
I was surprised he didn’t know that general system theory underpins enterprise architecture.
But then, there is no time in professional training courses to explain this.
A general system theory should be applicable to systems in every field, from the harder sciences to the humanities.
That is, from maths, physics, chemistry and biology and psychology to economics, politics and sociology.
In the 1950s, von Bertalanffy, Ashby and others looked for patterns and principles common to systems across all sciences.
Ashby’s ideas are applied in all modern enterprise and business architecture methods and modelling languages.
The aim here is to explain the general system theory that underpins enterprise architecture.
The explanation owes much to the works of W Ross Ashby.
And moreover, to explain what underpins general system theory.
That explanation owes much to the works of Charles Darwin.
Setting off to explain that led me on journey down several other paths.
Later papers analyse the notions of system theory with reference to:
· theories of description, types, communication and information
· philosophical questions about description and reality - how they differ and relate.
The analysis leads towards a coherent and consistent understanding of these matters.
The findings and conclusions can help both authors and users of enterprise architecture standards.
They can help readers detect and resolve ambiguities and contradictions in "systems thinking".
They could help scientists in different disciplines to use the term "system" more consistently.
Moreover, they may provide food for thought for philosophers about the description/reality distinction.
Social systems thinking started earlier than general system theory, in the 19th century.
When general system theory arrived, social system thinkers sought to embrace it.
Later however, some threw off its constraints and set off in a different direction
These papers explore the result, which is a schismatic distinction between:
· a social system – in which actors realise describable roles and rules
· a social entity – in which actors choose their own behaviors.
Certainly, seeing a business as a social entity is important; and is a primary responsibility of business managers.
The question here is whether classifying such an approach as "systems thinking” has a useful meaning.
If every problem or situation is a system, if every entity we name or point to is a system, then the term “system” is meaningless.
Enterprise architecture is about business system planning, and is underpinned by general system theory.
System theory is good to know, good for the soul, and practically useful in all kinds of thinking about systems
Many could benefit from a deeper understanding of it, and respecting it more than they do.
This work can be seen as homage to Ashby and his approach to system theory.
An aim here is to explain Ashby’s ideas and more, and before that, to explain what underpins them.
The journey starts with an exploration of description, communication, language, logic and truth.
Various puzzles are addressed and resolved consistently in the book.
They key is to look at each puzzle as Charles Darwin and Ross Ashby would surely have done.
The book relates system theory to biology, psychology and the philosophy of science.
And ends up showing how system theory is applied in enterprise architecture methods.
The relationship of description to reality is curious, and has been debated by philosophers for thousands of years.
Countless philosophers have proposed countless philosophies – both overlapping and contrary.
Descriptions (private & public)
<create and use> <idealise>
Describers <observe & envisage> Realities
My university degree course included biology, psychology and the history and philosophy of science.
Ideas taught to me then included:
· Biology: a living entity is sensitive to changes in the state of its environment, and responds to them.
· Psychology: a brain holds a model of things in its external environment.
· Science: scientific knowledge evolves by describing how the world works, then testing that it does.
· General system theory: “systems” have things in common: e.g. are connected to their external environment by input and output flows.
These ideas have appeared and reappeared throughout my career since then.
Before starting work as a computer programmer, I was taught program design (a luxury known to few programmers nowadays).
Michael A Jackson taught me that a software system holds a model of entities and events that it monitors and directs in its environment.
This work relates that idea to related ideas in biology, psychology, science and philosophy.
My career has been centered on business systems that are supported and enabled by information technologies.
Abstract away from the technologies, and you can see these business systems as formalised social systems.
To cooperate in business processes, system actors must exchange information.
They send information in messages, store it in shared memory spaces, and extract information from them
To succeed in exchanging information, actors must agree the meanings that are encoded in those messages and memory spaces
Today, I teach enterprise and solution architects how to describe and plan changes to business systems.
Their job is to design and plan generational changes to systems, under change control.
First, they describe systems in terms of active structures (actors/components), behaviors (activities/processes) and passive structures (notably data structures).
Once systems are described, they can be governed and changed under change control from one generation to the next.
Training course topics include interface definition, service-orientation, modelling languages and techniques, design patterns, and methods like TOGAF.