System theory in EA frameworks

(One of many presentations in the System Theory for EA tutorial)

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 16/05/2017 20:00

Preface

The term “system” makes 1,357 appearances in the Open Group Architecture Framework (TOGAF 9.1), including:

“EA structures the business planning into an integrated framework that regards the enterprise as a system or system of systems”

Architecture’’has two meanings:

1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation.

2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time”

 

But what is meant by “system”?

Systems thinking runs from the sciences to the humanities: Maths > Physics > Chemistry > Biology > Psychology > Sociology > Politics.

There is spectrum from the most scientific of engineering to the most political of management consulting.

 

EA is about human and computer activity systems that process information.

·        System: a bounded collection of interdependent actors/components that form a coherent whole.

·        Activity system: a system in which actors/components cooperate in orderly processes.

·        Open system: an activity system that connects to its environment via inputs and outputs - often in feedback loops.

·        Human and computer activity system: an open activity system in which actors/components cooperate in orderly processes by exchanging and remembering information.

 

“Orderly” means constrained; bound by the rules of physics, chemistry or man.

“Information” means data that is meaningful to its creators and users.

 

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

EA favours defining business systems in a manner closer to the science/engineering end of the spectrum.

Thus, EA can be seen as applying the core ideas of general system theory (GST).

It describes systems in a way more compatible with GST than with sociological systems thinking (SST).

However, contrarily, the practice of EA itself is often towards political end of management consulting.

Core General System Theory (GST) ideas

Here is a respectable definition of GST, as introduced by von Bertalanffy.

 

von Bertalanffy…emphasized that real systems are open to, and interact with, their environments, can acquire qualitatively new properties through emergence, resulting in continual evolution.

Rather than reducing an entity to the properties of its parts or elements (e.g. organs or cells) systems theory focuses on the arrangement of and relations between the parts which connect them into a whole.

This determines a system, which is independent of the concrete substance of the elements (e.g. cells, transistors, people, etc).

System concepts include: system-environment boundary, input, output, process, state, hierarchy, goal-directedness, and information.” Principia Cybernetica

 

This paper discusses the application of core GST ideas identified in the definition above:

·        Encapsulation (system-environment boundary) and Goal-directedness

·        Outputs, Inputs, State and Processes

·        Information, Holism and Hierarchy

·        Abstraction of system description from concrete operational system

·        Change

·        Emergence.

Encapsulation (system-environment boundary) and goal-directedness

The classic GST method is to start by defining:

1.      External entities served by the system

2.      Goals/outcomes those entities desire

 

EA defines the system-environment boundary as an interface via which a business offers discrete services to external entities (aka customers).

(It further defines each subsystem or component of a system in a similar way.)

The goals of system customers and sponsors are given top priority.

(The goals of actors employed to play roles in the system are another matter, and are often addressed by a business change team in parallel with EA.)

Outputs, inputs, state and processes

The classic GST method proceeds as below to define:

1.      External entities served by the system

2.      Goals/outcomes those entities desire

3.      Outputs (products, services, responses) to meet goals and produce outcomes

4.      Internal structure/state to produce outputs

5.      Inputs to maintain structure/state and produce outputs

6.      Processes to apply inputs and produce outputs

 

EA frameworks include artifacts for defining system outputs, inputs, state and processes.

Notably: service contracts, data models and process models.

Information

All business systems consume and produce goods and services.

And they all depend on human and computer activity systems that consume and produce information

Increasingly, that information is digitised, along with business rules applied to that information.

 

EA is about the human and computer activity systems that require or produce information.

Often, where the integration of distributed and decoupled systems is a significant architectural challenge.

 

Zachman’s view of business systems

"To keep the business from disintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity.

EA provides the blueprint, or architecture, for the organization's information infrastructure.” John Zachman.

 

TOGAF’s “Boundaryless Information Flow”.

The vision declared in The Open Group’s mission statement says, in effect: “any data should be available any time, any where, to authorised actors”.

This vision implies standardisation and integration of distributed state data

