System of Systems (SOS) is An Arrangement Not a Type

by Nic Plum on Friday 12 November, 2010 - 12:05 GMT

Tags: arrangement • boundary • classification • systems engineering • systems thinking • type

A System of Systems is defined by a system boundary that includes several systems and which conforms to the properties and behaviour of the type 'system'

There are a lot of references to 'system of systems' or 'SoS' and a lot of merchants riding on the back of inappropriate use of this term (so in this sense SoS ought to be Snake Oil Supplier!). Why does this matter and what are the impacts of sloppy use of the term?

What Type of Thing is a System of Systems?

As far as anyone has been able to establish a System of Systems is itself a 'System'. In other words it is of type 'System'. It is not of type 'System of Systems'. This is important because it means that general statements, properties and behaviours of a system are true for System of Systems. It also means that you shouldn't force or represent a binary choice between system and system of systems because you're still talking about 'system'. There are extra considerations for a system of systems but these are simply repetitions of the general approach for 'system' for the boundary of the system-of-interest which in this case includes several systems.

Even if the system so formed is accidental what we mean is that it had no designed man-made purpose (it is not a 'man-made system'). This doesn't mean it isn't a system. The characteristics of any system are that it has emergent behaviour and is stable (at least in human timescales) all of which need no predefined purpose or designation of control authority.

If a System of Systems isn't a System we'd have many problems. We'd need to identify how it differs from a system and we couldn't use methods that represent systems, such as architecture frameworks, to represent a system of systems as it is likely that the necessary constructs wouldn't exist.

System of Systems is an Arrangement

A System of Systems is an arrangement of systems to form a system. It is defined by the system boundary that encompasses these systems to describe this system-of-interest. It has a type = 'system'. As a system it must conform to the definition in terms of (emergent) behaviour and properties of the type 'system'. Emergence isn't a differentiating property of a System of Systems. It does have some unique properties over the base / parent 'system':-

it is wholly composed of systems
each of the component systems must be capable of independent existence/operation from the SoS

All too often it is the fact that we didn't identify this boundary or have any body being responsible for this system that causes the problems - we probably have lower level authority but no one has the responsibility for the emergent behaviour and integration of this arrangement of systems. That's when the trouble begins.

What is Appropriate Use of the 'SOS' / 'System of Systems' Term?

First, a few premises. Systems Engineering is a risk management tool or methodology - we use it to reduce risk in a development or programme to an acceptable level. In Systems engineering we therefore pick, choose and prioritise what we spend time on - which is often why we look at relationships, boundaries, structure, behaviour and exchanges at high levels.

There is nothing special about a system being formed from systems - we've had these for many years and have well established methods within systems engineering to manage these. Examples of such arrangements include submarines or any large platform such as an aircraft or satellite. As systems they have emergent behaviour, are complex etc. It is not therefore the arrangement or composition that matters.

There is, however, a small subset of systems of systems where there is limited or no control over the system as a whole - there is therefore no management or control authority and limited or no scope to mitigate. This is the worry. It is not therefore the arrangement but the control or management authority that matters - everything else is business as usual. It would therefore be more accurate to classify these as 'Unmanageable Systems' - far more accurate than using the broad spectrum general 'SOS' term which mostly includes the manageable systems we cope with quite happily.

The Effect of Misuse of the SOS Term and Woolly Thinking

The term embeds a viewpoint. It's a repeat of the classic system vs subsystem (my subsystem might be your system if we're at different levels in the management of the system). You wouldn't use 'System of Sub-Systems' even if a sub-system is itself a system as is so often the case with large complex systems.

It fragments the SE profession by creating an artificial distinction by arrangement - which is actually irrelevant to the problem to be managed.

Misuse of the the term encourages people to believe or act as though there is a new type of thing. You see this everywhere - we have 'System of Systems Engineers' even though the scope or remit is exactly the same as for a 'Systems Engineer'. We must always use the most generic type for which the statement holds true, not arbitrarily pick a subset as this enforces a belief that what is being said isn't also true for 'system'.

An example of the danger, on Wikipedia - System of Systems Engineering

System-of-Systems Engineering and Systems Engineering are related but different fields of study. Whereas systems engineering addresses the development and operations of monolithic products, SoSE addresses the development and operations of evolving programs. In other words, traditional systems engineering seeks to optimize an individual system (i.e., the product), while SoSE seeks to optimize network of various interacting legacy and new systems brought together to satisfy multiple objectives of the program

Immediately the author has set out his/her stall on the premise that the two are different and emphasises the split further by allocation 'system engineering' to traditional and monolithic and System of Systems Engineering to something new and uniquely tricky. Unfortunately 'sexy' or 'tricky' attracts money so there is a vested interest in differentiating yourself from something that has existed for many years. This is pretty typical and dangerous in that it implies that the approach and practices are not those used for a system or systems engineering - this is just not true. A system of systems is simply a specific case that applies to an arrangement. This isn't to say that it doesn't become more difficult but often the failure is in identifying that you have this arrangement and managing it, not the techniques that you use.

The confusion between type and scope or arrangement manifests itself in document names. If we're writing a Systems Engineering Management Plan or a Safety Case, both types of document, for a system that is formed from a set of systems then how should this be named? If we're being systematic and separating types from arrangement it should be something like:

Document Type. System Name (where this identifiably maps to a defined system boundary)

e.g. SEMP. Thribble Gobbler

Inevitably, however, someone embeds the arrangement within the document type and we get things like 'System of Systems Engineering Management Plan' - and immediately you start to believe that you've got a different type of document (you haven't).

A lot of this might seem to be picky but you have to be precise and accurate. It's an example of the point raised in George Orwell's 1984 where language was used to constrain thinking. In this case we have an example of the sloppy use of language fragmenting thinking. Bizarrely this might even be reductionism at work.

Suggestions

Always test by substitution of 'system' for 'system of systems'. If the statement remains true use the more generic 'system'.
Keep document names short and separate type of document from the scope of application (system of interest).