Ten principles of system description

This page is published under the terms of the licence summarized in the footnote.

This paper explores the concept of systems as abstractions.

You may well struggle with what follows, because I have struggled to write it.

Do skip this if you are eager to get to discussion of abstraction in practice.

Contents

Systems as abstractions. 1

Concrete directly performable system descriptions. 2

Abstract soft system descriptions. 3

Ten principles of system description. 4

Systems as abstractions

All systems descriptions are abstractions; and the level of abstraction is chosen by the describer.

Process flow charts and role definitions are were invented by humans to help us describe some part of what happens in the world.

A process or a role documented by an architect is an abstraction from what is observable in a real operational system.

The process flow chart is a type, or model, for a sequence of actions that occur in reality – for an instance you can observe happening over time.

The role definition is a type, or model, for an actor in reality – for an instance you can observe performing actions.

A system description is usually a partial and flawed abstraction from the operational system it describes.

Actors and activities in the real world are usually much more elaborate than types in idealised system descriptions, and do not always fully conform to types.

Nevertheless, what an architecture framework calls “the architecture” is primarily what is documented in some kind of system description.

Reverse engineering

This means moving from an operational system - observable in the real world - to one or more abstract system descriptions (views if you like) of that one operational system.

Which descriptions can fairly be called “architecture descriptions” depends on what architecture standard or method you use.

Forward engineering

This means moving from an abstract system description to one or more operational systems that can realise that one system description.

There is no one “right” way to design a system, to transform required system behaviour into a required system structure.

There are, rather, endless trade-offs between competing forces on the design.

Having agreed the input and outputs of a system to be designed, there are infinite possible internal system structures.

So, it is possible to change (“refactor”) the internal structure with no effect on the required behaviour.

So, the general notion is that a system description is independent of the concrete forms of components, be they man-made or organic.

Real-world operational systems and abstract system descriptions are in some ways inseparable, and yet necessarily separate.

If sociologists, biologists and software engineers are to share a truly general system theory, then all three need to separate system description from operational system, and separate description time from run-time.

Concrete directly performable system descriptions

Are there system descriptions that exactly represent an operational system? Descriptions that are not partial and flawed abstractions?

Run-time models

In System Dynamics, the operational system is nothing more or less than a performance of the system description.

The operational system is itself a runnable model of a real world system that is observed or envisaged.

Description of biological entities

Most cells of your body contain your genome, encoded in DNA.

It contains the entirety of your hereditary information.

This information can be viewed as an directly performable set of instructions for building and operating the organism that is you.

The following analogy may be drawn.

Biology	Analogy
Cell nucleus (the size of a pin point)	Book holder and reader
Genome	Book
23 Chromosomes	23 Chapters
48 to 250 million nucleobases per chromosome	48 to 250 million letters (A,C,G,T) per chapter.

Nucleobases are nitrogen-containing organic compounds.

They naturally form base-pairs and stack on one another to create the helical structure of DNA.

Your genome contains about 3.2 billion nucleobases.

(Note that this decomposition stops short of the atoms and elementary particles.)

Description of software systems

An enterprise’s many computers contain many application programs.

Each is documented in code as a structured collection of directly performable instructions.

A similar analogy might be drawn.

Computer with operating system	Book holder and reader
Application program	Book
10 Components (aka packages)	10 Parts
1,000 Modules (aka classes)	1,000 Chapters
10,000 Operations (aka methods)	10,000 Paragraphs
100,000 Directly performable instructions	100,000 Sentences

A large enterprise may employ 1,000 or more business-specific applications.

Add to those all the generic applications (word processors, email, etc.) and platform applications (operating systems, database managements systems, etc.) and it is conceivable that an enterprise may employ 3.2 billion directly performable instructions.

(Note that this decomposition stops short of words, characters and binary digits.)

Could an architect work with a system description with 3.1 billion elements? Of course not.

The larger and more complex the operational system, the more levels of abstraction are needed in architectural system descriptions.

That is a basic assumption in enterprise architecture frameworks like those published by The Open Group and John Zachman.

Abstract soft system descriptions

A biological entity is definitively described by its genome.

A computer program is definitively described by its code.

But these descriptions are too large and complex for discussion of the whole system, so humans formulate more abstract descriptions.

Others kinds of physical and human organisations have no definitive hard-coded directly performable description.

These organisations can only be called systems in so far as we able to describe them as systems in abstract descriptions.

You can find systems almost anywhere you look.

An operational system exists anywhere you can encapsulate a part of world and describe it as having systemic properties.

There are infinite nested and overlapping system descriptions you could abstract from the world, and therefore potentially infinite corresponding operational systems.

You cannot contemplate all the infinite operational systems that could be described.

You cannot even contemplate all those whose description might give you some benefit.

You can contemplate only a tiny number of the possible systems.

However, people do continually build novel and reasonably correct descriptions of the world in the form of new system models.

Especially in models of human and computer activity systems.

They do it in order to understand them, build them or direct them in some way.

