EA as applied system theory

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 22/07/2017 10:48

 

A series of 8 articles on EA as applied system theory.

The definitions of system theory terms are copied from “Introduction to General System Theory.”

These articles illustrate some EA ideas using the Open Group Architecture Framework (TOGAF).

Note that TOGAF is so general it is often used to manage solution-level work, rather than EA.

Contents

EA as applied system theory -1- The enterprise as a system.. 1

EA as applied system theory -2- Holism.. 4

EA as applied system theory -3- Systems. 5

EA as applied system theory -4- System boundary and information. 7

EA as applied system theory -5- System structure and behaviour. 9

EA as applied system theory -6- System change and complexity. 12

EA as applied system theory -7- Abstraction of system description. 15

EA as applied system theory -8- The systems that EA governs. 18

 

EA as applied system theory -1- The enterprise as a system

This is the first of 8 articles on EA as applied system theory.

These articles illustrate some EA ideas using the Open Group Architecture Framework (TOGAF).

The term “system” makes 1,357 appearances in 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.”

 

So, what is a system?

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

 

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

 

Solution architects work to support/enable, speed/scale up, optimise/extend business roles and processes in a narrow scope.

EA grew in the 1980s out of the requirement to reduce cost and quality issues caused by “silo systems” (not standardised, not integrated, and not sharing common services).

·         “EA is concerned with “system implementations, extending in scope and complexity to encompass an entire enterprise.” (Zachman).

 

As ever more business processes were digitised, models for EA were established; significant references include:

·         Business information systems analysis should be raised to the “Enterprise-level” (Zachman, 1982 reference).

·         Architecture is divisible into four domains: business, data, application and technology (PRISM report, 1986 reference).

·         The focus is on business and information before technology (NIST EA model, 1989 reference).

 

For decades, authors have put the quality and use of business information at the heart of EA.

·         “Architecture planning is the process… to improve data quality, access to data, adaptability…, data interoperability and sharing, and cost containment.” (Spewak, 1993 reference)

·         “The domain of information-intensive organisations…is the main focus of the [EA modelling] language” (ArchiMate standard v2.1)

·         "Today’s CEOs know that the effective management and exploitation of information… is a key factor to business success.” (TOGAF 9.1, 2009 reference)

·         The Open Group’s vision: “to achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”

·         The Open Group’s mission: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

 

The higher purpose of EA has always been to optimise and improve business processes.

·         “An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference)

·         "Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).

 

The solution architect’s vision usually has relatively short time frame and narrow scope.

The EA vision is broader, to standardise, integrate and coordinate business information and processes across an enterprise.

Both are about those regular business operations that create and use information - about human and computer activity systems that process information.

These systems are open, meaning they connect to their environment via input/output feedback loops.

The systems’ processes are orderly, meaning they are constrained or bound by rules.

 

EA frameworks are about designing, planning and governing changes to regular business roles and processes.

They can be seen as applying the core ideas of General System Theory to business systems.

This table compares a core concepts in TOGAF with a core concepts in General System Theory.

Concepts in General System Theory

Core concepts in TOGAF’s meta model

A bounded structure of

A bounded organisation of

actors/organs that interact by playing

actors/components that interact by playing

roles in

roles in

behaviors to meet

processes to meet

goals, by maintaining the system’s

goals/objectives by maintaining the system’s

state and exchanging

data entities (information state) and providing

inputs/outputs with each other and with

input/output services to each other and to

entities outside the boundary, using

entities playing roles outside the enterprise, using

system resources.

platform technology components.

 

"EA as Strategy” (by Ross, Weill and Robertson) says EA is about “digitizing core business processes”.

 

What does digitisation mean?

It means describing business systems terms of discrete entities and events.

Classifying those entities and events into types so you can deal with all instances the same way

Defining the information/data variables the business must capture and store.

Considering how technologies are best used to support and enable the business systems so described.

EA as applied system theory -2- Holism

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

 

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the second of 8 articles on EA as applied system theory.

 

Reductionist view: describing the parts of a whole, analysing each part in isolation from other parts.

In other words, a description that regards each part as a whole, regardless of things it is related to.

E.g. a description or analysis of the heart, in isolation from other organs of the body.

 

EA grew out of the need to reduce the cost and quality issues caused by “silo systems”.

Silo systems are not standardised, not integrated, and don't share common services.

