Activity systems thinking – wrt EA

Copyright 2020 Graham Berrisford. A chapter in “the book” at https://bit.ly/2yXGImr. Last updated 05/05/2021 10:09

 

The aim of this chapter is to outline some principles of activity system thinking and to show how they underpin EA. This chapter simply maps various activity system ideas and approaches to EA methods and frameworks.

 

Reading online? If your screen is wide, shrink its width for readability.

Contents

Preface (recap) 1

Activity system thinking. 1

A soft systems view of activity systems. 4

A cybernetician’s view of activity systems. 6

Scientific management (material processing) 9

The need for EA.. 10

EA methodology basics. 14

Conclusions and remarks. 16

 

Preface (recap)

In designing an activity system, the natural sequence is aims before activities before actors.

 

In defining aims, the normal practice is to zoom out, encapsulate the system of interest, and consider the effects it should produce. The overarching concern is the desired outcomes of system activity.

 

In defining the activity system needed to meet aims, the focus is on defining processes that produced desired effects, the rules to be followed and roles actors play in activities.

 

In defining the social entity in which actors are employed, the focus is on how actors are directed, motivated and organised to perform required activities; including general principles for actors to follow, specific aims for their activities, and the structure under which actors managed.

 

For discussion of aim and social entity thinking, read the previous chapter. This chapter focuses on activity systems thinking.

 

It has been said that EA regards an enterprise as a "system of systems". More accurately, EA sees a business as a social entity that employs a messy patchwork of activity systems, which may interact, overlap, and even be in competition. EA strives to extend and improve these activity systems, and optimize how they are coordinated to the benefit of the whole.

Activity system thinking

An activity system, being characterized by regular activities, is a pattern of behavior we can model. This table contains examples of systems in which actors interact in regular activities to advance the state of the system.

 

System

Actors (active structures)

Activities (behaviors)

State variables

A solar system

Star and planets

Orbits

Planet positions

A windmill

Sails, shafts, cogs, millstones

Rotations that transform wind energy and corn into flour

Wind speed, corn and flour quantities

A digestive system

Teeth, intestines, liver, pancreas etc.

Transformation of food into nutrients and waste

Nutrient and waste quantities

A termite nest

Termites

Disperse pheromone. deposit material at pheromone peaks

The structure of the nest

A prey-predator system

Wolves and sheep

Births, deaths and predations

Wolf and sheep populations

A tennis match

Tennis players

Ball and player motions

Game, set and match scores

A church

People

Roles in the church’s organization and services

Various attributes of roles and services

A billing system

Customer and supplier

Order, invoice, payment

Product, unit price, order amount

 

Three core concepts of activity systems thinking are defined below.

 

Actor: an active structure of any kind (person, planet, cell, machine etc). It occupies space. It has either evolved, or has been made, bought, hired to perform activities.

 

Activity: a regular behavior or process, performed by actors over time. The term “regular” implies we are able to describe or model the activity, perhaps in a value stream, flow chart or a causal loop diagram. Activities can create, use and change passive structures (material or information) and active structures (actors). They can advance the internal state of a system, and so produce a “line of behavior” over time, and/or produce outputs, which advance the state of the system’s external environment.

 

Aim: a motivation, desired outcome or goal which is ascribed to a system by an observer. (Some express aims as actual outcomes, results or effects, as might be shown in a line of behavior. This ambiguity is addressed in chapter 2.)

 

The questions and answers that Meadows discussed wrt system dynamics are easily translated into more general activity system thinking terminology.

 

Questions

General activity system thinking answers

What characterizes an activity system?

A system is characterized by a pattern of interrelated activities. An activity is a behavior (or occurrent) that changes or makes something. An actor is a structure (or continuant) that plays a role in performing activities.

What are the aims or purposes of a system?

Actors, which occupy space, may be visible or tangible. Activities, which run over time, are harder to see. Aims are even harder to see, and may be perceived or expressed as motivations or as outcomes.

Is every composite entity an activity system?

No, a system isn’t just any old collection of things or actors. It is a collection of actors organized to perform the system’s characteristic activities.

Is there anything that is not an activity system?

Yes, a passive structure (Linnean classification of species, the Dewey decimal system, the periodic table in chemistry). And a collection of actors that do not interact in a recognizable pattern of activities.

