TOGAF as an application of
general system theory
TOGAF® ArchiMate® are
Copyright
2017 Graham Berrisford. One of about 300 papers at
http://avancier.website. Last updated 15/05/2019 20:23
This paper is one of three that parallel each other.
1. Introducing general system theory ideas
2. EA as an application of general system theory
3. TOGAF as an application of general system theory
This paper shows The Open Group Architecture Framework (TOGAF) contains much that is based on system theory ideas.
If you want longer discussion of the same
system theory ideas then read paper 1 instead.
If you want a more general discussion of the
relevance of those ideas to EA then read paper 2
instead.
Contents
The generality of system ideas
1 Passive and
activity systems
3 Abstract and
concrete systems
4 Dynamics (the
primacy of behavior)
8 System
archetypes, design patterns
13 Hierarchy,
systems of systems
14 System bounded
as a black box
17 System
mutation (generation change)
The term “system” appeared 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”
In “General System theory: Foundations, Development, Applications” (1968), Ludwig von Bertalanffy wrote:
“There exist models, principles, and laws that apply to generalized systems or their subclasses, irrespective of their particular kind, the nature of their component elements.” Bertalanffy
Business systems evolved over millennia by formalising the roles and rules, messages and memories, of social systems.
This table compares core concepts in one business system design method 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/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/information entities 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. |
Many general system theory concepts are taken for granted in today’s enterprise and software architecture methods.
This table defines some general system ideas found in TOGAF.
|
General system ideas |
Business system ideas |
Defined in terms of activities |
|
Goal |
Business
goal |
A testable target for the outcome(s) of
business activities. |
|
Behavior |
Business
service |
A contract defining the request for and result/outcomes
of required activities. |
|
Process |
A behavior that
sequences activities. |
|
|
Abstract
structure |
Role |
A group of services offered and/or
activities performable by an actor. |
|
Business
function |
A group of services offered and/or activities
performable by an organisation. |
|
|
Concrete
structure |
Actor |
A person (or machine) who
realises a role by performing activities in processes. |
|
Organisation |
A managed unit that realises a function’s services
by performing activities in processes. |
The “Information Age” began when humans started using software to digitise the messages and memories of business systems.
Software
architecture modularises an application (system) into components (subsystems).
Compare the tables above and below.
|
General system ideas |
Software system ideas |
|
|
Goal |
Application
requirement |
A testable target for the outcome(s) of
application activities. |
|
Behavior (use case) |
Application
service |
A contract defining the request for and
result/outcomes of required activities. |
|
Application
process |
A behavior that
sequences activities. |
|
|
Abstract
structure |
Application
interface |
A group of services offered and performable
by an application component. |
|
Concrete
structure |
Application
component |
A deployable unit that realises an
interface’s services by performing activities in processes. |
Passive structure: a collection of inter-related things
or parts, which can be acted on, but does not act.
E.g. a table, a database.
System: an activity system, rather than a passive structure.
It is an island of orderly behaviors in the ever-unfolding process that is the universe.
The behaviors
maintain or advance the system state and/or produce outputs.
E.g. the solar system, an organism, a
software system, a choir, a tennis match.
Relevance to TOGAF?
TOGAF is concerned with the human and computer activity systems of a business.
These business systems have evolved over millennia by formalising social activity systems.
They feature business roles and processes that create and use information in the form of messages and memories.
The messages and memories contain passive data structures.
The actors play their roles by performing activities when triggered to do so by messages received and memories retained.
A closed system is one modelled without reference to its wider environment.
An open system is one modelled as consuming inputs from its environment.
Relevance to TOGAF?
TOGAF is concerned with business systems that are open - they consume input and produce outputs.
Bear in mind that the inputs and outputs to be described depend on the concerns of interest.
|
Inputs
to IBM |
Outputs
from IBM |
|
Oxygen |
CO2 |
|
Electricity and food |
Heat |
|
Money from customers and investors |
Salaries and dividends |
|
Raw materials and components |
Concrete products |
|
Questions and requests |
Answers and documents |
|
Raw information |
Integrated or advanced information |
“A system is independent of the concrete substance of the elements (e.g. cells, transistors, people, etc).” L & K
Abstract system: 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.
Concrete system: a system that runs in reality.
A real world entity that can be tested
as meeting an abstract system description – well enough.
Abstract systems are realised by concrete systems; concrete systems realise abstract systems.
|
Abstract system |
Conceptual |
A set of roles and rules (the
logic or laws actors follow) |
The stickleback mating ritual |
|
Concrete system |
Physical |
Actors
playing the roles and acting
according to the rules |
Countless pairs of stickleback. |
Relevance to TOGAF?
To exercise change control over changes to systems, there must be description of those systems.
TOGAF abstracts system descriptions from baseline systems (observed) and target systems (envisaged).
Its “architecture definition” is collection of descriptive artefacts, often including graphical models in which diagrammatic symbols substitute for words.
The definition is detailed only in so far as stakeholders need it to be.
Abstraction
of logical description from physical description
Abstraction is probably the hardest concept in system theory to grapple with.
This 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 shows how TOGAF distinguishes two levels of specification using different terms.
|
ADM phase |
Meta model |
Deliverables |
Building Block |
Enterprise Continuum |
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.
Abstraction
of services from internal structures and behaviors
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 classifies and relates different viewpoints used in system description in TOGAF.
|
System
viewpoint |
Behavior (activities, events) Activities in sequence from trigger
to result. |
Active
structure (actors, entities) Groups or performers of related
activities. |
|
|
External |
Service A
discrete transformation from input/request to output/result. TOGAF
Business service, IS service, Technology service |
Interface A
collection of services made accessible to clients TOGAF,
Interface, Service portfolio |
|
|
Internal |
Logical specification
or type |
Logical behavior A
specification of a behavior. TOGAF
Value stream, Business scenario, Process |
Logical active structure A
group of activities that a real world entity can perform. TOGAF
Business function, Capability, Role, Logical (data, application, technology)
component |
|
Physical realization
or instance |
Physical behavior
(locatable in time) A
performance of a behavior TOGAF
(n/a) |
Physical active structure (locatable in
space) A
real world entity with the ability to perform activities. TOGAF
Organisation unit, Actor, Physical (data, application, technology) component |
|
Abstraction
varieties used in TOGAF
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
in the Enterprise Continuum
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 |
Abstraction
of meta system from system
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 |
TOGAF |
|
Meta system |
System design methodology |
EA framework |
|
System description |
System design |
Enterprise repository · Requirements repository · Architecture repository · Solutions repository |
|
Regular behaviors in the real world |
Live information system Real world entities and events |
Deployed solutions |
Behaviors are processes performed by parts, often called actors or agents, that play roles in a system.
Behaviors change the state of the system or something in its environment.
Relevance to TOGAF?
The US government’s EA Framework declared its aims as: “common data and business processes”, “information sharing” and “new and improved 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).
In the popular book “EA as Strategy”, Ross, Weill and Robertson said.
"Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (“EA as Strategy” 2006).
Ross etc. used the grid below to promote the idea of standardising and integrating business processes across the enterprise.
|
Core business processes |
||
|
High
integration |
Coordinated |
Unified |
|
Low
integration |
Diversified |
Replicated |
|
|
Low
standardisation |
High
standardisation |
In short, the purpose of EA has always been to
optimise, integrate, improve and extend business processes – which produce results or outputs of
value to some interested parties.
TOGAF defines these behaviors in the form of “value streams”, “business scenarios”, “business processes” and “service contracts”.
TOGAF applies “the primacy of behavior” 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.
·
Phase C starts by defining information system/application services that business
processes require from business application components.
·
Phase D starts by defining platform/technology services that business
applications require from technology components.
TOGAF
has long employed modelling techniques that exemplify general system theory
ideas
·
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 behavior.
·
A
functional decomposition hierarchy is
structural view of those actions (more stable than the organisation’s
management structure).
·
A
business process model is behavioral (sequential) view of the same actions.
Deterministic means that a system, in a given state, responds to a given input or event in a pre-determined way (be it natural or designed).
Relevance to TOGAF?
TOGAF is concerned with business processes that are regular, determinate or repeatable (as Ashby said of cybernetics in 1956).
Determinate means the responses of a business (to events and service requests) are determined by business rules applied to system state or memory.
To monitor and direct the state of the entities and activities it cares about, a business runs in a feedback loop with its environment.
1. It receives a message carrying new information about business entities and activities
2. It refers to its memory, holding the last-recorded state of those entities and activities
3. Depending on the state, it “chooses” whether to update its memory and/or send messages to direct external entities and processes.
TOGAF includes
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 further detailed before the systems can be implemented.
Chaotic means disorderly, with no regular or repeated pattern.
Relevance to TOGAF?
EA is about orderly processes, not chaotic ones.
It is rarely concerned with the long-term trajectory of state changes to business state variables.
E.g. the value of a revenue-per-month variable might be stable, increase steadily or change chaotically.
Coupling is the relating of systems (as subsystems) in a wider system.
The actors in a system can interact by forces, energy, matter or information, the last of which is the main interest here.
Relevance to TOGAF?
TOGAF is concerned to integrate related systems to the benefit of the enterprise.
There are many patterns for the design of systems.
There are design patterns for how system interactions are organised or controlled
The table below identifies some contrasting design patterns.
|
Centralised organisation |
Distributed organisation |
|
in one
place or component. |
between places
or components. |
|
Hierarchy |
Anarchy or Network |
|
Hub and Spoke |
Point-to-Point or Mesh |
|
Client-Server |
Peer-to-Peer |
|
Fork or Orchestration |
Chain or Choreography |
Relevance to TOGAF?
TOGAF says little about design patterns – other than the III-RM.
The reason it mentions that particular design pattern is to explain how EA can address the vision of The Open Group.
That vision being: “to achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”
Their mission being: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”
Emergence primarily
means the appearance of outputs, effects or state changes that arise from
coupling subsystems in a wider system.
Relevance to TOGAF?
TOGAF is concerned to couple subsystems to produce emergent properties to the benefit of the business.
Exceptions occur when actors do not complete actions expected of their roles.
Relevance to TOGAF?
TOGAF does not address exception handling.
Complex
is a term with scores of different
definitions.
Relevance to TOGAF?
TOGAF is concerned with software systems, arguably the most complex systems designed by mankind.
And with systems that involve roles played by human actors, who are arguably the most complex systems in nature.
Holism means looking at something in terms of how its parts join up (e.g. bicycle and rider) rather than dissecting each part.
But how you identify the parts and join them up is only one perspective out of countless possible ones.
Relevance to TOGAF?
TOGAF takes a holistic view; it looks to integrate business systems to the benefit of the wider enterprise.
It 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.
With his background
in biology, von Bertalanffy wrote of a concept he called organicism.
Organicism: the idea that systems are describable at multiple hierarchical levels.
A system may be decomposable into subsystems, and/or composable (with others) into larger systems.
Atomic element:
an element that is not further divided in a description.
Note that atomic system actors may be complex
entities in their own right, and may play roles in other systems.
Relevance to TOGAF?
TOGAF is said to view the enterprise as a system, or system of systems.
This does indeed explain what TOGAF strives for, though integration of all systems is impossible in practice.
TOGAF is concerned with large
businesses that suffer the diseconomies
of scale.
These businesses are not so much
systems of systems as containers of systems, each relevant to a “bounded
context”.
TOGAF defines enterprise as a recursively decomposed structure of business functions/capabilities.
Each coarse-grained function/.capability provides several services
E.g. below is
hierarchical description of IBM.
Services offered
· Cloud services
· Mobility services
· Networking services
· Resiliency services
· Security services
· System services
· Technical support services
· Business operation services:
· Application development & innovation services
· Business Analytics & Strategy
· Big Data & Analytics Services
· Cloud business services
· Cognitive consulting & solutions
· Digital operations services
· Enterprise application & alliances
· Finance
· Risk & fraud services
· Global process services
· Finance & administration process services
· Human resources & learning services
· Lending solutions
· Managed marketing services
· Recruitment process outsourcing.
Customer domains
· Business operations
· Collaboration
· Commerce
· Content management
· Customer service & CRM
· Finance
· Human resources
· Marketing & sales.
Technology domains
· Analytics
· Cloud computing
· Cognitive computing & AI
· IT infrastructure
· IT management
· Mobile technology
· Security
· Software development.
At this highest level of descriptions, a business appears relatively simple and stable.
At
the lowest levels of decomposition and specialisation, a business may be
relatively complex and change weekly or even daily.
Whatever level an architect works at, they choose what is “atomic” to them, and typically leave the internal design of atomic elements to others.
“Closed and Open Systems: Every living organism is essentially an open system. It maintains itself in a continuous inflow and outflow…” Bertalanffy.
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.
System boundary:
a line (physical or logical) that separates a system from is environment
It encapsulates the system’s internal
structures and behaviors – encloses
them in input-process-output “black box”.
If you expand the system boundary then external events become internal events, passing between subsystems.
If you contract the system boundary then internal events become external
events, crossing that boundary.
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.
Relevance to TOGAF?
TOGAF is concerned with systems definable as a “black box”.
The encapsulation and specification of systems by their interfaces is a fundamental tool.
A business maintains itself in a continuous inflow from suppliers and outflow to customers.
· 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.
Adaptation is an ambiguous term, it can mean either system state change (as in homeostasis) or system mutation.
Read Complex Adaptive Systems (CAS), for detailed discussion.
However, as that paper points out, a system that adapts by changing state might be a SAS (simple adaptive system) rather than a CAS.
And a system that adapts by mutating (or a “learning organisation”) might be called an EME (ever evolving entity) rather than a CAS.
A
continuously mutating entity (or ever unfolding process) is not a system in the
ordinary sense of the term.
Because its behavior is not describable and
testable as regular, or determinate, or reproducible.
Relevance to TOGAF?
See the next entries on system state change
and system mutation.
“Systems concepts include: system-environment boundary, input, output, process, state….” Principia Cybernetica
System state: the current structure or variables of a system, which may change over time.
A concrete system’s property values realise property types or variables in its abstract system description.
System state change: a change to the state of a system, which may be of several kinds.
Relevance to TOGAF?
TOGAF is much concerned with the data that records the state of things in a business and its environment.
And with the business roles and processes that create and update that data.
It is important to distinguish system state change
(within a generation) from system mutation between system generations.
Like every other
discrete entity, an activity system has a discrete life time, which can be long
or short.
Relevance to TOGAF?
TOGAF is much concerned with system mutations made under change control.
It designs, plans and governs the migration from baseline systems to target systems.
See the next section.
Self-organisation can mean various things, including growth
and self-regulation (homeostasis).
In
sociology, it often means something different – the process by which actors who
play roles in a system define or redefine the roles and rules of that system.
Read Foerster’s ideas on second order cybernetics more detailed discussion of self-organisation.
Meta system: a system that defines a system or changes
it from one generation to the next.
In nature, the processes of sexual
reproduction define a new organic system generation.
In design, human actors define the
next generation of a machine or business system.
Relevance to TOGAF?
TOGAF does not focus on processes that actors are expected to define themselves, are ad hoc, or are performed without regard to business data.
It focuses on when, where and how regular business roles and processes create and use business data.
It is a meta system to the business systems that it observes and envisages.
It helps an enterprise to change those business systems in response to external and internal forces.
This table presents a version of the WKID hierarchy.
|
Wisdom |
The ability to respond effectively to
knowledge in a new situation. |
|
Knowledge |
Information that is accurate or true
enough to be useful |
|
Information |
Meaning
created or found in a structure by an actor |
|
Data |
A structure of matter/energy in which
information has been created or found |
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.
Information flow
(aka message): physically, a signal passed
from sender to receiver, logically, a communication.
Information state (aka memory): see “state”
above.
Relevance to TOGAF?
TOGAF focuses on business roles and processes that create and use information.
"EA
as Strategy” (2006) 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.
EA is concerned with inputs and outputs that are information, and with materials accompanied by information.
"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 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 |
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” 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.
A designed concrete
entity (like a motor car or a symphony) cannot behave as a system until after
it has been envisaged as a system.
Its reproducible behaviors are a response to the interests or goals of one or more living entities.
Designed systems have goals given to them by system owners, sponsors and others.
Natural system: a
system that runs before it is envisaged as a system.
Its repeated behaviors
evolve without externally-defined drivers or goals.
E.g. a solar system, weather system or
biological organism.
The solar system evolved without goals.
Its outcomes (the stable orbits of the planets) are not goals, they are the unintended consequences of evolution.
Designed system: a system that is envisaged 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, any other business system..
Relevance to TOGAF?
TOGAF is concerned with designing and changing systems to meet business goals.
The “Information Age” began when humans started using software to digitise the messages and memories of business systems.
Software
architecture modularises in application (system) into components (subsystems).
Compare the concepts one finds in software architecture and in general system theory.
|
General system ideas |
Software system ideas |
|
|
Goal |
Application
requirement |
A testable target for the outcome(s) of
application activities. |
|
Behavior (use case) |
Application
service |
A contract defining the request for and
result/outcomes of required activities. |
|
Application
process |
A behavior that
sequences activities. |
|
|
Abstract
structure |
Application
interface |
A group of services offered and
performable by an application component. |
|
Concrete
structure |
Application
component |
A deployable unit that realises an
interface’s services by performing activities in processes. |
TOGAF is about designing, planning and governing “transformational changes” to business systems.
Business systems are describable and testable using system theory ideas.
And when the system is put into production, it will be further tested throughout its run-time operation.
Design activities
that reflect system theory
TOGAF applies system theory concepts when, for example:
· Abstracting a system description from a baseline system (observed) and a target system (envisaged).
· Bounding systems (and subsystems or components) behind system-environment interfaces.
· Defining goals for a system to be designed.
· Defining system outputs or services that will meet or serve the goals.
· Defining processes and roles needed to deliver required outputs or services.
· Defining interfaces in terms of services required and provided.
· Defining data (state variables maintained) created and used by business processes.
Service-orientation
In the operation of a business system, external actors request services.
So, the starting point is to define those service requests – to encapsulate the internal actors and behaviors.
You start with the services or outputs
you want from the system of interest.
TOGAF applies this principle to the Business, Applications and Technology domains
Design sequences that reflect system theory
Four design sequences can be found in TOGAF
· Logical to physical: Abstract specification before concrete implementation
· External to internal: required services/products before internal processes and roles/actors/components
· Behavior 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.
System
reengineering
TOGAF follows
general process for rationalisation of a messy system estate, which
runs as follows:
Analyse the baseline
1. Catalogue baseline actor/components (organisation units, functions, roles, applications, technologies).
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.
In all the ways discussed, TOGAF can be seen as applying the core ideas of general system theory to business systems.
It describes systems in a way more compatible with general system theory than with social systems thinking.
Contrarily, as a meta system, TOGAF 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.