“EA is concerned with “system implementations, extending in scope and complexity to encompass an entire enterprise.” (Zachman).

Enterprise architects work as enterprise-wide as possible; regarding the business as one large system of systems.

They are expected to document the architectures of business and information systems – at least at an abstract level.

 

Holistic view: a description of how parts relate, interact or cooperate in a whole.

E.g. a description of how the muscles of the human heart interact.

 

EA takes the holistic view; looks to integrate business systems to the benefit of the wider enterprise.

"EA as Strategy” (by Ross, Weill and Robertson) suggests architects look to integrate and/or standardise core business processes.

It encourages architects to engage business managers by identifying their target “operating model”.

 “Operating model” for core business processes

High integration

Coordinated

Unified

Low integration

Diversified

Replicated

 

Low standardisation

High standardisation

 

In other words, EA strives for systemic coherence, which implies:

·         System integration and standardisation

·         Integrity: data consistency, single version of the truth

·         Coordination: sharing of information

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

 

Organicism

Bertalanffy promoted the idea of "organicism" meaning that systems (like organisms) are describable at multiple hierarchical levels.

Consider the decomposition a human society through human bodies, organs, cells, organelles and molecules to atoms.

Or from software application through components, classes and operations to executable instructions.

An entire system at one level may be an atomic element in a higher level system.

 

It is well-nigh axiomatic that:

·         Systems can be hierarchically nested: one system can be a subsystem of another (and can overlap with another).

·         An event that is external to a smaller system is internal to a larger system (and vice-versa).

·         The emergent properties of a small system are ordinary properties of any larger system it is a part of.

 

EA frameworks define an enterprise as a recursively decomposed structure of business functions/capabilities.

(They use this logical structure as their touchstone, rather than the organisation’s management structure, which is relatively volatile.)

They also treat the architecture domains (business, applications, platform technologies) as a client-server system hierarchy.

 

Atomic element: an element that is not further divided in a description.

Note that atomic system actors (living or non-living) may be complex entities in their own right, and may play roles in other systems.

 

The atom in a software system model (as in UML) is an atomic behaviour, a single executable action.

The atoms in a far higher-level EA model can include, for example an application, database or human role.

EA as applied system theory -3- Systems

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

 

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the third of 8 articles on EA as applied system theory.

 

Activity system (aka System): a structure whose elements interact (directly or indirectly) in regular behaviors.

A thing whose regular or repeatable activities act to maintain the state of the thing and/or reach other goals.

E.g. the solar system, an organism, a software system, a choir, a tennis match.

 

EA is concerned with business systems, or human and computer activity systems.

 

Abstract system description: a description or model of a concrete system.

E.g. a narrative, a context diagram, a network diagram, a causal loop diagram, or a combination of such artifacts.

 

EA abstracts system description from operational system contents and workings.

Architects design and govern the definition of business capabilities that are formalised and under change control.

To exercise change control over complex operational systems requires their processes to be documented.

With no description or model (mental or documented) of business operations or roles, there is no agreed system.

If a business has no documented model its operations, then they are not governable against any such a model.

 

So, enterprise architects are expected to maintain system descriptions in line with operational systems.

Their “architecture” is collection of descriptive artefacts, often including graphical models in which diagrammatic symbols substitute for words.

And since the scope of EA is wide, the system descriptions are necessarily abstract.

 

Concrete system (aka System): a system that runs in reality.

A real world entity that can be tested as meeting an abstract system description – well enough.

 

To paraphrase Ashby’s observations in “Introduction to Cybernetics”:

We should be clear about what a "business system” is.

Our first impulse is to point at a concrete business in operation and say "the system is that thing there".

This method has a fundamental disadvantage: every real-world business contains no less than an infinity of variables.

(A real employee has not only a name, salary and role, but also a nervous system, bodily organs, food tastes, musical aptitude, and so on.)

Any suggestion that architects should study "all" the facts is unrealistic, and actually the attempt is never made.

What is necessary is that architects select and study facts that can be usefully monitored or directed by the business.

 

Natural system: a system that runs before it is described by man.

Its repeated behaviors evolve without externally-defined drivers or goals.

E.g. a solar system, weather system or biological organism.

 

Designed system: a system described by man before it runs.

Its reproducible behaviors are defined in response to externally-defined drivers or goals.

