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 19/01/2021 12:52

 

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

On system as descriptions abstracted from reality. 1

What’s wrong with the ISO/IEC 42010 standard? In short…... 1

What’s wrong with the ISO/IEC 42010 standard? At length…... 1

Conclusions and remarks. 1

 

On system as descriptions abstracted from reality

 

Reality exists; IBM exists; our knowledge of them also exists as a biological phenomenon.

We animals abstract knowledge from what we observe and envisage.

On the nature of description (recap)

All written here about systems is based on the idea that systems are patterns we abstract from physical phenomena.

This reflects the outcome of a famous debate between two mathematicians about the meaning of descriptions.

Does geometry address a thing directly (Frege), or only selected features of it that are describable by geometry (Hilbert).

Our answer to this question is firmly in the Hilbert camp.

Activity system thinking doesn’t address the whole of a thing.

It addresses only those features of a physical entity that can be represented in an abstract system description.

 

Activity systems thinking

Abstract systems

<create and use>             <represent>

Systems thinkers <observe and envisage> Physical systems

 

The systems of interest here are activity systems in which actors perform activities to advance the state of the system.

Systems as models of reality

Von Bertalanffy first introduced the idea of a cross-science general system theory in the 1940s, and later wrote.

 All scientific constructs are models representing certain aspects or perspectives of reality.” (1968)

 

Many systems thinkers (see first chapter) urged us to separate the model from the entity that realizes it.

Meaning the system is a model (in mind or writing) of some observable or envisageable phenomena.

The model represents what may be called a physical system.

 

System theory

Abstract systems

<create and use>              <represent>

System thinkers <observe and envisage> Physical systems

 

pattern is a thought, design or other phenomenon that is “regular or repeatable”.

An abstract system is a pattern. E.g. a score of Beethoven’s fifth symphony

A physical system is an instance or embodiment of an abstract system. E.g. one performance of the symphony.

Systems as types

What does an abstract system description express? The types to be instantiated in a physical system.

What does a physical system embody or realize? The types expressed in the abstract system description.

 

Every system description is a class or type

It may conceivably be embodied or realized in many physical instances.

And in addition to the three concepts in the triangle, there is a fourth.

That is, the physical entity that realizes a physical activity system.

 

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

 

In writing, we can create large and complex types, composed of smaller simpler primitive types.

We can create an architectural model of a system far beyond any model we can hold in mind.

A system model may typify:

·       actors (structures in space that perform activities) by defining roles

·       activities (behaviors over time that advance the state of the system or its environment) by defining rules.

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

IBM can realise countless different abstract systems in parallel, some of which may be in conflict, and realize different systems over time. 

Conversely, countless real-world entities or situations may realise the same abstract type, such as “a commercial business”.

 

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

 

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.

Four particular system theories

W Ross Ashby, writing on cybernetics, distinguished entities in nature from the abstract systems they realise. 

In cybernetics, a system is an abstraction, a theory or model of how an entity or “real machine” behaves, or should behave.

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 (or populations) that interact and affect each other.

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.

Russel Ackoff, a writer on management science, spoke of abstract and concrete systems.

His abstract system is a description or model of how a concrete entity behaves, or should behave.

 

Ashby’s cybernetics

System Dynamics

Checkland’s Soft systems methodology

Ackoff’s system theory

Abstract machines

<create and use>          <represent>

Observers <observe and envisage> Real machines

Stock and flow models

<create and animate>                     <represent>

Modellers <observe and envisage> Interacting quantities

Business activity models

<create and use>                <represent>

Observers <observe and envisage> Human organizations

Abstract systems

<create and use>            <represent>

System thinkers <observe and envisage> Concrete systems

What’s wrong with the ISO/IEC 42010 standard? In short…

 

The ISO/IEC 42010 standard is for the architectural description of software-intensive systems.

 

“This International Standard takes no position on what constitutes a system... The nature of systems is not defined.”

“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?

                                                                     

The main 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

 

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.

 

Some say “An Architecture Description describes the Architecture of a System”.

But that is to speak loosely, and the sentence is tautologous.

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.

 

The triangle can generalized for enterprise architecture thus.

 

Enterprise architecture

Architecture Definitions

<create and use>            <represent>

Architects <observe and envisage> Business systems

 

Suppose all human memories and recordings of an architecture definition were destroyed.

Every copy and version in mental, written and other physical media were deleted.

Then that “type” would disappear from the universe.

 

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,

What’s wrong with the ISO/IEC 42010 standard? At length…

 

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.

 

There is a many-to-association between the two concepts – shown on the right-hand side of our triangle.

 

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.

 

Every documented system description is a class or type that may conceivably be embodied or realized in many physical instances.

The description can be a large and complex type, composed of smaller types and primitive simple types.

 

Describer(s)

One system description

Many system instances

Many physical entities

Composer(s)

A symphony score

Many symphony performances

Many orchestras

Business architect(s)

A set of business roles and processes

Many businesses in operation

Many business actors

Software engineer(s)

A program

Many program executions

Many computers

Game designer(s)

The rules of “poker”

Many games of poker

Many card schools

 

In each example above, the description can be embodied or realized in many instances - by many real-world entities.

The description is a concept, a type or typifying assertion; and conversely, a type or typifying assertion is a concept, is a description.

 

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 its, 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?

 

A type is a concept, is a description. A description is a concept, is a type.

A type/concept/description can be contained in a mind or in a document.

A type/concept/description only exists in a form (mental or documented) created by a typifier/conceiver/describer.

So ISO/IEC 42020 terms:

 

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

Revising the ISO/IEC 42010 triangle so it makes sense

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.

Conclusions and remarks

This article is a supplement to this description theory.

Where this general triangle is used to relate describers and descriptions to what is described.

 

Episteomology

Descriptions

<create and use>              <represent>

Describers <observe and envisage> Phenomena

 

It revises the concept graph in ISO 42010 to match this triangle.

 

 

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.