How to know you are looking at a system? not just some stuff that exists or happens?

a)     Are the activities regular and repeatable?

b)     Are the actors’ roles in those activities regular and repeatable?

c)     Do actors interact to produce effects (state changes and outputs) they cannot produce on their own?

Which of actors, activities and aims are most important?

All are essential to what a system does, and interdependent. What matters most are usually its aims and the effects of activities. The actors, the most tangible and visible elements, are often the least important.

What does it mean to change a system?

Changing actors usually has the least effect on a system (change every player on a football team, it is still a football team). But if a systems’ activities change, then it mutates into a new system generation, or a different system. Changing a desired aim usually implies changing the activities, which sometimes implies changing the actors.

 

SEE “MORE IDEAS FROM SYSTEM THINKING HISTORY” ON MEADOWS IDEAS

 

On the UML standard

UML is a standard for graphic symbols that represent concepts used in the modelling of business and software activity systems, where a system is a collection of actors (called active structures in UML) that combine to perform activities (called behaviors).

 

The concept at the base of the standard is the atomic activity performable without further explanation (called an action). Everything else in UML is ways of organizing those atomic activities into larger structures and longer behaviors so as to describe and design systems.

 

The normal practice is to begin by encapsulating a system and defining the required activities in one or more interfaces. Each operation in an interface is an activity. Another way to define the required activities is to draw a diagram of use cases. Each use case is a process that external actors play roles in. When it comes to defining the internal structure of a system there are many design options; some more procedural, some more object-oriented, but UML doesn’t favor either.

Specific activity systems thinking approaches

There are at least four broad approaches to activity systems thinking.

 

Soft systems approaches focus on human activity systems, in which human actors play roles in activities. They include matters specific to that kind of system, but say less than social entity thinking approaches that focus more on the motivation and management of people.

 

Cybernetics focuses on inputs (events, perturbations) and the effects they produce by way of system state changes and outputs. To discover the long-term effects of inputs over time, you may run a simulation, or observe the actual outcomes, of the described system.

 

System dynamics focuses on flows (which may represent batches of discrete inputs) and the effect they produce by way of increasing and decreasing quantitative variables some kind. Individual activities are modelled only indirectly, at a higher level of abstraction by composition. E.g. the individual activity in which a wolf kills a sheep does not appear (except as a unit of 1 within a quantity); rather, the model reveals the overall effect of several wolves killing several sheep over a period of time.

 

Agent-based approaches model individual behaviors and extract quantitative measures from their collective behavior.

 

This table distils how the first three systems thinking approaches view an activity system.

 

Soft (business) systems

Cybernetics

System dynamics

Regular activities transform

inputs into outputs wanted by customers

Regular activities maintain

variables that describe the state of actors (organisms, machines, societies)

Regular flows increase/decrease

variable stocks that represent the state of resources or populations of any kind

Feedback loops connect

a business to its environment thus:

a) it detects changes in the state of its environment

b) it determines responses

c) it directs entities to perform activities.

Feedback loops connect

control systems to target systems or entities

a) a receptor senses changes in the state of the target

b) a control center directs responses, and

c) an effector changes the state of the target.

Feedback loops connect

stocks that respond to changes in each other.

The whole model represents a closed system or ecosystem.

Observers may draw a business activity model.

Observers may observe the current state of a system, and draw a graph to show how the system's state changes over time.

Observers may draw a diagram of flows between stocks, and draw a graph of stock level changes over time.

 

In EA, most businesses depend on some socio-technical systems, or human and computer activity systems. These systems might be modelled using a soft systems method, the mathematics of cybernetics, or the causal loop diagrams of system dynamics. The last is rarely applied directly in EA, but its general principles are relevant, and EA methods clearly do feature ideas from soft systems methods and cybernetics.

A soft systems view of activity systems

The term “soft system” is used with at least three meanings: a) an observer’s perspective of a business system or situation; b) a system in which the observer is an actor and c) a human or socio-technical system in which people perform activities to meet aims. Remember that all you can model of humans in an activity system are their roles in activities, not the individual people.

 