E.g, a cuckoo clock, a motor car, an accounting system, a choir, a tennis match.

 

EA is about designed systems rather than natural ones.

EA as applied system theory -4- System boundary and information

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

 

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the fourth of 8 articles on EA as applied system theory.

 

System environment: the world outside the system of interest.

The environment of one system may be a wider system.

The environment of a business system is sometimes called its market.

 

EA is concerned with how business systems relate to customers and suppliers in its environment.

 

System boundary: a line (physical or logical) that separates a system from is environment

It encapsulates the system’s internal structures and behaviors.

 

A business maintains itself in a continuous inflow from suppliers and outflow to customers.

EA sees a business system as a bounded input-process-output mechanism.

·         It receives messages about the state or needs of entities in its environment

·         It processes information in the light of the current state of the business and/or environment.

·         It sends messages to help external entities produce desired effects or outcomes.

 

System interface: a description of inputs and output that cross the system boundary.

An interface defines the system as it is seen by external observers.

An interface may be defined in a contract defining services provided or required.

In social and software systems, the primary inputs and outputs are information flows.

 

EA defines system behaviors in the form of interfaces and service contracts.

E.g. The Open Group promotes service-orientation – defining standards and systems in terms of service portfolios.

TOGAF 9 introduced a content framework and meta model based on this service-oriented approach.

The table below shows the terms TOGAF uses when abstracting Services from Building Blocks.

Generic meta model

Generic entities

Business

Applications

Technology

Required behaviors

Services

Business Services

IS/Application Services

Platform/Technology Services

Structures

Building Blocks

Functions & Roles

Application Components

Technology Components

 

Information: a meaning created or found by an actor in any physical form that acts as a signal.

Any description or direction that has been encoded in a signal or decoded from it by an actor.

 

Businesses operations have always depended on information.

To drive a bus, you need to know the route.

To deliver a parcel, you need the sender address and receiver address.

To write cheque you need the payment amount, and the identity of the recipient.

 

EA focuses primarily on business operations that create or use information.

"EA as Strategy” (by Ross, Weill and Robertson) says the “foundation for execution” includes well-managed information systems.

Why? Because you can't integrate business processes without passing business data between roles and activities.

And you can't standardise business processes unless the actors in those processes are monitored and/or directed by information systems.

 

Signal: any structure of matter or energy flow in which an actor creates or finds information.

In human communications, the physical forms include brain waves and sound waves.

In digital information systems, the physical form is a data structure in a binary code.

 

Architects have to address the physical forms in which actors capture, transmit, store and receive information.

 

Information flow (aka message): physically, a signal passed from sender to receiver, logically, a communication.

Information state (aka memory): see “state” in the next article.

Information quality: an attribute of information flow or state, such as speed, throughput, availability, security, monetary value.

 

In the 1980s, as ever more business processes were digitised, models for EA were established; significant references include:

·         Business information systems analysis should be raised to the “enterprise-level” (Zachman, 1982 reference).

·         Architecture is divisible into four domains: business, data, application and technology (PRISM report, 1986 reference).

·         The focus is on business and information before technology (NIST EA model, 1989 reference).

 

For decades, authors have put the quality and use of business information at the heart of EA.

·         “Architecture planning is the process… to improve data quality, access to data, adaptability…, data interoperability and sharing, and cost containment.” (Spewak, 1993 reference)

·         “The domain of information-intensive organisations…is the main focus of the [EA modelling] language” (ArchiMate standard v2.1)

·         "Today’s CEOs know that the effective management and exploitation of information… is a key factor to business success.” (TOGAF 9.1, 2009 reference)

·         The Open Group’s vision: “to achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”

·         The Open Group’s mission: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

 

The higher purpose has always been to optimise and improve business processes.

·         “An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference)

·         "Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).

 

Information feedback loop: the circular fashion in which input flows influence future output flows and vice-versa.

Brains and businesses can both be seen as information systems.

Both maintain a monitor-direct feedback loop with their environment.

·         They detect events and changes in their environment - via input information flows

·         They remember the entities and events they monitor - in an internal model or information state.

·         They send messages to direct those entities and events.

If the system does not monitor and direct entities and events in its environment efficiently or effectively enough, then it expires or is changed.

 

Clearly, EA is concerned that business information feedback loops are efficient and effective.

