Every enterprise platform reaches the same moment sooner or later: one piece has to change, and changing it means touching everything. The CRM that no longer fits is tangled with billing, billing with inventory, inventory with the customer portal. What should be a three-month decision becomes a two-year platform replacement. Composable architecture exists so that moment never arrives again.
The short answer: composable does not mean many pieces, it means replaceable pieces. You get there by placing seams where the business actually changes, connecting them with stable contracts, and measuring coupling with operational evidence rather than diagrams. And there is a moment when splitting is exactly the wrong move.
What is composable architecture, really?
It is designing around interchangeable capabilities, not around boxes drawn on a slide.
The unit of a composable architecture is the packaged business capability: a self-contained component that delivers clear, complete business value on its own, with an explicit contract facing outward. Quoting, billing, identity, catalog, and routing are typical examples. The test is not how many pieces you have, but whether you can change one without negotiating with the others.
The market is moving that way in measurable terms. Gartner projects that by 2026 at least 70% of organizations will be mandated to acquire composable digital experience platform technology rather than monolithic suites, against 50% in 2023 [1].
Data
| Year | Share of organizations |
|---|---|
| 2023 | 50% |
| 2026 (projected) | 70% |
Is composable the same as microservices?
No, and confusing the two is the most expensive mistake in this conversation.
Microservices are a deployment decision. Composable is a design property. You can have twenty microservices that must be deployed together because they share a database, and that is not composable: it is a distributed monolith with a cloud bill. And you can have a single deployment, a modular monolith, with boundaries so clean that replacing the quoting module is two weeks of work.
DORA's research says it without ambiguity: architecture, not technology choice, is what determines delivery performance, and the pattern holds on a mainframe just as it does on microservices [2]. What matters is whether teams can make large-scale changes without external permission, test without integrated environments, and deploy independently of other services [2].
What do three expert positions say?
There is a real disagreement here, and it is worth seeing before choosing.
Position 1. Composable as the market direction (Gartner). Gartner's analysis holds that composable modularity is a growing architecture and investment objective, driven by demand for business agility, and that enterprise buying is shifting from monolithic suites to interchangeable components [1]. Under that reading, whoever does not modularize stays tied to a vendor's pace.
Position 2. Start with a monolith, do not split early (Martin Fowler). The opposing position is uncomfortable and well documented. Fowler wrote that "you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile," and observed that "almost all the successful microservice stories have started with a monolith that got too big and was broken up," while "almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble" [3]. His underlying reason is that even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning, and refactoring functionality between services is much harder than doing it inside a monolith [3].
Position 3. The seam, not the count (Neo Bernal, co-founder of MasterDragon.AI).
The most expensive pattern I run into is always the same: a platform split into more than ten services before it has a first customer. Shipping one feature takes days and requires coordinating several people. The diagram is beautiful. The operation is stuck. I offer an opinion here not because I hold a theory of architecture, but because the work of undoing those splits looks the same every time.
In those teams the question is usually "why did we end up so slow?", and that question only spreads blame among whoever drew the diagram. The one that unlocks it is different: "what did we separate each piece for?". Asked service by service, most of them have no answer.
Seen that way, Gartner and Fowler stop contradicting each other: Gartner describes where a mature system should evolve, and Fowler describes how to get there without breaking on the way. What resolves the tension is changing the unit of measure, dropping piece count in favor of cost of change. In practice that is three moves:
- Start modular but deployed together, with explicit internal boundaries and clearly owned data.
- Define a boundary only where you have already observed the business changing at different rates, not where the diagram looks better.
- Extract a piece once the friction is measured, not when you sense it.
I want to be honest about the limit, though: this does not tell you how many pieces you will end up with, and sometimes you will extract a seam and find six months later that it was in the wrong place. The rule does not eliminate the mistake, it only makes it cheaper. A correct seam pays for itself; a premature seam gets paid for twice.
Where do the seams go?
Where the business changes at different rates, not where the org chart has a line.
This is the practical rule we use: two capabilities belong in separate pieces when they change for different reasons and at different frequencies. The catalog changes daily, accounting changes with the law, identity almost never. If they live in the same piece, the slowest rate throttles the fastest.
Table 1. Signals for placing or delaying a seam.
| Signal | Place a seam | Not yet |
|---|---|---|
| Rate of change | Very different between the two parts | They always change together |
| Teams | Separate teams with clear owners | One team maintains both |
| Data | Each side owns its data | They share tables and transactions |
| Domain boundaries | Already proven by months of change | Still being discovered |
| Reason for splitting | Observed and measured friction | The diagram looks better |
Look at the last row. It is the one that costs the most money when ignored.
What is the worst possible outcome?
The distributed monolith, and it is more common than either extreme.
It happens when you split the system into services but kept the coupling: they share a database, they call each other in a chain to complete one operation, and they have to be deployed in a specific order. You pay network latency, operational complexity, distributed observability, and cloud cost, and in exchange you do not get the independence that justified the split. It is the worst of both worlds and it usually results from splitting before knowing the domain, exactly the risk Fowler warns about [3].
How do you prove an architecture is composable?
With operational measures, not the architecture slide.
A diagram always looks modular. The evidence is in how the team works. DORA proposes measuring exactly this: what share of design changes requires approval outside the team, what share of deployments needs coordinating with other services, how many hours a week go to cross-team coordination, and how many handoffs there are from code complete to user release [2].
If your answer to "can this team deploy its piece today without waiting on anyone?" is no, you have coupling, no matter how many boxes the diagram has.
How we apply this at MasterDragon
We design for cost of change, not for service count.
In our builds that becomes a concrete sequence: start modular and deployed together, with explicit internal boundaries and clearly owned data; observe which parts change at different rates during the first real cycles; extract a piece only once the friction is measured; and leave versioned contracts at every seam so a future replacement needs no negotiation. The outcome we aim for is simple to state and hard to achieve: that three years from now you can change any piece without asking the rest of the system for permission.
If you are about to commit to a platform or rebuild your own, talk to our AI engineers before you fix the boundaries. Start with how we build your software and review our portfolio of shipped AI-native products. And if the underlying decision is build versus rent, we develop it in custom software is an asset, not an expense.
References
- Gartner. (2025, February). Magic Quadrant for Digital Experience Platforms, as cited by MACH Alliance. https://machalliance.org/insights-hub/composable-comes-of-age-in-the-gartner-dxp-magic-quadrant
- DORA. (2025). Loosely coupled teams: capability overview. Google Cloud. https://dora.dev/capabilities/loosely-coupled-teams/
- Fowler, M. (2015, June 3). MonolithFirst. martinfowler.com. https://martinfowler.com/bliki/MonolithFirst.html