The distinction between hard and soft systems is debatable: a) all scientific system thinkers consider a system to be “soft” in the sense that it is a perspective or model of some physical phenomena; b) even Ashby included himself in a system as an observer of its behavior; and c) one end result of a soft systems method is a business activity model, to which general activity systems thinking principles apply.

Ackoff’s view of activity systems

“Different observers of the same phenomena may conceptualize them into different systems”. Ackoff

 

Russell Ackoff was known as a brilliant observer of humans, their institutions and their failings. However, in “Towards a System of Systems Concepts” (1971), when setting out more than thirty general ideas about systems, he started some distance from human society with eleven terms and concepts that clearly derive from more general system theory and cybernetics.

1.     System: two or more interrelated objects (parts or elements).

2.     Abstract system: a system in which the elements are concepts. 

3.     Concrete system: a system that has two or more objects.

4.     System state: the values of system properties (state variables) at a particular time. 

5.     System environment: those elements and their properties (outside the system) that can change the state of the system, or be changed by the system. 

6.     System environment state: the values of environment properties at a particular time. 

7.     A closed system: one that has no environment. 

8.     System/environment eventa change to the system's state variable values.

9.     Static (one state) system: a system to which no events occur (it does not change).

10.  Dynamic (multi state) system: a system to which events occur (its state changes).

11.  Homeostatic system: a static system whose elements and environment are dynamic.

 

In EA?

A concrete business system (3) realizes an abstract system (2). The system is open (7) dynamic (10) and interacts with its environment (5). It recognizes input events that represent changes to the state of entities (people, processes, materials and machines) in the environment (8). It maintains system state variables (4). It informs, directs or enables consumers or customers change the system environment state (6) and meet their aims

 

The business system of interest may be characterized as in the diagram below.

 

Open dynamic system

System environment

Inputs

Outputs

System State

ß Suppliers

à Consumers

Environment State

 

 

For more on Ackoff’s ideas…

SEE “MORE IDEAS FROM SYSTEMS THINKING HISTORY” CHAPTER

Checkland’s view of activity systems

Noting that different observers may perceive different systems in one organization, Peter Checkland spoke of stakeholders as having their own “weltenshauung” or world view.

 

Checkland’s Soft Systems Method

World views

<create and use>                        <represent>

Observers <observe and envisage> Business activity systems

 

Checkland’s method involves capturing each observers’ view in a “root definition” of the system, using the CATWOE acronym.

·       Customers – Who are the beneficiaries of system behavior?

·       Actors – Who plays roles in the system?

·       Transformation process – What is the essential input to output transformation?

·       Weltanschauung – What is the observer’s world view or big picture?

·       Owner – Who owns the system, transformation or situation being investigated?

·       Environmental constraints – What constraints and limitations will impact the solution?

 

Note that of the six letters in the CATWOE acronym for describing a system of interest, five can be found in the extended SIPOC diagram drawn below.

 

Environment

Transformation

Environment

Suppliers

Actors

Inputs à Processes à Outputs

Owner and Actors

Customers

Actors

 

Different modellers, speaking to different stakeholders, may come up with different CATWOE sentences, different systems of interest. Reconciling different perspectives is part of what must be done, even in the hardest of engineering projects. Checkland noted the distinction between hard and soft system approaches is slippery. He wrote that people get it one day, and lose it the next. And sometimes he said the term “soft” was intended to characterize his method – not the system of interest. For more, read Checkland’s ideas.

A cybernetician’s view of activity systems

"A system... is independent of the concrete substance of the elements (e.g. particles, cells, transistors, people, etc).” Principia Cybernetica Web

 

A system is an island of stability in the infinitely complex and ever-unfolding process of the universe. A system is a regular pattern in that process, which can be modelled. Some go as far as to say systems exist only in models; and don’t exist in the real world. That is misleading.

 

An earlier chapter listed ten cybernetic ideas applicable to EA.

 

Idea 1: A regulator needs a model of its environment

In EA, a business information system maintains a model of entities and events the business monitors and directs. The question is not whether a business has a model; it is how complete and accurate is the model? To which the answers might be both “very incomplete and somewhat inaccurate” and “complete and accurate enough”.

 

Idea 2: Abstract systems represent physical systems

EA cannot address the whole of the social entity that is a business. It addresses the roles that business actors play in a performance of particular processes, and the resources they need to play those roles.

 