EA as applied system theory -5- System structure and behaviour

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

 

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the fifth of 8 articles on EA as applied system theory.

 

The structure/behaviour dichotomy:.a distinction drawn in this table along the same lines as in UML.

Structure: passive structures and actors in space

Behavior: atomic actions and processes over time

An entity may be an active actor (with a thread of control) or a passive object.

Actors respond to messages generated by actors performing communication actions.

All behavior is triggered by and composed of actions performed by actors.

An actor instantiates an entity type/role by performing the behaviors of that type/role.

An action is the atomic unit in the specification of behaviour.

An action converts a set of inputs and into a set of outputs.

Repeatable behaviors are often modelled as discrete event-driven process.

The time between events can small enough to simulate continuous behaviors.

 

EA techniques are specific examples of GST concepts.

EA uses structured analysis to model structural and behavioral views of a business.

An elementary business function/process is an action – the atomic unit of behaviour.

A functional decomposition hierarchy is structural view of those actions (more stable than the organisation’s management structure).

A business process model is behavioural (sequential) view of actions.

 

The primacy of behavior

[Cybernetics] does not ask "what is this thing?" but ''what does it do?" It is thus essentially functional and behaviouristic.” Ross Ashby

The primacy of behaviour over structure is seen in many approaches

·         In Six Sigma’s SIPOC the P stands for process.

·         In Computer Sciences Cooperation’s POLDAT the P stands for process.

·         Service-Oriented Architecture (SOA) defines a system by its external behaviour.

·         The Open Group’s portability principle encourages definitions of systems by their interfaces.

 

EA frameworks start with required services and end-to-end behaviours (aka value streams, business scenarios or business processes).

They define functions/capabilities and roles independently of the organisation's management structure.

 

State: the current structure of a thing, which may be described in values of that thing’s variable properties.

An entity’s concrete state is directly observable in the values of its physical position, energy and material variables.

E.g. the location, temperature, colour, and matter state (solid/liquid/gas) of a thing you see in front of you.

Information state is found in the values of descriptive variables held in a memory or database of some kind.

 

Again, EA techniques are specific examples of GST concepts.

An entity-attribute-relationship model is uses to describe the passive structure of a business information system's information state.

 

EA treats a business as a system whose current state can be represented as a large and complex vector containing thousands of variables.

Of course, this vector is not only very large, but also distributed across scores or hundreds of business data stores.

And so, the architect has to study dis-integrity between databases, and consider where and how to reduce it.

EA strives to ensure the integrity of business system state data.

It looks to improve the consistency and quality of information available to people.

And make it accessible wherever it is needed (cf. the BoundaryLess Information Flow principle of The Open Group).

 

Event: a discrete input that triggers a process that changes a system’s state, depending on the current state.

(Note: this is the basis of modelling a system using discrete event dynamics and system dynamics.)

(Note: information systems also consume enquiry events that report current state.)

 

A business is stimulus-response system; it must respond to discrete events and service requests.

So, EA regards the enterprise as a discrete event-driven system in which the system’s state changes in discrete steps.

It also looks for way to analyse and exploit information that has been remembered in information state.

 

Process: one or more state changes over time, or the logic that determines which state changes lead to which other state changes.

A process may be directly observed in changes to the state of the world.

E.g. an apple falls from a tree; a cash payment is handed by one actor to another.

In the abstract, a process is a description or specification of discrete or continuous state change.

E.g. a flow chart showing the control logic governing event-triggered activities that result in discrete state changes.

E.g. mathematics describing the continuous change to the position of a planet in its orbit.

 

EA presumes processes can be “digitized” and described in flow charts.

Service-oriented specification of business processes is discussed in other papers.

Note that architects need service contracts to include measurable non-functional requirements.

 

Deterministic: the quality of a system that means its next state is predictable from its current state and input event.

 

Architects deal with all kinds of business process that are regular, or determinate and reproducible.

Determinate means the responses of a business (to events and service requests) are determined by business rules applied to system state or memory.

EA frameworks include viewpoints (data models, state charts, interaction diagrams) for modelling event-driven systems.

True, enterprise architects produce only sketchy models, but the roles and rules must be detailed before the systems can be implemented.

 

To facilitate the transactions of government and commerce, EA formalises inter-actor communication and behaviour.

