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.
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.
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.