Architects both observe and describe current/baseline systems, and envisage and design new/target systems. To do this, they need abstract systems - models - they can manipulate in their “mind’s eye”.  So, EA is about systems that can be modelled, and models that can be realized as systems. As Groucho Marx might have said: "An enterprise that is simple enough to understand without a model of it is one that doesn't need an enterprise architect."

 

Enterprise architecture

Abstract systems

<create and use>         <represent>

Designers <observe and envisage> Physical systems

 

At design time, there is an abstract system, a complex type that relates simpler types of many kinds: data entity types like customer, event types like order and payment, process types like billing, and rule types like order value = order amount * unit price.

 

 

A billing system

Abstract system

An architecture definition is a complex type, describing business roles and activities and how they relate to each other.

Physical system

Business operations exhibit or instantiate the architecture definitions

Physical entity

Enterprises employ actors to play roles in business operations.

 

At run time, supervised by managers who keep thing in order, business actors realize the abstract system in a physical system that consumes inputs, creates business data and uses it to decide how to respond to events.

 

Again, there is a many-to-many relationship. One generic activity system model can be realized by many particular businesses. One business can realize several activity systems, (ranging from generic to organization specific).

 

Idea 3: Systems can be coupled by information feedback loops

If a control system is to monitor and direct the state of a target system then it must know or remember the state of that target system, and update that knowledge or memory by getting information from the target system. Thus, control and target systems are connected in feedback loop.

 

 

Feedback loop

Business

 ßstate information  

directionà

Customers and suppliers

 

In EA and BA, actors encode information (descriptions, decisions and directions) in data flows or messages. External actors can couple to a system in two ways: as providers of inputs, and as consumers of outputs. Enterprise architects can couple to a system in two ways: as a provider of inputs, and as an observer of its inputs and outputs.

 

Idea 4: Most systems of interest can be modelled using discrete dynamics

To describe the continuous flow of time in the universe, we divide changes into discrete steps. In EA, the focus is on digitizable business activity systems. The systems are modelled in terms of discrete entities and events, discrete actors and activities. Events trigger actors to perform activities that advance the system’s state. The state variables in data stores and data flows have discrete (rather than continuous) values.

 

Idea 5: Activities are constrained by rules

In EA, the primary concern is regular business operations in which the range of possible activities is defined. And if no action is detected when expected, then a time-out event may trigger some compensating action. Business systems maintain data that records the state of entities and events that the business must monitor and direct in its environment.

 

The primary concern is business operations that are regular, in which the range of possible activities is defined. If no action is detected when expected, then a time-out event may trigger some compensating action.

 

Idea 6: An activity system advances state variables

In EA, Business systems maintain data that records the state of entities that the business must monitor and direct in its environment.

 

Environment

Open system

Environment

Suppliers

Inputs

Actors <perform> Activities

Inputs + States <determine> Activities

Activities <consume> Inputs

Activities <change> States

Activities <produce> Outputs

Outputs

Consumers

 

In EA however, the lines of behavior are not often of interest.

 

Idea 7: Mutation differs state change

In EA, business systems are dynamic and change in two senses which refer to different processes. “The distinction is fundamental and must on no account be slighted.” System state changes may be called updates. System mutations are called migrations. Data that records the state of entities is advanced by discrete state changes. The system itself may advance, under change control, by discrete mutations.

 

Idea 8: Self-organization implies a higher entity or system

EA can be seen as the higher entity or system for organizing the systems of an enterprise.

 

Idea 9: The law of requisite variety

In EA, business systems must remember enough about entities and events of interest (both inside and outside the system of interest) to direct them as need be.

 

Idea 10: Coding is ubiquitous in thought and communication

In EA, actors perform activities including sending and receiving messages (data flows) and reading and writing memories (data stores). Ideally the activity system is a bounded domain, in which actors share a domain-specific language. We’ll return to this in part 4

Scientific management (material processing)

Parallel and related to the history of activity system theory has been the revolution in manufacturing and supply chain businesses. A common theme is the measurement and continual improvement of end-to-end business processes. Where continual really means frequent, incremental, small-scale, discrete changes.

 

Taylorism