Not only is the representation of information in messages and memories standardised using data types (defined in data models).

But also, the behaviour of actors is standardised using business rules (defined in data, service or process specifications).

 

Linear change: progress or change over time that is represented in a graph as a straight line (or else a regular shape).

Non-linear change: progress or change over time that is represented in a graph as a curve (or else an irregular shape).

 

EA assumes the behaviour of actors in a system is event-driven and shaped by business rules.

But this does not mean the overall behaviour of the business is predictable.

There are several reasons why the behaviour of a business may be, or appear, unpredictable.

 

·         Humans are ignorant of system rules or state

·         Rules involve fuzzy logic or probabilistic formula

·         External market forces

·         The “chaos” (in the mathematical sense) that results from multiple micro-level interactions

 

That “chaos” may not be revealed in system testing or pilot running.

This table mentions two system micro-level modelling approaches that might be used to simulate long-term outcomes.

Modelling approaches

Heterogeneous population

Homogeneous population

Micro-level modelling

System Dynamics

Agent-Based Modelling

Macro-level modelling

Enterprise Architecture (EA)

?

EA as applied system theory -6- System change and social entities

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

 

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the sixth of 8 articles on EA as applied system theory.

 

System change: a change to the state or nature of a system.

The many kinds of system change can be divided between adaptations and evolutions.

 

System adaptation: a change to the state of a system.

·         Update – the processes by which a system’s information state is changed to reflect its concrete state or environment.

·         Homeostatic adaptation – the processes by which a system responds to internal and external state changes so as to maintain its state variables in acceptable ranges.

·         Autopoiesis – the processes by which a biological cell, given simple chemical inputs, sustains/replicates its own complex chemistry.

