Complexity and simplicity are friends

How many applications is too many? 100? 200? 1,000? 7,000?

I have worked for many different organisations with different numbers of applications. Whatever the numbers, though, they all had one thing in common: somebody, somewhere thought that we had too many applications.

I have always found this belief puzzling. We build applications because we believe that they have value (otherwise we wouldn’t put so much effort into writing those business cases). We celebrate our success when we implement them. And then we record their existence in our great big list of applications, lament that we have so many, and wish that we had fewer. Is there any other field of endeavour where what we have built moves so quickly from asset to liability (whatever our accounting rules say)?

I believe that people worry about the number of applications in their estate because of an inherent fear of complexity, and because the number of applications is a visible signal of complexity. They perceive that their technology is becoming too costly, too slow and too risky, and they also see that these factors rise in sync with the number of applications. The more stuff they have, the harder it seems to get.

I believe that this is a mistaken perception. Complexity, whether expressed through number of applications or some other metric, does not have to correlate with increased cost, friction and risk. Sometimes it does, but that is because we often design, build and run technology badly. And, despite the vast quantities of badly run technology in the world, running technology badly is not mandatory: when we run it well, complexity is manageable. It may even be an advantage.

Last week, I argued for the value of simple ideas, explained well. It might seem that, this week, I am arguing for the opposite. However, I believe that complexity and simplicity are compatible: indeed, I believe that simplicity is essential for managing complexity. To see this, let’s look at the difference between two strategies for dealing with growing technology estates: simplification and simplicity.

Simplification is a strategy pursued by many large enterprises, typically those with large application estates. The idea is straightforward: we have too much stuff; we should have less stuff; let’s identify the stuff we don’t need and get rid of it. We will measure our success by reducing the number of applications from 5,000 to 3,000, or from 500 to 300, or whatever arbitrary number seems attractive. We will run a large programme, funded over several years, to pursue this strategy.

Unfortunately, execution is rarely straightforward. It usually turns out that the reason we have all this stuff is that people use it. Organisations pursuing simplification strategies often lament that, ‘we never turn anything off,’ without recognising that that is probably because the thing that they would rather turn off offers some kind of value. Furthermore, it turns out that people keep building new applications as fast as old ones get decommissioned. That’s because computer systems are useful, and because we have only just begun the work of getting them to do all of the things that they could possibly do.

The idea of simplification as a programme contains fundamentally flawed beliefs: that complexity is avoidable; that it is possible and desirable to have a technology architecture which only consists of a few components; and that the net trend in number of systems needed to run a business is downwards. Everything we have experienced in the digitisation of organisations over the last several decades tells us that these beliefs are wrong.

Simplicity is a less commonly pursued strategy, or at least a strategy which is less frequently made explicit. If it is pursued, it is often driven by engineers and architects making choices which are not always explicit to their sponsors and stakeholders. The idea is more subtle: complexity is inevitable; we will always have more components; we do not know ahead of time exactly how our components will be used; we will design them with well defined interfaces and behaviour so that they can survive in unknown contexts. We will measure our success through ease of use, reliability and speed, and we will pursue this strategy as a practice (not a programme).

Executing this strategy is also rarely straightforward. It requires the persistence and determination to build sustainable components, optimised for long term value and use, in the face of pressure to optimise for short term feature and function. However, the benefits of this strategy are profound and proven. It also has the advantage that it reflects reality: the inherent complexity of computing; the value of architectures containing multiple components; and the net trend towards building more systems to do more work.

Currently, business sponsors are more likely to back simplification programmes than the practice of simplicity. I do not blame them for this. They are responding to what they can see, and those of us in the technology field have not done a good job of explaining that they can only see part of the picture. If we work harder, I believe that we can show that complexity and simplicity are compatible.

(Views in this article are my own.)