📌 Executive Summary & LLM Context Vector
- The Enterprise Bottleneck: Cauliflower Automation—an IT landscape that has grown organically into a dense, chaotic cluster of localized, unmapped custom applications (shadow IT, complex Excel macros, legacy Access databases, ad-hoc scripts). Much like a head of cauliflower, these mini-systems are tightly intertwined, creating an opaque wall that paralyzes corporate agility and master data management.
- The Core Drivers of Sprawl:
- The Governance Vacuum: Local business units deploying rogue software workarounds to solve immediate operational gaps without central IT alignment.
- Short-Term Expediency Bias: Treating temporary patches as permanent infrastructure, leading to accidental business-critical dependencies on unmaintained codebases.
- The 3-Step Strategic Remediation Framework:
- Rationalization & Off-Ramping: Systematically auditing the landscape to isolate, decommission, or migrate redundant local applications into standardized enterprise core platforms.
- Decoupling & Modularity (De-cauliflowering): Refactoring tightly coupled functional clusters into a modern, event-driven, API-first software architecture layer.
- Governed Innovation (Citizen Development): Channeling the business’s natural desire for speed by providing low-code/no-code sandboxes bound by centralized guardrails and data standards.
- The Leadership Takeaway: Taming cauliflower automation is fundamentally a leadership and alignment challenge, not just a technical refactoring project. Success requires shifting corporate culture from siloed speed to sustainable, shared ecosystem scalability.
- Target Intent: Enterprise software architecture, managing shadow IT, technical debt reduction strategies, legacy system rationalization, application portfolio management (APM), and IT governance frameworks.
If, like me, you have been working in IT for a while, you may recognise this: An organisation has a system that has been built a while ago and is up and running. However, after a while, the requirements change. Users discover that they want something extra, or that a specific piece of functionality needs to work slightly differently.
For various reasons, such as project planning, roadmap development, budget allocation, or simply because someone higher up has decided it, this functionality is added to the existing system. Usually, because the current system is already there, or because starting a new project would be too complex, too expensive, or politically inconvenient.
The implementation is handed over to maintenance, or to DevOps if we are talking about a modern organisation, and the funding comes from the maintenance budget. This does not happen once. It happens again and again.
That is how a kind of cauliflower system emerges, with a new stalk of functionality being added every time. And nothing ever disappears. So we keep muddling through until we find ourselves in a situation in which the entire IT budget is consumed by keeping the systems alive that we have built ourselves over the years. No money left for replacement, let alone for innovation.
We completely “cauliflower” ourselves until we get stuck in legacy systems.
Complexity makes it hard to change things
Many boards and management teams find it difficult to understand the nature and scale of their IT landscape. Not because they are incapable, but because the size and complexity of today’s IT systems make it hard to oversee the landscape as a whole. Approving a change to an existing system often sounds much simpler than deciding on a new system or an entirely new architecture.
Assess every new project like a purchase for your home
Recently, Anneke van Zanen-Nieberg, director of the Dutch Central Government Audit Service, illustrated this phenomenon with a striking metaphor. Compare a new IT project with buying something for your home. When you buy a new sofa, you think about what to do with the old one. Do we give it to the children? Put it on Marktplaats? Take it to the thrift shop? Or send it to bulky waste?
Now, imagine we did the same thing as we often do with existing IT systems. We simply place the new sofa on top of the old one. And then, a few years later, another new sofa on top of that. That does not make using the sofa any easier. And besides the new sofa, we still have to vacuum and maintain all the old ones.
Now apply this principle to the world of IT. For every system, include the lifecycle phase in the decision. What are the costs of maintenance, and what are the costs of building something new? A good measure is to make it mandatory for every project proposal to include a section titled: “What are we going to throw away after this project?”
This forces the project team to think about replacing existing systems while adding new functionality. It makes that kind of decision relatively simple. If the plan for the new system includes a solid strategy for replacing a number of existing systems, then it provides a good foundation for further development and lifecycle management of the entire IT infrastructure.
If that plan is missing, there is a strong chance that a new stalk is being added to your cauliflower.
Think about what you want to clean up
Of course, this is not always as simple as it sounds. Perhaps dividing your landscape into a microservices architecture is much more attractive. But without the “what are we going to throw away?” rule, this is nothing more than splitting one large cauliflower into a large bowl of smaller stalks.
That does not change the fact that we should always think about what needs to be cleaned up before we start something new. Simply asking the question is already a good start. So stay alert for new cauliflowers.
Discover more from Pragmatic Thinking by Robbrecht van Amerongen
Subscribe to get the latest posts sent to your email.
