EA, GST and Social System Thinking

Copyright 2017 Graham Berrisford.

One of about 300 papers at http://avancier.website. Last updated 24/05/2017 13:09

 

Some believe “systems thinking” approaches are a progression from, or advanced application of, general (cross-science) system theory.

The reality is that systems thinking approaches tend to depart from general system theory in one or more of the ways below.

 

General system theory (GST)

Social system thinking (SST) tends to be

Scientific

Scientistic

General

Specific to situations in which humans interact

About system roles and rules

About individual actors (especially people)

About systems

About meta systems

About describing testable systems

About solving a problem or changing a situation

 

This paper explores the last two differences.

Enterprise Architecture and GST

TOGAF says “An architecture defines a system” and “Enterprise architecture regards as the enterprise as a system...”

What does it mean by “system”?

Enterprise architecture started when GST and cybernetics were more widely recognised than they are today.

A touchstone for enterprise architects is GST.

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

 

How EA frameworks apply GST

To apply GST is describe a system abstractly, then test a real system against the abstract description.

This approach is applied all over the world every day in the design of government, business, human and computer activity systems.

TOGAF applies GST to Enterprise Architecture (EA).

 

In TOGAF phases A to D, architects observe a baseline system and envisage a target system

Architects form an abstract description (e.g. architecture definition) of system roles and rules.

 

In phases E and F, architects and others plan system changes.

 

In phase G, architects govern projects delivering the new system.

The system’s actors/components are bought, hired or built.

The system’s operation is tested against the system description.

If there is a discrepancy, the system or the description is changed.

 

In phase H, architects govern change, and maintain system descriptions in line with system change.

System change requests are tested against the system description.

If there is a discrepancy, the system or the description is changed.

 

How EA frameworks document system concepts

“The method proposed by systems theory is to model… multiple interacting components by abstracting from certain details of structure and component.” (Laszlo and Krippner)

TOGAF is built around three comparable general principles:

1)      An enterprise is composed of interoperating building blocks (components, functions, organisation units, roles, actors, nodes).

2)      An enterprise architecture is an abstract (conceptual, logical) description of building blocks, their interactions and behaviors.

3)      The generic meta model is: required behaviors <are assigned to> logical structures <are realised> physical structures.

 

This table shows different names are given to the same general concepts, often at different levels of abstraction, formality or granularity.

 

Behavior elements names

Structure element names

External view

Service, Service Contract

Interface, Boundary, Service Portfolio

Internal view

Process, Value Stream, Scenario

Building Block, Component, Function, Organisation Unit, Role, Actor, Node

 

Core terms can be defined in a way that is general to TOGAF and ArchiMate.

Structural elements (persist between behaviors)

·         Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

·         Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

·         Component: a building block defined by the one or more services it offers to clients.

·         Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.

 

Behavioral elements (run from start to end over time)

·         Service: a discretely requestable behavior that encapsulates one or more processes; it is triggered by an event or service request and produces a result of value; and is definable declaratively in a contract.

·         Process: a behavior composed of steps in a sequence; it is triggered by an event or service request and leads to an interim or final result.

A process, activity or sequence diagram can relate process steps to structure elements.

 

The TOGAF meta model can be tabulated thus:

 

 

Required behaviors

are assigned to

Logical structures/building blocks

are realised by

Physical structures/building blocks

Business

Business Services

Functions

Organisation Units

Roles

Actors

Information Systems

IS Services

Logical Application Components

Physical Application Components

Technology

Platform Services

Logical Technology Components

Physical Technology Components

 

Implicit in TOGAF are the equations: function = logical business component, and organisation unit = physical business component.

The abstract/logical building blocks cluster behavior types that concrete building blocks can be nominated to perform.

The concrete/physical building blocks are nominated to realise or perform instances of those behavior types.

Read Building Blocks and Services for more detail.

 

This table generalises how different frameworks describe GST concepts.

GST system constructs

Business in BIZBOK®

Business in TOGAF®

Applications in TOGAF®

Software in UML

Abstract system structure: the network in which nodes interact

Capability/Outcome Network, Flows between Capabilities.

Node Connectivity Diagram, Flows between Nodes

Application Communication Diagram , Interface catalog (flows between applications)

Class Diagram: relationships between classes

Abstract structure node groups required activities

Capability?

Function, Role

Logical application component

Class

Concrete structure node is nominated to perform activities

Capability?

Organization unit, Actor

Physical application component

Object

Response or output required from activities

Value

Business Service

IS Service

Output parameter

Abstract behavior sequences activities

Value stream

Scenario, Process

Use case, PAR diagram

Interaction, Operation

Abstract action is an atomic activity

?

Elementary Process/Function

?

Action

 

Every flow between concrete structure nodes delivers something of value to the receiving node.

The last flow in an "end to end" stream/scenario/process/use case delivers the value wanted by the end customer/client/user node.

Enterprise Architecture and SST

The processes of life in an individual organism are very different from the cross-generational process of evolution.

To maintain the integrity of the system concept, a general system theory may better separate

·         The operational processes within a system (S) that sustain S or meet its goals

·         The evolutionary processes in a meta system (M) that changes S from one generation to the next.

 

And allow an actor to switch between roles in S and M.

The idealism triangle

The roles and rules of S

<define and change>                  <idealise>

Meta system M     <observe and envisage>      System S

 

Enterprise Architecture is a meta system that transforms system S from a baseline generation to a target generation, under change control

This change control requires there to be an abstract system description that is agreed by stakeholders.

E.g. consider the migration plan in EA frameworks like TOGAF; or the daily stand up meeting agile methods like SCRUM.

 

Where an EA framework might apply SST

What this paper calls SST may be useful to enterprise architects in the course of their work.

A traditional system design method proceeds along these lines.

1.      Define Customers – external entities that need outputs to meet their goals

2.      Design Outputs - that customers need from the system

3.      Design Inputs – that the system needs to produce the outputs

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

5.      Design Processes - step-by-step processes to produce outputs from inputs

6.      Define Roles - in which actors will perform process steps.

7.      Hire and/or make Actors - to play the roles

8.      Organise, motivate, deploy and manage the actors – to perform roles in processes.

 

The organisation must be designed to perform the required behaviors.

An ITSM organisation deploys and manages the operations of computer actors.

A business management organisation deploys and manages the operations of human actors.

SST may be useful in the latter.

Management consultants use these tools to make "interventions" in management structures and other social aspects of a business.

However, the management of human actors is not usually seen as a matter that EA addresses.

 

How EA frameworks apply SST to the meta system that is EA

EA uses SST ideas not so much in defining business systems as in defining the meta system that is EA itself.

E.g. Ackoff’s attempts to align SST with GST and classify systems may be questionable.

However, his more practical “socio-systemic view of organizations” can be seen in the methodologies used by architects in the meta system like TOGAF.

 

Ideas that Ackoff and Checkland might recognise in TOGAF include

·         Start with the business mission, drivers, strategy and goals (and map system elements to them).

·         Define the human activity system before the rest, And the information systems (IS) before the technologies (IT).

·         Define/bound business systems (also IS and IT systems) by defining heir "emergent properties" - the services they provide.

·         Define "viewpoints" and "value propositions" to fit the perspective (Checkland might say Weltanshauung) of each stakeholder.

·         Define the business as a function/capability hierarchy.

·         Define the network of business functions/capabilities provide services to each other.

·         Define value/streams/processes sequential paths through function/capabilities.

 

 

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.