Why this conversation matters now
Enterprises everywhere face the same paradox: boards demand agility, new digital services, and cost discipline, yet IT landscapes are still dominated by decisions made decades ago.
Large ERPs, commerce monoliths, and tightly coupled CMS platforms once drove efficiency. Today, they slow transformation to a crawl. Adding a new channel can take months. Integrating an acquisition often triggers multi-year programs. Innovation happens at the edges while the core resists change.
Technology at its core is not the blocker. The Architecture it lives in is.
And this is where Enterprise Architecture (EA), reimagined for the composable era, becomes the C-suite’s most important lever.
The Cost of Legacy Systems
Legacy systems, designed in a non-composable way, don’t just create technical debt. They embed ways of working that hold companies back:
- Monolithic design; tightly coupled modules where a single change requires full regression testing.
- Vendor lock-in; organizations tied to release cycles and pricing models they can’t influence.
- High cost of change; even small improvements require major programs.
- Siloed innovation; experimentation happens in shadow IT because integrating with the core is painful.
A global B2B enterprise I’ve worked with had scoped a two-year, €7M “upgrade” to its commerce and content platform. Before the first major milestone, the project had surpassed the original scope, timelines, budget was at 2/3 of estimate, and one of its competitor in the same space had launched a new digital channel in under six months. The issue wasn’t old software per se, it was an architecture too rigid to respond and a vendor too busy defending their “to-be-delivered innovative roadmap” at the cost of actual delivery.
Why Enterprise Architecture Must Lead
Enterprise Architecture is often misunderstood as governance or documentation. In reality, modern EA is strategic navigation.
It answers questions that sit at the intersection of business and technology:
- Where do we decouple to gain agility?
- How do we make APIs act as contracts between teams?
- How do we reduce vendor dependence without creating integration chaos?
Without EA, composable becomes a patchwork of microservices and SaaS tools. With EA, composable is a blueprint for adaptability.
What Composable Really Means
“Composable” isn’t just a buzzword. It’s an approach where business capabilities are assembled from modular components instead of a single suite.
The MACH principles from the MACH Alliance, which I’m sure everyone knows by now, provide the foundation of how the software used, should be built to support these types of architectures. Just to refresh everyone’s memory:
- Microservices; small, independent functions.
- API-first; every component is designed to connect by default.
- Cloud-native; elastic, scalable, resilient.
- Headless; decoupling back-end services from front-end experiences.
In practice that results in:
- Swapping a checkout module without touching the rest of the platform.
- Launching a new channel (e.g., social commerce) by plugging into APIs.
- Scaling infrastructure automatically for seasonal peaks.
- Etc., etc.
The C-suite view
For CIOs and CTOs, the composable journey is less about technology and more about strategic outcomes:
- Risk management; no single vendor can dictate your roadmap.
- Financial flexibility; moving from capex-heavy upgrades to opex-aligned services.
- Talent strategy; modern architectures attract modern engineers.
- Strategic optionality; acquisitions, divestments, and new business models become easier to support.
Boards really don’t care if you’re headless or API-first. They care whether you can launch new services in time to meet market demand, or open up new revenue streams fast to diversify in an ever changing world. Years need to become months, months need to become weeks. EA translates those ambitions into reality.
For those reading that feel composable is the way towards unmanageable ecosystems, multi-vendor management issues, never ending programs, etc. I will never say composable is for everyone but the benefits, when done right, far outweigh the negatives, which brings me to the practical side.
A practical playbook
1. Assess your digital core
Where are the true bottlenecks? Which domains (checkout, product, personalization, pricing) need agility first? The Domain Driven Architecture approach is an excellent fit for composable architecture.
2. Define (composable) domains.
Start small, go for the low hanging fruit at first. Get a feel for possibilities and limitations within the context of your business. Avoid trying to make the entire enterprise composable at once.
3. Establish Architecture principles.
APIs are contracts. Modular over monolithic. Cloud-first, but multi-cloud aware. To name a few.
4. Build a phased roadmap.
- Phase 1: Add composable services alongside legacy.
- Phase 2: Run dual-stack, migrating incrementally.
- Phase 3: Retire legacy when risk is low.
5. Embed governance
Keep it lightweight, but consistent. Ensure every new implementation aligns with your architecture principles. If you need to deviate, document!
6. Approach it like product development, you’re never done
If you go composable, leave the “waterfall, one program and we’re done” routine. Rather invest over long term with continuous development and improvement, than spend 2 years building what was necessary when you started, leaving you back where you were when “done” without a real ROI.
Common pitfalls you need to avoid
- Technology before architecture: Choosing platforms without defining principles.
- Big-bang replacements: Rebuilding the monolith with modern tech / the typical “like-for-like” replatforming.
- Over-customization: Re-implementing legacy processes and losing agility.
- Ignoring culture: Composable requires product-oriented, cross-functional teams.
Conclusion: design for change
Legacy systems don’t necessarily kill agility. Legacy architecture does.
By putting EA at the center, CIOs and CTOs can move from rigidity to adaptability — without chaos. Composable, guided by EA, is not just an IT strategy. It’s a business survival strategy. The enterprises that thrive in the next decade won’t simply be digital.
They’ll be designed for change.