Taylor is remembered for his work (book 1911) promoting a scientific approach to the study of workflows in manufacturing, looking to measure productivity and increase it by optimising how the work is done. His proposal that workers be rewarded for their productivity (piece work) was based on his observation that if not rewarded, workers will tend to work at the slowest rate not actually punished. He is less known for endorsing a kind of “self-organization”, saying that "whenever a workman proposes an improvement, it should be the policy of the management to make a careful analysis of the new method”.

 

Toyota's Production System (TPS)

TPS was born in the 1930s to organize the manufacturing and logistics for the automobile manufacturer. The most significant impacts are achieved by designing an end-to-end process capable of delivering the required results smoothly; by designing out "mura" (inconsistency), without stress or "muri" (overburden) and reducing "muda" (waste). 

 

Lean manufacturing

TPS was a major precursor of the more generic “lean manufacturing” developed between 1948 and 1975 by Japanese industrial engineers Taiichi Ohno and Eiji Toyoda. The lean production method defined in 1996 by Womack and Jones promoted five key principles:

 

1.     Value - Enter into a dialogue with the customer. Identify the value the customer obtains from a product or service. Form a team to stick with a product from start to end.

2.     Value Stream - Identify the end-to-end process for delivering a product or service and challenge all peripheral or wasteful activities.

3.     Flow - Make the value-adding steps flow continuously

4.     Pull – Arrange the process such that later steps pull what they need from earlier ones.

5.     Perfection – Continuously look to reduce the number of steps, the time and information needed to complete the value stream

 

Value stream mapping (VSM)

This is a particular lean management method for analyzing and designing processes that act on materials and information, and deliver a product or service to a customer. It is recommended that front-line workers be involved in VSM, and that process is improved “continuously” by making small increment changes.

 

In EA, the analysis of value streams, or end-to-ed business processes, is central to business architecture in EA. However, it must be noted that designing the material flows of a supply chain or manufacturing business is a specialist “operational research” activity. EA addresses material processing only in so far as it relates to information processing, with regard to the business data that each activity creates and uses, and the support that IT systems can provide.

The need for EA

"Managers do not solve problems, they manage messes". Ackoff. 

 

No business "organization" is fully and perfectly organized; it is somewhat messy assembly of aims and activities. However, most enterprise do strive to systemize some of their activities. A business activity system is characterized by regular activities, it is orderly, and is realized by actors and resources that are coherently organized and interconnected so as to perform required activities.

 

Activity systems theory is helpful when architect seek to:

·       understand how some outcome arises from some regular behavior.

·       predict how some outcome will arise from some regular behavior.

·       design a system to behave in a regular way that produces a desired outcome.

·       intervene in a situation to change some regular pattern of behavior.

Above EA

Business directors are responsible for business planning.  They respond to business drivers by declaring strategic directions and top-level goals/objectives. Business planning may involve predicting demand and directing changes to any of the following:

·        Constitution: mergers, acquisitions and divestments, opening/closing outlets.

·        Market: industry domain/sector/segment, customers and suppliers.

·        Products and services: sales and service channels, prices.

·        Relationships: partners, in-sourcing and out-sourcing of operations.

·        Resources: people, wages, machines, locations/buildings and other physical asset types.

·        Management structure: sacking or appointing CxOs and restructuring the organisation.

 

Enterprise architects may both stimulate and contribute to business planning. But their primary responsibility is business system planning (below).

The need to address a mess of systems

The boundary of a system is determined by observers with an interest in its outcomes. You can draw a boundary around a steam engine with some hope of describing its internal actors and activities - reasonably comprehensively. You cannot draw a boundary around an enterprise with the same hope.

 

In reality, a business is more a mess of systems than a system of systems. You can find countless different activity systems in it.

 

·        Systems large and small.

·        Systems nested and overlapping.

·        Systems more and less connected by information flows to others.

·        Systems synchronized and out of step with each other.

·        Systems that cooperate and compete with each other.

 

EA grew out of looking to extend or optimize the performance of an enterprise, by taking a cross-organizational and strategic perspective, by standardizing and integrating activity systems. EA is a never-ending struggle to improve, synchronize and extend systems. To make them more efficient and effective to the benefit to the wider business, and its stakeholders.

The need for semantic interoperability

