Complexity and simplicity are friends
Photo credit: Harrison Leece via Unsplash

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

Himanshu Tiwari

Senior Delivery Manager @ Material | Business Analytics * Decision Intelligence | Data Tech Delivery Solution * Change Management

7 个月

It’s all in the (execution) : (How ?) Simple Became Complex Or Complex Became Simple (How?) !

回复
Karel Husa

??API & Integration Architect, CS Teacher

7 个月
回复
Paul Riley

Head of Architecture (Colleague Channels) at Lloyds Banking Group

7 个月

Having done something similar the headache is that we assume less is better. Some of the oldest architectures in the world relied on large monolithic applications - we've spent large amounts of time splitting these into ever smaller increments where now even the definition of what an application is becomes difficult (when does a micro service expand to become an app?). We should instead be looking for platform consistency as a route to simplification not blunt tools like number of apps. Trouble is that's more difficult to track and much more subjective

Mohammed Brueckner

Strategic IT-Business Interface Specialist | Microsoft Cloud Technologies Advocate | Cloud Computing, Enterprise Architecture

7 个月

I agree with your points on complexity and simplicity in technology estates. Complexity doesn't necessarily increase cost, friction, and risk. However, it's important to consider the psychological impact of complexity on users, such as "analysis paralysis." User experience (UX) design can make complex systems more accessible. Emerging technologies like AI i all its facets can automate processes, improving efficiency. Continuous learning for IT professionals is also crucial. So we are left with the fact that only embracing both complexity and simplicity will lead to greater efficiency and innovation.

Niurka Quinteros

Digital transformation leader optimizing application modernization using AI, Containerization and Hybrid Cloud Master’s candidate at Brown University

7 个月

The desire to "Marie Kondo" IT systems and make them simpler is a common wish. The semantics of simplicity in IT architecture refer to the fundamental concepts and principles that guide the creation of simple yet effective architectures. As technology advances, systems become increasingly complex as we implement features like modularity, flexibility, scalability, and fault tolerance. This can make simplicity a challenge. Some important areas to be mindful of include: Documentation and business value of applications - Ensuring applications are well-documented and aligned with strategic business goals. Inventory of line-of-business (LOB) utilization and app sponsors - Maintaining a comprehensive understanding of application usage and key stakeholders. Evaluating if applications are contributing to technical debt - Assessing whether applications have accumulated complexity over time that impacts long-term viability. By proactively addressing these areas, organizations can make informed decisions about their application portfolio, prioritize investments, and ensure the long-term business value of their IT assets, despite the inherent complexity of modern systems.

回复

要查看或添加评论,请登录

David Knott的更多文章

社区洞察

其他会员也浏览了