Implications for system architecture and ISO/IEC 42010
Copyright
2017 Graham Berrisford. Now a chapter in “the book” at https://bit.ly/2yXGImr. Last
updated 23/02/2021 16:27
This article is a
supplement to this description theory.
It reviews a concept graph in ISO/IEC42010 and revises it match our
epistemological triangle.
Contents
Implications
for the ISO/IEC 42010 standard
What’s wrong
with the ISO/IEC 42010 standard? In short…
What’s wrong
with the ISO/IEC 42010 standard? At length…
Many systems thinkers have urged us to
separate descriptions
from described things. Our abstract system is a model (in mind or writing) that
represents a physical system we observe or envisage as a phenomenon in reality.
|
System theory |
|
Abstract systems <create
and use>
<represent> System
thinkers <observe
and envisage> Physical systems |
|
Ackoff’s
system theory |
|
Abstract systems <create and use>
<represent> System thinkers <observe and envisage> Concrete systems |
W
Ross Ashby, writing on cybernetics, distinguished entities in nature from
the abstract systems they realise. His system is an abstraction, a theory
or model of how “real machine” behaves, or should behave.
|
Ashby’s
cybernetics |
|
Abstract machines <create and use>
<represent> Observers <observe and envisage> Real
machines |
Jay
Forrester (a professor at the MIT Sloan School of Management) was the
founder of System Dynamics. He defined a system as a set of stocks (resources
or populations) that interact and affect each other by increasing or decreasing
the amounts they contain.
|
System Dynamics |
|
Stock and flow models <create
and animate>
<represent> Modellers
<observe and envisage> Interacting quantities |
Peter Checkland
promoted a “soft systems methodology” for the design of business activity
systems. He said different observers may perceive different systems, some in
conflict, in any one human organization or other entity.
|
Checkland’s Soft systems methodology |
|
Business activity models <create and use> <represent> Observers <observe and envisage> Human organizations |
In addition to
the three concepts in the triangles above, there is a fourth. An abstract system is a pattern (a thought,
design or other phenomenon that is regular or repeatable) that contains and relates types to be instantiated in a
physical system. An abstract system may be embodied or realized in many physical systems. And last but not
least, we come to the physical entity that realizes a physical system. This table contains an example.
|
Stickleback mating ritual |
|
|
Abstract
system (roles, rules, variable types) |
The
type, a model of the ritual |
|
Physical
system (actors, activities, variable values) |
An
instance of the ritual |
|
Physical
entities |
A
pair of sticklebacks, nest and eggs |
|
Describer(s) |
One abstract type |
Many physical instances |
Many physical entities |
|
Composer(s) |
One symphony
score |
Many symphony
performances |
Many orchestras |
|
Business
architect(s) |
One set of
business roles and rules |
Many businesses
processes |
Many business
actors |
|
Software engineer(s) |
One program |
Many program executions |
Many computers |
|
Game designer(s) |
The rules of “poker” |
Many games of poker |
Many card schools |
An abstract system does not have to be a
perfect model of a physical entity’s behavior; only accurate enough to be
useful. We can test that an entity realises an abstract system to the degree of
accuracy we need for practical use.
In writing, we can create a very large and complex type, composed of smaller simpler types. We can create an architectural model of a system far beyond any model we can hold in mind. The model may typify
·
actors (structures in space that perform
activities) by defining roles,
·
activities (behaviors that advance the state of
the system or its environment) by defining rules, and the
· system’s
state (structures changed by activities) by defining state variables.
|
System architecture |
|
Logical Roles, Rules, Variables <create
and use>
<represent> System
architects <observe
and envisage> Physical Actors, Activities, State |
Ashby pointed out that countless system
descriptions (mental or documented models) may be abstracted from one
substantial real-world entity or situation. some of which may be in
conflict. Conversely, countless real-world entities or
situations may realise the same abstract system type.
In short, the relationship between physical entities and abstract systems is many-to-many.
· One physical entity (e.g. a card school) may realise countless abstract systems (poker, whist, pizza sharing).
· One abstract system (the game of poker) may be realised by countless physical entities (card schools).
The ISO/IEC 42010 standard is for the architectural description of software-intensive systems. The concern here is the way the standard relates three concepts in 1-1 associations.
|
The ISO/IEC 42010 standard |
|
1 Architecture Description <is expressed in> <identifies> 1 Architecture <is exhibited in> 1
System |
If an architecture is a documented description of a thing, then in ISO 42010 terms, it is an Architecture Description. If it is a described thing, then in ISO 42010 terms, it is a System observed in reality or envisaged in the mind. If it is neither one nor the other, then where is it?
To say “a weight describes the weight of a thing” is tautologous. To say “a type describes the type of a thing” is tautologous. To say “an architecture description describes the architecture of a system” is tautologous. It is really to say either “a description describes the description of a thing”, or else “a description describes the thing of a thing”.
More accurately: “An architecture
description sets out concepts or properties that a system that will embody.”
That is all we need to discuss. So better, revise the concept graph
thus.
|
System architecture |
|
1 Architecture Description <create and use> <represents> N Architects <observe and envisage> N
Systems |
For longer and deeper analysis of ISO/IEC 42010, read on.
“For a system of interest to you, the Standard provides guidance for
documenting an architecture for that system."
“Architecture
description: work product used to express an
architecture".
“Architecture:
fundamental concepts or properties of a system in its environment embodied in
its elements, relationships, and in the principles of its design and
evolution.”
How
to distinguish concepts or properties that are fundamental from
other ones?
Are
the concepts or properties of a system different when the system is not in
its environment? What would that mean?
Where are the concepts or properties embodied?
In the Architecture? In the Architecture Description? In the System?
Surely
elements and relationships are merely instances of concepts and
properties?
Surely
principles are external guidelines for defining the Architecture, embodied
in its concepts and properties?
We can see description and reality in terms of types
and instances.
1.
a
type - concepts or properties expressed in an intensional definition.
2.
an
instance – concepts or properties embodied in an observed or
envisaged thing.
In the worlds of business and software architecture, we can see
1.
Architecture Descriptions that express and relate
architectural property types.
2. Physical systems – realized by enterprises – that embody or exhibit architectural property types in particular instances.
If the Architecture expresses and
relates property types, then it is an Architecture Description. If the
Architecture embodies or exhibits property types, then it is a System. If it
does neither then what is it, and where is it?
The existence, or potential existence, of a physical software system is not worth debating, The question that ISO/IEC 42010 raises is whether a universal system architecture exists outside of human minds and models. And a moment’s reflection suggests not.
Different people may have different ideas of what they see as the “fundamental concepts or properties” of a given system. There is no single, universal, concept of that system’s “architecture” outside of an architectural description we make – in mind or on paper. Moreover, the concept on paper is likely to be more complete, consistent and coherent than any held in any architect’s mind.
There is no metaphysical system architecture out there, which we can find and express in an architecture description.
To say “a weight describes the weight of a thing” is tautologous. To say “a type describes the type of a thing” is tautologous. To say “an architecture description describes the architecture of a system” is tautologous. It is really to say either “a description describes the description of a thing”, or else “a description describes the thing of a thing”.
More
accurately: “An architecture description sets out concepts or properties that a
system that will embody.” That is all we need to discuss. So better,
revise the concept graph thus.
|
System architecture |
|
1 Architecture Description <create and use> <represents> N Architects <observe and
envisage> N Systems |
Suppose
we posit a metaphysical Architecture – not found in a model/description. Which
of several mental and documented models/descriptions does it correspond to? How
do we know what the Architecture contains? What use is it? It is redundant - a
pointless piece of nonsense.
Oddly
Since the standard does not take any view of what a system
is, it can be applied to any designed thing. Since it does not say which
concepts and properties are fundamental to architecture, it can be applied to
any documented design. In fact, it can be applied to anything whose documented
description must address the concerns of stakeholders. You can change
all "architecture" to "design" without affecting its
practical application. And generalize its
triangular relation thus.
|
Design |
|
Designs <create and use> <represent> Designers
<observe and envisage> Designed things |
Read
on for a longer version of the argument above.
In the worlds of business and software architecture, we can see
1.
Architecture descriptions that express and
relate architectural property types.
2. Physical systems – realized by enterprises – that embody or exhibit architectural property types in particular instances.
Our triangle can be used to describe the situation thus..
|
System architecture |
|
Architecture
Descriptions <create and use> <represent> Architects
<observe and envisage> Physical
systems |
The ISO/IEC 42010 standard posits a third thing called “architecture” related by 1-1 associations to the first two. Compare with the standard with cartography. What would you put in place of the questions marks.
|
ISO/IEC 42010
triangle |
Cartography |
|
1 Architecture Description <is expressed in> <identifies> 1
Architecture <is exhibited in> 1
System |
1 Map <is expressed in> <represents> 1 ???????
<is exhibited in> 1 Territory |
What is the “architecture
description” in ISO/IEC 42010?
Our mental models are relatively fragile and fuzzy, and they fade. In writing, we can create an architectural model of a system that is beyond any model we can hold in mind. It can be larger, more complex, consistent and coherent, as well as more stable and persistent.
ISO/IEC 42010 says it is a: “work product used to express an architecture".
OK, it is a documented form of the architecture that is formed from (but cannot be completely or perfectly remembered in) one or more architects’ minds.
What does a system architecture
description express? The types to be instantiated in a physical system.
What does a system
embody or realize? The types expressed in an architecture description.
Who conceives the
types and translates them from a fragile mental form into a documented form?
The system architects.
What is the
“architecture” in ISO/IEC 42010?
ISO/IEC 42010 says it is a: “<system> fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution"
This definition starts off referring to descriptive property types, as expressed in an architecture description.
It then shifts to a physical entity - the embodiment of those types in an observable system – and throws in some constraints on the design activity.
So, is it a Platonic ideal? Or is it real, a copy of the architecture description in some mental form?
If the architecture is ethereal, the concept of the architecture, then how could it exist before architects conceived it?
Platonic ideals are “universals” - eternal
and invariant types like “height” and “ellipse” – they never change.
There is no such universal “architecture”,
since it must change every time the “architecture description” that identifies
a “system” is changed.
Which means there are infinite architectures
for the identified system!
The concept of a Platonic ideal architecture is baffling; it adds no meaning to the description and reality of a system; it is redundant.
If the architecture is real, then
where is it? And when is it created?
Before architects
start work - there is no system or architecture – just some concerns about a
vast, indescribable and incomprehensible enterprise.
Surely the architecture gradually emerges from architects’ incomplete, fragile and fuzzy mental models of what they envisage.
Architects collate and consolidate those mental models into the form of a documented architecture description.
In this view, the architecture is one or more mental models – encoding a set of
property types in a private bio-chemical form.
And the architecture
description is a documented model – encoding the same set of
property types in a public verbal form.
Two problems with this view.
Mental models can be incoherent, fragile and transient. Does the architecture disappear when the architect who conceived it forget it, or their mental models shift over time?
Several architects can contribute to creating one description of the same system, none holds the whole description in mind. To posit a mental model “architecture” in 1 to 1 correspondence with a documented “architecture description” is incredible. Which of the architects’ heads holds that complete description? What if different architects hold different mental models? What if one architect holds the whole description in mind, then another architect changes the documented description?
Q1) What does the architecture contain?
A1) A complex type, an integrated and coherent set of property types (in one or more mental models).
Q2) What does the architecture description express?
A2) A complex type, an integrated and coherent set of property types (in a documented model).
Q3) What does the system instantiate, embody or realize?
A3) A complex type, an integrated and coherent set of property types.
You might say:
· The architecture <consists of> architectural property types envisaged by architects.
· The architecture description <expresses> that architecture.
· The system <instantiates, embodies or realizes> that architecture and that architecture description.
Or else remove the redundant “architecture” and say:
· The documented architecture description <expresses> the mental architecture description envisaged by architects.
· Both architecture descriptions <consist of> architectural property types.
· The system <instantiates, embodies or realizes> both architecture descriptions.
What is the
“system” in ISO/IEC 42010?
Despite being a standard on describing software-intensive systems, ISO/IEC 42010 does not define what a system is.
It says: “This International Standard takes no position on what constitutes a system within those domains—or elsewhere. The nature of systems is not defined….”
OK, the standard is obliged to delegate the definition of some terms, notably system, to other ISO standards. But the ISO standards don’t add up to a coherent or consistent whole. And in any case, ISO/IEC 42010 doesn’t limit itself to what other ISO standards say. Its “system” is so far generalised it could be any entity describable from different perspectives by people with different interests in it.
The standard says: “The term system is used in this International Standard to refer to entities whose architectures are of interest.”
This definition is so far generalized it can be
applied to the description of any entity of which different views may be drawn
- be it a system or not. The standard does not define the real target, which is
activity systems in which behaviors are performed by structures. So, the
standard could be applied to passive structures.
The standard says: “The term is intended to encompass, but is not limited to, entities within the following domains:”
Since the standard is not limited to the
three domains below, it does not actually define what a system is. It merely
lists some possible system type and contents, with somewhat arbitrary
distinctions like between process and procedure.
· “systems as described in [ISO/IEC 15288]: “systems that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities”;
· software products and services as described in [ISO/IEC 12207];
· software-intensive systems as described in [IEEE Std 1471:2000]: “any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole” to encompass “individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest”.”
The first recommendation is to replace the 1 “architecture” by the N architects who conceive the architecture.
|
The ISO/IEC 42010 standard |
|
1 Architecture Description <is expressed in>
<identifies> 1 Architecture
<is exhibited in> 1 System |
|
Issue: the architecture above is a metaphysical concept |
|
Revised to match our triangle
(1) |
|
1 Architecture Description <create and use>
<represents> N Architects
<observe and envisage> 1 Systems |
OK, the standard defines everything from the perspective of 1 and only 1 Architecture Description. But for sure one Architecture Description <can represent> many similar systems realisations. So, the triangle could reasonably be reshaped to match our epistemological triangle thus.
|
Revised to match our triangle (2) |
|
1 Architecture Description <create and use>
<represents> N Architects <observe and envisage> N Systems |
(What the standard omits to say is different
architects may create different Architecture Descriptions of the same System.)
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.