Obviously, an enterprise with scores, hundreds or even thousands of databases, each having its own domain-specific language, will suffer “semantic interoperability” challenges. How to resolve discrepancies between languages used in different bounded contexts?

 

A)    Point to point translation. If the meanings of data types in one system can be correlated with the meanings of data types in another system, then architects can insert transformers or adapters to translate data structures in transit between systems.

 

A is the approach used where system development is opportunistic and incremental. But from a wider perspective it is suboptimal. So, enterprise data architects strive to acquire or define a controlled vocabulary in some kind of enterprise data model or data dictionary. It defines, for example, the canonical form of "policy number" as an eight digit number, the identifier of a "policy" entity, which has an agreed set of attributes/variables. This "meta data" can be used in three ways.

 

B)    Hub and spoke translation. Architects can insist that every local variation of policy number is translated into and out of the” canonical” form when a message passes between systems. This implies the use of a message broker that holds the canonical data models and does the translations.

 

C)    Data standardization. Architects can impose the rule that every instance of “policy number” in every memory (data store) has the same data type and meaning. This removes the need for translation steps between systems.

 

D)   Shared memory. All enterprise data is stored in one database.

 

To begin with, in 1980s, EA (for example, John Zachman) promoted D as the preferred solution. In a world in which more systems are distributed, and more remote systems are connected, this has proved impractical. How far standardization efforts of kinds B and C can reduce the complexity and overhead of A is an open question.

The need for change control

The actors playing roles a system cannot continually change how they individually interpret messages and respond to them. That would undermine the concept of an activity system. E.g. The actors playing a game of poker cannot unilaterally decide to follow different rules. To change the roles or rules of the system is to design a new system, or system generation, and to implement such a change requires the agreement of all actors, both those that play roles in the game and any other stakeholders with concerns about the game.

 

So, EA presumes business activity systems will be stable for a generation. A system will be changed in discrete and testable steps, from one generation to the next. In agile software development, the generation is short; in EA, the generation is long. In both, changes to designed activity systems must be made under change control – else the concept of the activity system evaporates.

The need for "design thinking"

Generally, designers order elements of an entity to produce desired outcomes. More specifically, enterprise and business architects order elements of a business to produce desired outcomes. Above all they order those regular business roles and processes that create and use business data.

 

The most well-known architecture framework is called TOGAF. It is neither a prescriptive process, nor entirely consistent and coherent. It is a flawed but highly flexible assembly of processes and products people adapt as they choose for change initiatives that need big-up-front design and planning.

 

Herbert Simon defined "design thinking" in “The Sciences of the Artificial” (1969).  TOGAF clearly embodies Simon’s "design thinking" principles. His core ideas being that designers

·        spend time up front deciding the basic/fundamental/root issue(s) to be addressed;

·        don't search for a solution until they have determined the real problem; and

·        consider a range of potential solutions before settling on one.

 

TOGAF embodies those and other design thinking ideas below.

·        Capture the inspiration, the vision (TOGAF phase A).

·        Take a human-centric view of business processes (A and B).

·        Manage stakeholders and value propositions (throughout).

·        Treat all design as re-design, as a baseline to target transformation (throughout).

·        Make ideas tangible to facilitate communication.

·        Use visual languages, sketch diagrams and technical drawings to show abstract requirements may be met by concrete systems (A to E).

·        Double loop learning (throughout).

 

In the 1980's Chris Argyris promoted double-loop learning, teaching people to think about their assumptions and beliefs, as a tool for system design. While TOGAF does not explicitly promote double-loop learning, it is crammed with directions to revisit assumptions. At every phase, architects check what is being proposed against, business drivers and goals, and the concerns and requirements of stakeholders. And this is done alongside continual requirements change management.

The need for abstraction

In describing business activity systems, an enterprise architect must abstract from detailed design. Abstraction is not a simple or singular idea. The table below characterizes four kinds of abstraction, arranged in a hierarchical fashion, with the abstract or more vacuous concept at the top and the physical or more elaborate concept at the bottom.

 

Delegation

Composition

Generalization

Idealization

Client

 

Server

Whole

Part

Atomic part

Universal

Common

Unique

Conceptual

Logical

Physical/Real

Service provision

Decomposition

Specialization

Realization

 

