Coalitions of systems

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.



Filed under Uncategorized

2 responses to “Coalitions of systems

  1. Interesting post.

    Isn’t containment exactly how they responded? The SEC put in place limits on stock valuations so that the sudden drops can’t continue until some human assesses what is happening. What’s interesting is how we can separate the actors in the coalition from the operating environment. In the stock market example, I assume the environment can be modeled as anything which a system affects, e.g. stock price. But it doesn’t seem like it would always be so easy to delineate what is affected from what is affecting.

    What about “ecosystem of systems”? A coalition to me still implies that there is some intentionality from the collaboration.

  2. Just to point out the obvious…

    The real entities represented change real value only on a timescale of months. There is no value (outside pure gambling) in a virtual representation that changes value several orders of magnitude more quickly than real value.

    The answer is to force virtual evaluations to a timescale closer to real changes. Deriving a solution is simple – add a delay to only allow virtual interactions at near real timescales.

    A very simple (and real-world accurate) solution removes the problem.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s