All description is abstraction.

Given a part of the world that is almost a completely disorganised shambles, you can describe it as system by focusing only on what is systematic – however slight – using abstraction to hide the rest.

And you can describe your perception of something as a system.

A partial and subjective description of something as a system is often called a “soft system”.

People use the same term to mean that their system-of-interest involves human components.

Enterprise architects do deal with soft systems in both senses a) the system descriptions are subjective abstractions, and b) the operational systems contain humans.

Peter Checkland’s soft systems methodology (of which Brian Wilson teaches a variation) uses soft system descriptions to capture different views of a current or potential business from different stakeholders.

This approach is usually applied to a human organisation, but can be applied also to more mechanical systems.

Having gathered several soft systems, the architect has to architect an operational system.

Builders need a coherent system description.

Testers need objective test criteria.

Architects may have to compromise between soft systems, and seek agreement to one system description.

But even a single, agreed, system description remains a partial and flawed abstraction from the operational system.

And in this sense, every architectural system description is a soft system.

In practice, the term soft is used with many and various implications, as the table below indicates.

Hard	Soft
Objective	Subjective
Reality	Description
Unchanging	Adaptable
Stable	Evolving
Machinery	Society
Computer	Human

Some system thinkers are especially interested in the adaptation and/or evolution of human social groups.

There will be more on adaptation and evolution in a moment.

Ten principles of system description

People all too readily add the word "system" after another word with little or no clarity about what the system is or contains.

The ambiguity hinders discussion that follows and leads to sloppy thinking rather than systems thinking.

1. For you to call interacting components a system is to imply a system description.

If an operational system exists in the world, then a corresponding abstract system description has been or can be formed.

(Similarly, a “set” of concrete objects in the world is inseparable from the “type” that defines a set member.)

2. For you to formulate a system description requires a system theory.

You can’t rightly call something a system if you have no theory of what kinds of property a system can have and how to describe them.

(Concepts to be found in system theory include input types, output types, process/rule types, component types and variable types.)

3. An operational system is defined by the descriptive types it conforms to.

You can call anything a system provided it has the properties of a system that your system theory defines.

This usually means you can observe it as exhibiting the types and rules found in a given description (be it abstract or detailed).

4. An operational system is a subset of reality.

The operational system is only a small part of what you observe in the world.

It is no more and no less than whatever parts of reality correspond to the system description of interest to you.

The remainder of what you observe in the world is irrelevant to your view of what the system contains.

You may define "a human system" as including the microbes essential to digestion of food.

Another may define "a human system" without the microbes; so, there are two differently bounded systems.

The microbes are internal components of your "human system", yet external entities to another’s "human system".

5. Every architectural system description is a soft system.

An architect’s system description is a flawed and partial abstraction from an operational system.

(It may be called a highly complex and polythetic type.)

6. A system description needs a describer.

A system describer is an actor or process that produces or uses a system description.

The system describer could be the DNA replication that produces a genome, or human.

Architects are system describers of course.

Why say describer? Why not go along with second-order cyberneticians and system thinkers who speak of the observer?

First, because humans may not be involved.

The describer of a biological entity is the process by which that entity’s genome was created.

A general systems theory ought to be applicable to biological entities that exist as operational systems but are never observed.

Second, because a human can describe a system before observing it in reality.

You may hold a description in your mind, but if you want it to be shared and discussed by other people with any certainty, it will have to be documented for them.

7. Descriptions must be documented to be demonstrably verified or validated.

The match of an operational system to its system description implies:

· verification by inspection of the description and/or

· validation by testing of the operational system against the description.

It is the describer who defines what the system-of-interest is.

The term "system" is often a noise word in discussion.

Here, the system-of-interest is whatever the describer describes as a system.

It is defined by systemic types and rules, which have been formulated or abstracted by evolution or people.

8. An operational system must be matchable to a system description.

An operational system is real, exists, it is distinct from any system description.

But to call it a “system” is to imply it has systemic properties that are describable.

The universe is a continuously unfolding process.

Our sun and its orbiting planets exist, but to call them a "system" implies there are systemic properties that are describable - if only in the mind.

You imply this can be done when you call it “the solar system”.

9. One real world entity can be many systems.

To different observers’ intents and purposes, the one named entity is different systems at the same time.

The solar system can be severally described.

Described by the International Astronomical Union, it excludes Pluto and a few large celestial bodies in the asteroid belt, which are all called planets in other descriptions.

So to different observers, one named entity, the same area of the universe, is different systems.

IBM is many systems at once.

It is a stable system in a highly abstract description (name, profit/loss amount).

At the same time, it progresses through many system generations in more detailed descriptions of its structure and processes.

Notice that in describing a named entity as a system, one description can be stable while another is changing.

10. Higher level abstract system descriptions usually live longer than lower-level ones.

That is assumed and necessary in enterprise architecture frameworks like those published by The Open Group and John Zachman.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 18/12/2015 18:45

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org