There’s an old thought experiment in philosophy called the Ship of Theseus. If you replace every plank of a ship, one by one, is it still the same ship? Enterprises are beginning to live a version of that question in real time — except they don’t have the luxury of doing it plank by plank, on their own schedule. Markets move faster than replacement cycles. And that’s where composable architecture enters the conversation.
The idea is deceptively simple: instead of building your enterprise systems as one enormous, tightly coupled structure, you build from modular components — Packaged Business Capabilities, or PBCs — that can be assembled, reconfigured, and swapped out without unravelling the whole thing. Think less of a cathedral, more of a LEGO city. The cathedral is beautiful and permanent. The LEGO city can be rebuilt on a Sunday afternoon.
Why the Monolith Became a Problem
For decades, the monolith made sense. You built a comprehensive ERP, or a sprawling CRM, and it did everything. It was expensive to buy, expensive to customise, and very expensive to leave. But it worked. The problem is that “it worked” was measured in a world where business requirements changed on a timescale of years, not months.
Now the timescale has compressed. Regulations shift. Competitive threats arrive from adjacent industries. A supply chain disruption in one region rewires procurement logic globally. The enterprises that weathered these moments well weren’t necessarily the largest — they were often the ones whose architecture had enough flexibility to pivot without a multi-year transformation programme.
The pattern worth noting: Gartner tracks that organisations embracing composable architecture outpace competitors by as much as 80% in speed of new feature implementation. That’s not a minor efficiency gain — it’s a structural advantage in markets where being second can mean being irrelevant.
What “Composable” Actually Means in Practice
It helps to get concrete, because composability can sound abstract until you see it in motion.
The simplest version: composable architecture is the reason Netflix can roll out a new personalisation feature in one region without touching its payment system. Or why Uber can update surge pricing logic without rebuilding the driver dispatch engine. Each capability is independent, with a well-defined interface — an API contract — that says how it communicates with everything else. Swap the component, keep the contract, the rest of the system doesn’t notice.
Gartner frames the composable enterprise across three building blocks: Composable Thinking (the design principles guiding what to build modularly), Composable Business Architecture (the structural layer — teams, capabilities, governance), and Composable Technologies (microservices, APIs, headless SaaS, event-driven systems). The technology is almost the easiest part. The harder work is getting the organisational model and the thinking to align with it.
This connects directly to the architecture conversation explored earlier in this series — particularly around why legacy architecture is now surfacing as an AI bottleneck. A composable design isn’t just faster to change — it’s also far better positioned to absorb AI components as they mature, because those components slot in as capabilities rather than requiring full-system rewrites.
The Organisational Shift Nobody Warns You About
Here’s what tends to get underplayed in the architecture conversation: composability requires a different kind of organisation, not just a different kind of software.
In a monolithic world, a team owns an application. In a composable world, a team stewards a capability — and that capability has to serve any consuming team that needs it, via a defined interface. The software contract is no longer between a vendor and a buyer; it’s between teams inside the same organisation. That changes conversations, incentives, and accountability structures in ways that architecture diagrams don’t capture.
There’s also a vendor relationship shift. Rather than one sprawling platform contract, enterprises move toward curating an ecosystem of best-fit components from multiple providers — choosing the best payment capability, the best fraud detection, the best onboarding flow — and integrating them through APIs. This is why around 84% of CIOs and CTOs surveyed by Rimini Street indicated they planned to invest in composable ERP. The monolith era of software procurement is quietly winding down.
The Lens Worth Applying: Change as a Design Criterion
The most useful reframe here isn’t technical. It’s about what you’re optimising for when you make architectural decisions.
Most enterprises historically optimised for stability — build it right once, maintain it, extend it carefully. Composable architecture optimises for changeability. It treats the ability to reconfigure as a feature, not a side effect. That’s a genuine philosophical shift, not just a different deployment pattern.
It also has implications for how enterprise software gets evaluated. By the mid-2020s, Gartner projected that 70% of large and mid-sized organisations would include composability as a key criterion when approving new application investments. Not as a nice-to-have — as a gate. The question stops being “what does this system do?” and starts being “how does this system behave when we need it to do something different?”
That’s the conversation worth having in any organisation still running on applications that were designed, quite intentionally, to never need to change.
The Risk Nobody Talks About
Composability isn’t free of tension. There’s a real risk that modularity, pursued without discipline, creates a different kind of complexity — dozens of loosely connected components, unclear ownership, fragile integration points, and an architecture that’s flexible in theory but brittle in practice.
The organisations navigating this well tend to invest as heavily in governance and interface standards as they do in the components themselves. The LEGO analogy is instructive here too: LEGO bricks work because the stud-and-tube connection is rigorously standardised. Without that standard, you just have a pile of plastic. The composable enterprise needs its equivalent of the stud standard — and right now, many organisations are still figuring out what that looks like for them.
In your organisation, what’s the one system that everyone knows would take years to change — and what would it mean if it didn’t have to?
Let’s keep learning — together.
harish.balasubramanian 
Share your thoughts