Dave Cliff wrote a short piece on the ‘flash crash’ on 6th May 2010 when there were extreme and unexpected fluctuations in US stock prices (link here when its online). While there remains some uncertainty about the cause of this, a very significant factor was interactions between the high-frequency algorithmic trading systems used by brokers to trade stock, sometimes several hundreds of times per second. Some emergent behaviour in this collection of systems led to the dramatic price fluctuations.
This is an example of the kind of problems that arise from system complexity where there are dynamic relationships between the components in the system. Understanding and at least partially managing this type of complexity is, in my view, one of the major challenges that faces the systems engineering community. Work we can draw on comes from the ‘systems of systems‘ (SoS) community but I don’t think that the collection of systems that led to the flash crash should really be called a ‘system of systems’.
I always think of a system according to Peter Checkland‘s notion when he developed Soft Systems Methodology as something that is purposeful, with the implication that the system serves the purpose of some individual or organisation. Therefore, a system of systems is primarily an organisational notion – some organisation puts together systems (which may be inside or outside that organisation) to do something that’s useful to the organisation.
But the interacting algorithmic trading systems that led to the flash crash are owned by different organisations and they are probably systems of systems in their own right. They serve purposes of the different owners (and these may be different although in this case they probably have the common underlying purpose of enriching their owners) and they only cooperate because they have to. The owners are often competing and may be mutually hostile. Each system jealously guards its own information and may change without consultation with any other systems.
I don’t think it makes sense to call this collection of systems a ‘system of systems’. Rather what he have here is a ‘coalition of systems’ where systems work together, sometimes reluctantly, because it is in their mutual interest to do so. Coalitions of systems are not explicitly designed but come into existence when different systems interact according to some agreed protocols. Like political coalitions, there may be (but doesn’t have to be) hostility between the members and the coalitions may break down if one system changes so that it no longer fits.
For those of us working in complex systems engineering, we need to think about coalitions of systems as well as systems of systems. We can’t design dependability into the coalition as there is no overall design authority; nor can we control the behaviour of individual systems. Maybe we have to be thinking about dependable protocols where the protocols are not just concerned with defining how the systems can interact but also act as a regulator ensuring that interactions are within some acceptable bounds? Perhaps we should also be thinking about containment (analagous to the concrete around a nuclear reactor) to ensure that when things go wrong, the damage that can ensue is limited.