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
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
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
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
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
Executing this strategy is also rarely straightforward. It requires the persistence and determination to build sustainable components, optimised for long term value and use
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.)
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?) !
??API & Integration Architect, CS Teacher
7 个月Peter Zelenak
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
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.
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.