Tag Archives: systems of systems

What is complexity?

I’m part of the LSCITS project where LSCITS stands for ‘Large Scale Complex IT Systems’ and we have been having discussions about what is meant by ‘complexity’. Some argue that the term complexity should be reserved for complex adaptive systems, systems which are dominated by emergent behaviour. Others argue that ‘conventionally’ engineered systems can also be complex in that their non-functional characteristics and (sometimes) their functional behaviour cannot be predicted. This is particularly likely when we create systems by integrating different parts (often other systems) which are independently developed and managed. In such cases, it is practically impossible to predict how the characteristics of one system will interfere with the characteristics of others.

We suggested that ‘complex’ and ‘complicated’ were not the same. A complicated system is one that is understandable in principle although, in practice, the effort involved may be so great that it is not understandable in practice. This was my own view at one time, but I’ve now changed my mind and think that there is no practical difference between a complex and a very complicated system.  This position has emerged from musings on the roots of complexity.

Some systems are inherently complex – we cannot deduce their properties by a study of their components; we cannot predict the consequences to changes to these systems. System behaviour and properties are emergent and non-deterministic. I believe that such inherent complexity stems from the fact the there are dynamic, dependent relationships between the parts of the system. These relationships evolve in time and according to stimuli from the system’s environment. New relationships may be created and existing relationships may change. As a consequence, deterministic modelling techniques cannot be used to make predictions about such systems although statistical approaches may be used in some cases.

As soon as you consider the people who use a system to be part of the system, you have dynamic, dependent relationships between components in the system so I argue that all large, socio-technical systems can be considered to be complex systems.

There is also another aspect to complexity – what might be called epistemic complexity. This relates to the predictability of system properties when changes are proposed. If you don’t have enough knowledge about a system’s components and their relationships, you cannot make predictions about it, even if, in principle, that system does not have dynamic dependent relationships between its components. Therefore, I argue that large complicated systems are also complex systems when it is practically impossible to acquire the necessary knowledge to understand the system.

This means, of course, that complexity is not just a property of the system but also of the system observer. We have all encountered system experts who know about some system and can make changes to it in a reliable way. Their knowledge is hard to articulate and when they are no longer available, someone taking over the system may find it impossible to develop the same level of understanding. Therefore, what was a complicated system has become a complex system.

Where is all this leading – who cares?

Well, I think it is important to emphasise that complexity isn’t simple. Striving for a simple, universal definition of complexity isn’t really going to get us anywhere.

If we are to try and manage complexity we need a toolbox of theories and methods to do so. To give an example, if you think about dynamic dependencies between components, formal methods of computer science don’t really help. However, if you think about epistemic complexity, they may be very useful indeed as they allow us to state ‘truths’ about a system – filling in our knowledge about that system.

The notion of dynamic, dependent relationships may also be useful in helping us manage complexity. By developing a better understanding of such relationships (e.g. through socio-technical analysis of organisations), we may be able to change the type of these relationships from dynamic to static and hence reduce the complexity of the system.

As I said, complexity isn’t simple so there’s lots of scope for disagreement here.


Filed under LSCITS

Enterprise architecture frameworks – TOGAF and MODAF

I’ve been looking at Enterprise Architecture frameworks such as TOGAF and MODAF as people have suggested that some of the work we have done on responsibility modeling relates to these. I can see a tenuous link but that’s not what this post is about.

EA frameworks strike me as the brontosauri of the methods world. They have a view that the world can be architected starting with the business and then (somehow) defining and enterprise architecture that tries to tie together all of the systems in that business. It’s all about top-down reductionism and nowhere is the inherent messiness and unpredictability of the world taken into account. They assume that you can set up stable business goals and use these as a driver for defining your enterprise and hence defining the set of systems that you need.

Well I have worked in several enterprises and have, like almost everyone else in these enterprises, have considered the stated business goals as a joke. Business goals are statements that may make senior managers feel good when presenting the business but they are so far removed from organizational reality that they don’t strike me as a good basis for defining a long term vision for systems in an enterprise. Problems with business goals are:

The personal goals of the people in the organization are not necessarily aligned with the business goals. People are driven by personal motivations (goals is too strong a word) and mostly couldn’t care less about the business goals. Why should they – in many large organizations, senior management are concerned with the shareholders rather than the people in the organization. The difference in rewards between the highest and lowest salaries in many enterprises is obscene and people are treated as disposable commodities.  At best, the people in an organization will ignore the business goals; at worst, they will actively oppose changes driven by these goals as they see them as undermining their ability to do their job.

Changes in the world are so significant that they overwhelm business intentions. Business goals can only be established on the assumption that there is some degree of stability in the world so that a plan derived from the goals can be executed. However, all of the evidence that we have suggests that no such stability exists. Things happen – collapsing banks, lack of credit, changes of government policy, new disruptive technologies, natural disasters, etc. that  mean plans have to be torn up and rethought.  A top-down, goal-driven view of the world is simply untenable.

This means, IMHO, that the basic premise of these EA frameworks is fundamentally flawed.

And, then we come to the complexity;  TOGAF is described in an 800-page book  and suggests literally tens of different views of the enterprise architecture that should be produced. No mention of the costs and difficulties of keeping these up to date or attempting to demonstrate/maintain consistency. Clearly the costs of introducing these EA frameworks are huge – and how can the benefits be assessed?

I used the term ‘brontosauri’ deliberately to describe these methods. Huge and the last of a line that is doomed. I have some doubts about agile methods in general but, when it comes to modeling, I’m in complete agreement. Just Barely Good Enough is definitely the right approach – agile modeling is immature but definitely the first of the mammals that will take over from the dinosaurs.

Leave a comment

Filed under LSCITS