Holism (and systemic coherence)

Regarding the Enterprise-as-a-System means a business can be described as:

·        a collection of actors/components that

·        cooperate in business processes to

·        maintain the state of the enterprise,

·        transform inputs into outputs, and so

·        produce outcomes and meet the goals of system customers and sponsors.

 

Taking a holistic view of the enterprise-as-a-system can mean both:

·        Encapsulation: starting from system-environment boundary.

·        Holism: connecting components in processes to deliver services.

 

EA was originally conceived to address the difficulty that enterprises suffer from systemic incoherence.

Therefore. EA strives for systemic coherence, which means:

·        System integration and standardisation

·        Integrity: consistency, single version of the truth

·        Coordination: sharing of information

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

 

In other words, EA strives to turn the enterprise into one coherent system.

 

The MIT operating model (in “EA as Strategy”) views an enterprise as a single organisation.

It presents cross-organisational standardisation and integration of business processes are essential ideas in EA.

That integration requires sharing of information.

 

An EA vision in short:

·        Enterprise-as-a-System

·        TOGAF: “EA regards the enterprise as a system or system of systems.”

·        MIT: Business standardisation and Integration

·        Wider sharing and use of information

·        Better data quality

·        More agile Business & IT systems

Hierarchy

The classic GST method proceeds to define as below:

1.      External entities served by the system

2.      Goals/outcomes those entities desire

3.      Outputs (products, services, responses) to meet goals and produce outcomes

4.      Internal structure/state to produce outputs

5.      Inputs to maintain structure/state and produce outputs

6.      Processes to apply inputs and produce outputs

7.      Actors/Components to perform processes.

 

Hierarchies are used in both system description and system operation to organise and manage atomic

·        Actors/components

·        Activities/processes

·        Facts (information items in data flows and stores)

 

Various kinds of hierarchy are used, including

·        Composition/decomposition hierarchies

·        Client-server hierarchies

 

However EA does also organise things in chains and network structures.

(And blockchain technologies provide an extremely decentralised way of organising a peer-to-peer network.)

 

What “organisation” means to a general systems theorist

Think of a biological entity or machine.

Think of the rules by which components cooperate in processes to maintain the state of the system and transform inputs into outputs.

 

What “organisation” means to a systems thinker

Think of a human society.

“Organizational theory: the study of organizations for the benefit of identifying common themes

for the purpose of solving problems, maximizing efficiency and productivity, and meeting the needs of stakeholders …

complements the studies of organizational behavior and human resource studies.”  Wikipedia

 

How far can a human “organisation” be seen as a “system”?

There are harder organisations: the organisation chart is a strict command and control structure; business processes, roles and procedures are well defined.

And softer organisations: people circumvent the organisation in undocumented ways; rules are few and/or may be broken.

And informal groups in which very little is organised or designed:

·        the boundary of the “whole” is unclear;

·        the processes are vague or ad hoc.

·        there may be a thin constitutional description

·        a minimal declaration of aims, roles and rules

·        even the group’s raison d’etre is subjective and open to change.

 

All architecture descriptions are soft systems

The term “soft system” is used in two ways, to mean

·        the operational system involves human components, or

·        a subjective description of a “real machine”.

 

The latter is the presumption in EA.

Every system description describes a perception of an entity as a system; it is subjective, partial and flawed.

Architects collect and make “soft system” descriptions and use them in stakeholder management.

 

System builders need a coherent system description; and system testers need objective test criteria.

So architects collate and reconcile soft systems to form a definitive architecture definition document (ADD) that can be agreed

But even the signed-off ADD remains a partial and flawed abstraction from the operational system, and might be called a soft system.

 

Earlier, we generalised this as a position called Scientific Idealism.

Scientific Idealism

Abstract Descriptions

<create and use>               <idealise>

Architects     <observe and envisage>    Concrete Realities

 

Our even more general position is that animals have evolved to remember and share descriptions of realities.

We create and use descriptions (mental, linguistic and other models) as a means to understand and deal with particular realities.