All four varieties of abstraction are employed in standards for EA such as TOGAF and ArchiMate.

Delegation and composition hierarchies

In practice, architects probably make most use of the composition and delegation hierarchies. This table characterizes hierarches found in the architecture framework called TOGAF.

 

Delegation

Composition

Business

Applications

Technologies

Enterprise/Strategy

Segment

Solution/Capability

Service provision

Decomposition

Generalization and idealization hierarchies

A generalization (aka class) hierarchy may be constructed from the bottom up by grouping things that share one or more common features into a type, then abstracting supertypes from subtypes. A famous generalization hierarchy is the classification of species.

 

The ideal of the classifier is to build a tree in which a type at the bottom of the hierarchy has every feature of all the types above it. In such a strict or pure type hierarchy, each subtype “inherits” the features of all subtypes above it, and “extends” their features with additional ones.

 

Idealisation may be seen as a variety of generalization in which, from the bottom up, one abstracts a detailed description from a physical reality, then successively removes what might be called physical features to form more logical and conceptual descriptions.

 

Abstraction by idealization appears in the Zachman Framework, which is a 6 by 6 grid for classifying the artifacts that describe or typify a particular enterprise and its busines operations. And the architecture framework called TOGAF features all four kinds of abstraction.

 

TOGAF’s "enterprise continuum" can be seen as 4 by 4 grid that classifies descriptive artifacts into three degrees of generalization from the particular business, and three degrees of idealization from real-world busines operations.

 

     Generalization

Idealization

Universal

foundation

Common

system

Industry

domain

Unique

organization

System

Requirements

 

 

 

 

Abstract

Architecture continuum

 

 

 

 

Solution continuum

 

 

 

 

Deployed solutions

 

 

 

 

Physical

 

Though the enterprise continuum encourages architects to abstract in the two ways shown, it is probably more a teaching device than a practical repository classification tool.

The need for methodical design

To paraphrase Meadows’ description of a system: the actors are the most concrete and tangible elements, the activities are harder to see, and the aims are even harder to see. However, recommended practice for designing an activity system is to defining the abstract before the concrete thus:

 

1.     Aims to be met

2.     Activities required to meet aims

3.     Actors required to perform activities.

 

This simple process can be extended into a business activity system design method along the lines below.

 

1.     Aims of stakeholders

2.     Products/services that people need to meet the aims.

3.     Processes that sequence activities to deliver the products/services

4.     Roles required to perform the activities

5.     Data created and used by activities

6.     The social entity/actors that perform roles

 

The sequence is flexible. The choice between robot or human actors might lead you to modify the roles or the activities. But in general, you can't or don't want to acquire actors with no regard to their roles. Or define roles with no regard to activities and processes they are responsible for. Or define processes and services with no regard to their goals.

EA methodology basics

The next section sketches out a BA in EA methodology to be explored in a later chapter

 

1 Aims or goals

There are accidentally evolved-systems, like the solar system, a tree and a beehive. But EA is about purposefully-designed systems. These are ordered or organized by designers to produce outcomes that meet some given or aims or goals. So, given a system of interest, EA starts from the aims of system sponsors and other stakeholders. It identifies the desired outcomes that currently or should emerge from business activity.

 

2 Product or services

EA identifies the products and services that currently or should emerge from business activity, to mee the aims. (A service contract template was introduced in the previous chapter.)

 

3 Activities and processes

EA defines a system in two ways: externally (from the outside) in terms of input-to-output transformations made, and internally in terms of activities performed and state variables maintained. Activities are sequenced in processes (or value streams). The SIPOC view below encapsulates the processes of such a system and connects it to actors in its environment.

 

 

 

Open system

 

Suppliers

Inputs

à Processes à

Outputs

Consumers

 

This SIPOC diagram is only a simple overview. It doesn’t show feedback loops between a business system and actors in its environment. The outputs of a business system (say invoices) can influence its future inputs (say, payments).

 

Nesting of systems. The boundary of a system is in the eye of the observer(s). E.g. a boiler transforming water into steam may be seen as a system, or a subsystem of a steam engine. Having encapsulated a system, you may divide it into subsystems that interact. Then, each subsystem can be decomposed, and so on, until you reach what you regard as atomic actors and activities.

 

