Introduction to enterprises as systems
Or rather, as containers of systems
Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 21/02/2018 11:19
The role of enterprise architects is to observe baseline systems, envisage target systems, and describe both.
Classical system theory gives us insights into a wide variety of disciplines.
It leads towards theories of information and communication.
It leads towards answers to philosophical questions about description and reality.
And helps us to make sense of what enterprise architecture is about.
Enterprise architecture is about:
· Open (rather than closed) systems, which deliver services to consumers.
· Designed (rather than natural) systems, which need analysis and design effort.
· Purposeful (rather than accidental) systems, which have measurable objectives.
· Information (rather than material) processing systems, which formalise messages and memories.
Enterprises are social entities in which actors exchange information.
Business activity systems can be seen as formalised social systems.
The actors perform activities according to messages received and memories retained.
The contents of memories and messages are defined as data structures composed of business data types.
A meta system is one that observes, envisages or describes the roles and rules of another system.
An enterprise architecture function is a meta system for changing an enterprise's business systems – under change control.
The social impacts of changes are usually addressed in parallel, by a business change team.
Some say "enterprise architecture regards the enterprise as a system, or a system of systems."
What does that mean? And is it true?
People do often point to an institution (such as a church or cooperation) and call it a "system".
They might mean merely "it contains things that are interrelated in some way or another" (which may be said of the entire universe).
Or they might mean, a tad more specifically, "it is a social entity in which people receive directions from above and communicate with each other."
An enterprise architecture function takes a holistic view of business activities that create and use business data.
Architects take a cross-organisational and strategic view of the enterprise’s business systems.
They strive to standardise and integrate discrete business systems.
However, seeing the whole enterprise as one system is a vision rather than a reality.
Partly because different functions/capabilities have their own domain-specific languages.
And partly because large businesses suffer the diseconomies of scale.
Generally, an enterprise is as many different activity systems as you are able to describe and test
Calling an enterprise a system without reference to a particular system description means next to nothing.
Not only can an enterprise be conceptualised as countless different systems.
But also, those systems may be nested, overlapping, disparate, cooperative or antagonistic.
E.g. IBM is a corporation that employs many actors who interact in many activities.
There are infinite ways to divide IBM into systems.
Every system description is a highly selective partial description of IBM.
There are countless disparate activity systems (research, production, sales, accounting, corporate reporting).
Systems in different regions or divisions may duplicate, conflict or compete with each other.
Its countless disparate actors and activities cannot be joined up in one holistic description, and tested as a coherent whole.
IBM may be seen as the same entity today that it was last year – as is made evident in its name and in legal documents.
But IBM is surely not the same system today.
Simply pointing to IBM and calling it a system has no useful meaning.
Because IBM can be represented in countless system descriptions, depending on the perspective you take of it.
You can only say "IBM is a system" with reference to a particular system description, against which the behavior of IBM can be tested.
Architects identify, design, plan and govern changes to business activity systems - under change control.
They describe a system in a way that can be used to test an operational system, and analyse the impact of changes.
They describe a system from several viewpoints.
External views help us scope or bound the structures and behaviors of interest to stakeholders.
E.g. An interface (aka boundary, service portfolio in TOGAF) encapsulates one or more internal active structures (building blocks in TOGAF).
A service (as may be defined in a discrete service contract) encapsulates one or more internal behaviors.
Structure views help us understand and describe how things in the system relate or connect to each other.
Behavior views help us understand and describe how things in the system act and change over time.
E.g. Structure/behavior contrasts include: actor/activity, entity/event, object/operation, stock/flow, function/process, and capability/value stream.
Logical views help us abstract essential facts from more physical descriptions, and from the concrete reality of an active system.
Note that external views may be seen as logical views.
Physical views help us translate between logical views and the concrete reality of an active system.
Note that some elaborate the logical/physical distinction into four levels (conceptual/logical/physical/real) or even six levels (as in the Zachman framework
This table classifies the views in relation to each other.
System view point
Behavior (activities, events)
Activities in sequence from trigger to result.
Active structure (actors, entities)
Groups or performs related activities.
A discrete transformation from input/request to output/result.
Defined without reference to internal behaviors.
A directory or facade where services can be found.
specification or type
A specification of a behavior.
E.g. value stream, scenario, process, use case, service, procedure
Logical active structure
A group of activities that a real world entity can perform.
E.g. a business function or capability, role, component type, class.
realization or instance
Physical behavior (locatable in time)
A performance of a behavior.
Physical active structure (locatable in space)
A real world entity with the ability to perform activities.
E.g. organisation unit, employed actor, deployed component, object.
Note that while people do sometimes name instances of physical active structures, they rarely identify instances of physical behaviors in the run-time system.
For more, see papers on "ENTERPRISES AS SYSTEMS" on the "System Theory" page at avancier.website.
All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.
If you find them helpful, please spread the word and link to the site in whichever social media you use.