Why this conversation matters now
Boards want agility, new digital services and cost discipline. Meanwhile most IT landscapes are still shaped 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 takes months. Integrating an acquisition turns into a multi-year program. Innovation happens at the edges while the core resists change.
The technology itself is rarely the problem. The architecture around it usually is. And that is where Enterprise Architecture (EA), rethought for the composable era, becomes one of the most important levers the C-suite has.
The cost of legacy systems
Legacy systems that were never designed to be composable create more than technical debt. They lock in ways of working that hold companies back:
- Monolithic design: modules are so tightly coupled that a single change means full regression testing.
- Vendor lock-in: you're tied to release cycles and pricing models you can't influence.
- High cost of change: even small improvements turn into major programs.
- Siloed innovation: experiments end up in shadow IT, because integrating with the core is too painful.
A global B2B enterprise I've worked with had scoped a two-year, €7M "upgrade" of its commerce and content platform. Before the first major milestone, the project had already outgrown its scope and timeline, the budget was at 2/3 of the estimate, and one of its competitors had launched a new digital channel in under six months. The software being old wasn't the real issue. The architecture was too rigid to respond, and the vendor was too busy defending its "to-be-delivered innovative roadmap" to actually deliver.
Why Enterprise Architecture must lead
Enterprise Architecture is often seen as governance or documentation. Done well, modern EA is how an enterprise navigates. It answers the questions that sit between business and technology:
- Where do we decouple to gain agility?
- How do we make API's work as contracts between teams?
- How do we reduce vendor dependence without ending up in integration chaos?
Leave those questions unanswered and composable turns into a patchwork of microservices and SaaS tools. Answer them and you get a blueprint the business can actually adapt with.
What composable really means
"Composable" gets thrown around a lot. What it means is simple: you assemble business capabilities from modular components instead of buying one big suite.
The MACH principles from the MACH Alliance, which I'm sure everyone knows by now, describe how the software has to be built to make that work. 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: back-end services decoupled from front-end experiences
In practice that means you can swap a checkout module without touching the rest of the platform, launch a new channel (social commerce, for example) by plugging into API's, and scale infrastructure automatically for seasonal peaks. Etc., etc.
The C-suite view
For CIO's and CTO's, going composable is less about technology and more about what it does for the business:
- Risk management: no single vendor gets to dictate your roadmap.
- Financial flexibility: you move from capex-heavy upgrades to opex-aligned services.
- Talent: modern architectures attract modern engineers.
- Strategic options: 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 demand, or open up new revenue streams fast enough to diversify in an ever changing world. Years need to become months, months need to become weeks. EA is what turns that ambition into a plan.
For those reading this who feel composable leads to unmanageable ecosystems, multi-vendor headaches and never-ending programs: I will never say composable is for everyone. But done right, the benefits far outweigh the downsides. Which brings me to the practical side.
A practical playbook for going composable
1. Assess your digital core
Where are the real bottlenecks? Which domains (checkout, product, personalization, pricing) need agility first? Domain-Driven Design is an excellent fit for finding and cutting those domains.
2. Define your composable domains
Start small and go for the low-hanging fruit first. Get a feel for the possibilities and limitations in the context of your own business. Don't try to make the entire enterprise composable at once.
3. Set your architecture principles
API's are contracts. Modular over monolithic. Cloud-first, but multi-cloud aware. To name a few.
4. Build a phased roadmap
- Add composable services alongside the legacy platform.
- Run dual-stack and migrate incrementally.
- Retire legacy once the risk is low.
5. Embed governance
Keep it lightweight, but consistent. Every new implementation should follow your architecture principles. If you need to deviate, document!
6. Treat it like product development, because you're never done
If you go composable, drop the "waterfall, one program and we're done" routine. Invest for the long term in continuous development and improvement. The alternative is spending two years building what you needed when you started, and ending up back where you were when you're "done", without a real ROI.
Common pitfalls to avoid
- Technology before architecture: picking platforms before you've defined your principles.
- Big-bang replacements: rebuilding the monolith with modern tech, the typical "like-for-like" replatforming.
- Over-customization: re-implementing your legacy processes and losing the agility you were after.
- Ignoring culture: composable needs product-oriented, cross-functional teams.
Conclusion: design for change
Old systems on their own rarely kill agility. A rigid architecture around them usually does.
With EA at the center, CIO's and CTO's can move from rigidity to adaptability without creating chaos along the way. Guided by EA, composable stops being an IT project and becomes the way the business keeps up with its market. The enterprises that do well over the next decade will be the ones that built their architecture to change.