·         Decay – the gradual loss of an entity’s ability to act according to a system description (if we didn't age and die, our species could not evolve).

 

EA is concerned with adaptive changes to an operational system state, made by business processes

These which occur in the everyday behavior of a business, under its own business rules.

 

System evolution: a change to the nature of a system.

·         Growth by maturation – the processes by which we develop from egg to adult.

·         Evolution by reproduction - the processes by which we creat a new, different, member of our species (system generation N + 1).

·         Learning – the processes by which an organism or AI machine remembers past events and responds to differently to new events (implies pattern recognition and fuzzy logic).

·         Change by design – the processes by which a designed system is changed - the purpose of all enterprise and solution architecture efforts.

 

A biological species or football team evolves when individual members are replaced by members better fitted to their roles.

“Since offspring tend to vary slightly from their parents, mutations which make an organism better adapted to its environment will be encouraged and developed by the pressures of natural selection, leading to the evolution of new species [eventually] differing widely from one another and from their common ancestors.” http://www.oxforddictionaries.com/definition/english

A business evolves when individual business systems are replaced by ones better able to support and enable the business.

 

EA is concerned with evolutionary changes to a system description, made by designers, which define a new system generation.

This table presents EA as being about discrete change rather than continuous change.

Four kinds of change

Discrete change

Continuous change

System adaptation (state change)

Enterprise Architecture (EA)

System Dynamics

System evolution (nature change)

Enterprise Architecture (EA)

No describable system

 

Meta system: a system that defines a system or changes it from one generation to the next.

Human actors perform processes (defined in methods like TOGAF) to define and change designed systems.

Biological evolution depends on the process of sexual reproduction to define and change natural organic systems.

 

Evolution can be seen as a meta system that replaces individuals by different individuals (better suited to their environment), and so changes a social entity or species.

IBM as a system today is different from IBM as a system yesterday.

The named entity has adapted to circumstances by replacing and radically changing the business systems it uses.

 

Similarly, EA can be seen as a meta system that replaces business systems by different systems (better suited to their environment), and so changes an enterprise.

It provides a change management framework.

It can be seen as a meta system that shapes and reshapes the operational systems of a business.

It helps an enterprise evolve or adapt in response to environment forces.

It replaces individual business systems by somewhat different, better-adapted, business systems.

It is about planning the change of formal business systems from one generation to the next.

It is much concerned with the integration of a new business system with existing ones.

 

One might say an EA team makes an enterprise self-organising, but that is somewhat misleading.

The EA team is not involved in performing day-to-day business operations.

Rather, EA is a meta system to the business systems it observes, envisages and plans.

 

EA defines each business system at a particular generation, at a baseline state, transition state or target state.

In each state, the language and behavioural rules of a business system are fixed.

The system runs and is directed according to roles and rules that are stable for a generation.

Which means the definitions of business processes and business data are placed under change control.

 

Social system: a system in which animate actors play roles in regular, repeatable processes.

E.g. bees collecting pollen for a beehive; an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

 

Social entity: a group of actors who may chose their own behaviors, and may interact to reach agreed aims.

E.g. the group of actors hired to play in an orchestra, who may agree to hold a party after the performance.

 

The orchestra’s actors both play roles in a system and belong to a social entity.

The actors cannot perform other symphonies in parallel, because the dynamics of a symphony are continuous.

But other social entities can play roles in different (discrete event-driven) systems - in parallel.

A business can be seen as a social entity in which actors play roles in many systems

Those business systems may be consistent or inconsistent, coordinated or unrelated, or even in competition with each other.

 

System theory is primarily about the roles in the symphony (the system).

That is the sense in which enterprise architecture “regards the enterprise as a system”

“Systems thinking” is more about the actors in the orchestra, and their motivations.

 

A vision of EA is to coordinate the business systems in which business actors play roles.

EA as applied system theory -7- Abstraction of system description

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the seventh of 8 articles on EA as applied system theory.

 

“A system is independent of the concrete substance of the elements (e.g. cells, transistors, people, etc).” [It is abstract]

 

This Scientific Idealism triangle represents TOGAF’s abstraction of architecture definition from operational systems.

TOGAF

Architecture Definition Documents

<create and use>                            <idealise>

Enterprise Architects <observe and envisage> Operational systems

 

This table identifies four varieties of abstraction employed in the TOGAF and ArchiMate standards from The Open Group.

Architecture domains

Architecture levels

TOGAF’s Enterprise Continuum

Delegation

Composition

Generalization

Idealization

Business

Applications

Technologies

Enterprise/Strategy

Segment

Solution/Capability

Foundation

Common System

Industry

Organization

Requirements

Architecture continuum

Solution continuum

Deployed solutions

Service provision

Decomposition

Specialization

Realization

 

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

The Eternal Golden Braid is a classic model of abstraction.

Eternal Golden Braid

E.g. Language

E.g. System theory

Descriptions of description

Dictionaries and grammars that describe sentences

Meta system

Descriptions

Sentences that describe the world

System description

Particular things in reality

The world of physical matter and energy

Regular behaviors in the real world

 

Oddly, to describe a business that employs an information system, the Eternal Golden Braid needs an extra layer.

Since the information systems of a business describe real-world entities and events monitored and directed by the business.

System theory

Business system design

Meta system

System design methodology

System description

System design

 

Live information system

Regular behaviors in the real world

Real world entities and events

 

This table is an attempt to align TOGAF with the models above.

TOGAF

EA framework

Enterprise repository

·         Requirements repository

·         Architecture repository

·         Solutions repository

Deployed solutions

 

Architecture description frameworks

EA frameworks encourage architects to abstract successively more abstract descriptions of from live systems (typically physical > logical > conceptual).

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

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

Some other dimension

Idealisation

Conceptual model

Logical model

Physical model

Real world system

 

E.g. Zachman maps 5 levels of idealisation from live systems against 6 questions (which are more clearly expressed as system theory concepts).

Question

(GST)

Idealisation

What

(Passive

structures)

How

(Behaviors)

Where

(Places where

structures are)

Who

(Active structures)

When

(Time when

behaviors occur

Why

(Aims)

Identification

Definition

Representation

Specification

Configuration

Instantiation

 

Cap Gemini’s IAF map 4 levels of idealisation (or 3 if the physical level = live systems) against 4 architecture domains.

Domain

Idealisation

Business

Data

Information

Systems

Technology

Infrastructure

Context

Conceptual

Logical

Physical

 

TOGAF proposes abstraction by 3 levels of idealisation from reality, and by 3 levels of generalisation from the specific organisation.

It is presumed here that TOGAF’s deployed solutions are live systems, though the diagram could be interpreted as model of them, as in a CMDB.

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

 

The Open Group’s principle is to specify systems by abstracting "open" and "vendor-neutral" specifications from particular implementations.

TOGAF applies this principle, first by service-oriented specification, and then by documenting the architecture of a system at two levels.

In each architecture domain, it abstracts logical specification from physical specification, using the terms in this table.

Generic meta model

Generic entities

Business

Applications

Technology

Required behaviors

Services

Business Services

IS/Application Services

Platform/Technology Services

Logical structures

Logical Building Blocks

Function & Roles

Logical Application Components

Logical Technology Components

Physical structures

Physical Building Blocks

Organisation Units & Actors

Physical Application Components

Physical Technology Components

 

This table shows how chapters 34 to 41 distinguish the two levels of specification using different terms.

ADM phase

34 Meta model

36 Deliverables

37 Building Block

39 Enterprise Continuum

41 Enterprise Repository

B, C and D

Logical components

Architecture Definition Document

Architecture BBs

Architecture Continuum

Architecture Repository.

E

Physical components

Architecture Roadmap

Solution BBs

Solutions Continuum

Solutions Repository.

 

Drawing the table above helps people to see that TOGAF draws a coherent and consistent division between the two levels of system specification.

Being an EA framework, TOGAF focuses attention on the abstract level.

EA as applied system theory -8- The systems that EA governs

A system contains or employs actors that play roles in regular processes. E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach agreed aims. E.g. the group of actors hired to play in the orchestra.

If management is about hiring and motivating the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).

System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.

This is the last of 8 articles on EA as applied system theory.

 

What does business/IT alignment mean?

Providing the business with the discrete event-driven systems the business needs to work more effectively and efficiently.

(Rather than deploy whatever IT products IT service providers convince managers to buy.)

To this end, architects all over the world apply general system theory every day.

 

Design activities that reflect system theory

Architects apply system theory concepts when, for example:

·         Bounding systems (and system components) behind system-environment interfaces.

·         Abstracting a system description from an (observed or envisaged) operational system.

·         Defining goals for a system to be designed.

·         Defining system outputs or services that will meet or serve the goals

·         Defining required behaviour and roles before structure and actors

·         Defining external interfaces before internal composition structures.

·         Defining business processes to deliver required outputs or services.

·         Defining state variables maintained (data created and used) by business actions

·         Defining inputs and business processes to maintain system state.

·         Assigning actors/components to perform required roles/actions.

 

Design sequences that reflect system theory

In the operation of a business system, events trigger actors to play roles and perform behaviours.

All EA frameworks are based on two presumptions made explicit in the UML 2.1 standard

·          “all behavior in a modeled system is ultimately caused by actions executed by so-called “active objects

·         “behavioral semantics only deal with event-driven, or discrete, behaviors”  UML 2.1

 

Formalising a social system into a business system typically follows this sequence:

·         Define discrete events (including service requests) to be recognised and processed

·         Define the necessary behaviours and group them into roles

·         Hire, buy or build actors (active objects) and deploy them to act in the defined roles.

 

The starting point is always to encapsulate the internal actors and behaviour (hide the internal view)

And to start from the events/ service requests actors must respond to (the external view).

The same principle applies at every level and in every domain of EA.

You always start with the services / event responses you want from the system of interest.

 

Four design sequences can be found in architecture frameworks:

·         Logical to physical: Abstract specification before concrete implementation

·         External to internal: required services/products before internal processes and roles/actors/components

·         Behaviour to structure: services and process sequences before roles/actors/components.

·         Business to technology: human actors before computer actors.

 

There are reasons to deviate from these sequences in practice, and to “reverse engineer”

But methods for governing design and implementation against a specification usually start with these presumptions.

 

A general process for rationalisation of a messy system estate runs as follows:

 

Analyse the baseline

1.      Catalogue baseline actor/components (organisation units, functions, roles or actors).

2.      Abstract the discrete services provided by those baseline actor/components.

3.      De-duplicate baseline-provided services.

 

Design the target

1.      Define required services

2.      If need be, design processes to deliver the required services.

3.      Assign required services and/or process steps to logical interfaces, functions or roles.

4.      Change, hire, buy or build physical actor/components to realise logical interfaces and perform processes.

 

Conclusion

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

The application of system theory in a business system description is testable.

An operational business system can be tested for conformance to a system description.

And if the system is put into production, it will be further tested throughout its run-time operation.

 

In all the ways discussed, EA can be seen as applying the core ideas of general system theory.

It describes systems in a way more compatible with general system theory than with sociological systems thinking.

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