Our models need only be accurate enough to predict real world behaviour in a way that helps us.

Abstraction of system description from concrete operational system

Abstraction is probably the single hardest concept in system theory to grapple with.

Consider for example this example of abstraction/

Language

Dictionaries and grammars that describe sentences

Sentences that describe the world

The world (observable physical matter and energy)

 

The Eternal Golden Braid (EGB) is a classic abstract model of abstraction.

Eternal Golden Braid

Descriptions of description

Descriptions

Particular things in reality

 

Extending the Eternal Golden Braid

EA is about business processes that create and use business data

It is about business operations that depend on information systems, which are already an abstraction from real-world actors.

Eternal Golden Braid + 1

Descriptions of abstract description

Abstract descriptions of an operational system

Operational model of real system (information system)

Operational real system

 

The extended EGB – with recursive description

EA frameworks encourage maintaining successively more abstract system descriptions (typically physical > logical > conceptual).

Eternal Golden Braid + 1 + 3

Descriptions of abstract description

Abstract descriptions of an operational system

·        Conceptual model

·        Logical models

·        Physical models

Operational model of real system (information system)

Operational real system

 

However, people interpret conceptual/logical/physical distinctions differently.

 

The Open Group Architecture Framework (TOGAF)

This presumes system descriptions (aka soft system) abstract from concrete operational systems.

It isn’t entirely clear whether “deployed solutions” are operational systems or descriptions of them (as in a CMDB).

TOGAF

TOGAF (a generic EA framework)

Architecture Definition (one specific EA)

·        Requirements and context

·        Architecture continuum / building blocks

·        Solution continuum / building blocks

Deployed Solutions

Live (run-time) systems

 

TOGAF is a meta system to business systems.

It is a management framework for producing abstract system descriptions with a view to changing concrete operational systems

 

Architecture description frameworks

EA frameworks encourage architects to idealise from operational objects to types

Then abstract from detailed types to sparser types.

They present 2-dimensional classification schemes for architecture descriptions, such as the one below.

These are nothing more or less than pigeon holes for descriptive artefacts.

Some other dimension

Idealisation

Conceptual model

Logical model

Physical model

Real

 

E.g. Zachman proposes 5 levels of idealisation

Question

Idealisation

What

How

Where

Who

When

Why

Identification

Definition

Representation

Specification

Configuration

Instantiation

 

E.g. Cap Gemini’s IAF propose 4 levels of idealisation

Domain

Idealisation

Business

Data

Information

Systems

Technology

Infrastructure

Context

Conceptual

Logical

Physical

 

E.g. TOGAF proposes 3 levels of idealisation

TOGAF’s enterprise continuum features 3 levels of idealisation from deployed solutions (assuming those are operational systems, rather than descriptions of them).

And 3 degrees of generalisation from organisation-specific.

Generalisation

Idealisation

Foundation

(Universal)

Common Systems

(Fairly generic)

Industry

(Fairly specific)

Organisation

(Uniquely configured)

Requirements and Context

Architecture Continuum

(Logical Models)

Solution Continuum

(Physical Models)

Deployed solutions

Change

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

EA is a meta system to orderly business systems.

Architects define system version changes rather than system state changes.

 

The business systems are not what some systems thinkers like to call “complex adaptive systems”

Architects do not define “systems” in which actors can change the aims, roles and rules of the “system” without change control, because they cannot be described as “systems”

However, EA can define meta systems to such systems.

And actors can swap between roles in a business system and in the meta system that is EA itself.

Emergence

This is a self-evident phenomenon in enterprise architecture.

Emergent properties are the very purpose of system design

If any part of the system could display the properties of the whole, we wouldn’t need to design or build the rest of the system.

Conclusion

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

EA favours defining business systems in a manner closer to the science/engineering end of the spectrum.

Thus, EA can be seen as applying the core ideas of general system theory (GST).

It describes systems in a way more compatible with GST than with sociological systems thinking (SST).

However, contrarily, the practice of EA itself is often towards political end of management consulting.

 

 

All free-to-read materials on the 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.