EA as applied system theory

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 31/07/2017 14:44

 

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

Business systems evolved over millennia by formalising the roles and rules, messages and memories, of social systems.

Every business depends on sending and receiving messages, and remembering what has been done to date.

Enterprise architecture is about generational change – from baseline business system to target business system.

 

The Open Group Architecture Framework (TOGAF) contains much that illustrates the application of system theory to business systems.

The term “system” appears 1,357 times in TOGAF 9.1, including:

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

·          “Architecture descriptions are formal descriptions of a system.”

·         “Systems are built up from … building blocks [that] interoperate with other building blocks”

 

A system contains or employs actors that play describable roles in describable 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 aims they agree.

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

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 particular business systems.

The origins of EA can be traced back to IBM’s Business System Planning method, which Duane Walker reputedly started c1970.

By the 1980s, the cost and quality issues caused by “silo systems” led many to call for higher-level “enterprise architecture”.

Significant references include:

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

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

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

 

As ever more business processes were digitised, models for EA were formalised.

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

 

Ross, Weill and Robertson say EA is about “digitizing core business processes”.

That means describing business operations in terms of discrete entities and events.

·         Classifying business entities and events into types such that all instances can be treated 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.

 

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

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

Thus, EA frameworks can be seen as applying the core ideas of General System Theory to business systems.

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.

 

This table compares core concepts in TOGAF with 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

building blocks 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, using

system resources.

platform technology components.

 

The next article addresses some basic system theory principles.

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: identifying the parts of a whole, naming or describing parts without considering how the parts are related in the whole.

E.g. listing the organs and limbs of the body without relating them. Or analysing and describing the heart without reference to the lungs.

 

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.

Note: these definitions reflect what the biologist von Bertalanffy meant when he initiated the idea of a general system theory.

 

TOGAF takes a holistic view; it looks to integrate business systems to the benefit of the wider enterprise.

TOGAF version 8 (the "Enterprise Edition") borrowed a great deal from the US government’s Federal EA Framework (1999).

(In turn, FEAF drew from mainstream EA sources such as Zachman, Spewak and the NIST EA standard.)

FEAF declared its aims as: “common data and business processes”, “information sharing” and “new and improved processes”.

TOGAF also promotes the “business operating model” principle (from “EA as Strategy”, 2006) of standardising and integrating processes across the enterprise.

 “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: the idea that systems are describable at multiple hierarchical levels (as named by von Bertalanffy).

E.g. Consider the decomposition of a human body through organ, cell, organelle and molecule to atom.

Or the decomposition of software application through component, class and operation to executable instruction.

 

Note: when you study a subsystem in isolation, it is the whole system of interest to you.

When you study how two systems are related, they become parts of a wider whole.

It is 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

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

 

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

To this end, The Open Group promotes service-oriented specification – defining standards and systems as service portfolios.

TOGAF 8 extended the service-oriented specification approach already used in TOGAF 1 to 7.

"TOGAF Version 8… uses the same underlying method for developing IT architectures that was evolved [in] TOGAF up to and including Version 7.

That method was to define a system or component, an architecture domain or layer, logically, by the services it provides.

Version 8 applies that… method to the other domains of an overall Enterprise Architecture - the Business Architecture, Data Architecture, and Application Architecture, as well” http://www.opengroup.org/architecture/togaf7/index7.htm

 

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

 

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

Their mission is: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

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:.structures exist in space; behaviors happen over time.

The table below has a natural language section, followed by a section adapted from the Unified Modelling Language (UML) standard.

Structure: passive structures and actors in space

Behavior: atomic actions and processes over time

Structures that are shaped or directed by behaviors.

Entities that are created, changed and destroyed by Events.

Stocks that are incremented and decremented by Flows.

Components that perform Processes and deliver Services.

Behaviors that are performed by active structures.

Events that create, change and destroy Entities.

Flows that increment and decrement Stocks.

Processes performed and Services delivered by Components.

Structure - along the lines defined in UML

Behavior - along the lines defined in UML

A structural 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 processes.

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

 

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

 

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 is seen in many approaches to systems analysis and design.

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

 

TOGAF applies “the primacy of behaviour” principle, first to human activity systems, then to applications, then to platform technologies.

·         Phase B starts by defining required business services, and the end-to-end business processes (aka scenarios or value streams) needed to provide them.

·         (It also defines flows of materials and information between business units in a “node connectivity diagram”).

·         Phase C starts by defining information system/application services that business processes require from business application components.

·         (It also defines data created and used by business processes, using applications.)

·         Phase D starts by defining platform/technology services that business applications require from technology components.

 

TOGAF employs modelling techniques that exemplify GST concepts.

·         Structured analysis is used 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 the same actions.

 

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.

 

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.