System decomposition is a simple idea; it is important and useful today. However, there are many other ways of looking at systems, and systems thinkers use many terms ambiguously.

 

4 Logical active structures

EA is largely not about physical structures (buildings, hardware, vehicles and human bodies).

Some misleadingly liken activity system architects to building architects. And true, both shape what is to be made and govern those who make it. But you can visualize a building and instantly recognize it in a picture or photograph. Whereas, you cannot visualize a dynamic activity system (like a poker game) in a comparable way.

 

However, EA does define logical structures (functions and roles) and assign activities to them.

 

5 Passive data structures

EA is about systems in which human and computer actors are “active structures”. These actors create and use passive structures, notably, data/information structures.

 

Generally speaking, systems consume flows of energy, matter, forces or data. In EA, the focus is on the last of those, on data/information flows. Since businesses operations depend on business information, a business needs information systems to

·       monitor and direct business actors and activities (people, processes and machines).

·       maintain state variables that represent the state of business operations (actors, activities and resources).

·       are updated by inputs submitted by business actors.

·       produce outputs that inform and direct the actors and activities in business operations.

 

General speaking, actors remember information in memories, and communicate information in messages. The memories and messages contain data structures. Actors create and find information, in those messages and memories, by encoding meaning in symbols and decoding meanings from symbols. Successful communication requires the sending and receiving actors share a common language, and so share the meanings of symbols in messages and memories.

 

EA does not model ad hoc or spontaneous communications. It does model regular messages and memories, and the data structures they contain.

 

6 The social entity that implements a system

Logical functions and roles must be mapped to physical organization units and actors. So, EA does require some social entity thinking about how activities and/or actors grouped for management, and the individual that play roles in the systems of interest.

Conclusions and remarks

The aim of this chapter is to outline some principles of activity system thinking and to show how they underpin EA. This chapter simply maps various activity system ideas and approaches to EA methods and frameworks.

 

The next two chapters say more about the modelling of activity systems by enterprise and business architects.

 

The relevance of activity systems and cybernetics to EA is distilled in two lists below.

 

How EA applies activity systems thinking

EA sees a business as a social entity that may realize any number of (possibly conflicting) activity systems, and strives to coordinate them.

EA is about activity systems that can be modelled, and models that can be realized.

EA cannot define the whole of a business as one activity system.

It can identify where selected parts act holistically in regular or repeated ways.

And identify many such activity systems - nested, overlapping, competing.

It strives to optimize how systems are best coordinated to the benefit of the whole.

EA starts from the aims of system sponsors and other stakeholders, and identifies the desired outcomes, products and services, that currently or should emerge from business activity.

EA sees a business system as a holistic network of activities, which are sequenced in deterministic, probablistic and possibilistic processes (or value streams).

EA is largely not about physical structures (buildings, hardware, vehicles and human bodies) but it does assign activities to logical structures - functions and roles.

EA is about business roles and processes in which active structures - human and computer - create and use passive data structures to store and convey information.

EA requires also some social entity thinking, where logical functions and roles are mapped to physical organization units and actors.

 

How EA applies cybernetics

EA business information systems maintain models of the entities and events that the business monitors and directs in its environment.

EA is about systems that can be modelled, and models that can be realized as systems.

In EA, the relationship between activity systems and social entities is many to many.

EA is about digitizable business activity systems.

EA is about regular business operations in which the range of possible activities is defined.

EA is about systems that maintain data that records the state of entities and events of interest.

EA is about systems that change by state change, and by mutation under change control.

EA is a higher social entity, process or meta system for organizing the systems of an enterprise.

EA is about systems that remember enough about entities and events to direct them.

EA is about actors and systems that exchange information in messages. It may resolve discrepancies between languages used in different bounded contexts by standardization or by inserting transformers or adapters.

 

On the terminology torture in EA

Standards architects like TOGAF, ArchiMate, BizBOK and UML are terminology torture on their own - let alone in combination. Authors use ordinary words (like service, process, function, capability, actor, interface and process) with a variety of meanings. For the meanings of these terms and more try these related Linkedin articles. They include a slide show relating EA and BA concepts to general system theory.

 

None of the above speaks to the motivation and management of human actors. By contrast, social entity thinking focuses on outcomes and actors, rather than inputs or activities.