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

Summary

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

This article continues.

Read the whole article...

Comments

Comment on this article

Visualisation of Relationships

Summary

This is a recurring theme. Systems-thinking, systems engineering and architecture description are primarily concerned with identifying and managing the important relationships with other things in the world. They are relationship-centric rather than object-centric.

It is often hard for folks used to using flat 2D diagrams produced in PowerPoint or Visio to appreciate the potential power behind relationships. Flat diagrams don't make it easy to explore nearby related things and because they're limited in terms of the parameters you can apply, for example weightings to indicate proximity or importance, you often need many versions or different cut-sets of the bigger one.

Having a means to store objects and relationships and represent them allows you to explore beyond the immediate vicinity to assess impacts and dependencies. There is a very nice example on TED.com of the use of relationships by ecologist Eric Berlow which is helped by the ability to visualise them in a nice way. This could be achieved using a architecture description repository although the visualisation is probably not as good. There are bound also to be other tools that are good at representing and filtering relationships - possibly harking back to the thoughts for visualisations of information sources using Resource Description Format (RDF). With Linked Data gaining ground you need only to be able to see that relationships or dependencies exist but to be able to see what affect the strength of that relationship has. The Mk1 Human Being is highly adapted to visual input and stimulus so it is perhaps not surprising that being able to see and manipulate visually is a powerful tool in identifying context and assessing impact.

Read the whole article...

Comments

Comment on this article