Composable vs. Suite: Refereeing the Enterprise Architecture Fight

The loudest adjective in enterprise architecture right now is ‘composable,’ and the volume is coordinated. The MACH Alliance (microservices, API-first, cloud-native, headless) is the best-of-breed vendors’ standards body and marketing engine. It evangelizes the death of the suite. The analyst frameworks have blessed ‘composable DXP’ as the direction of travel. The integrated platforms, Adobe foremost, counter that the assembly costs of best-of-breed are being undersold by the people selling the pieces. Both camps quote case studies, often the same ones, read in opposite directions.

We sit in an unusual seat for this fight. We have built and operated both architectures for institutional clients across a decade. We hold no vendor allegiance in either camp. And we carry the implementation scars that the keynotes on both sides conspicuously lack.

So: a referee’s assessment, in the format we use for architecture fights. What composability actually buys. What it actually costs. What the suite trade actually is. And the verdict, which annoys both camps and matches the pattern we see across the sites we operate.

What composability actually buys

The genuine goods, stated fairly, because the referee’s credibility depends on it. You can swap parts one at a time. The composed stack swaps its search without touching its content. It replaces its personalization engine without a replatforming. It adopts the best current tool per capability, on that capability’s own refresh cycle. Adopt-with-an-exit, expressed as a design, and truly valuable exactly where tool categories change fastest.

Wiring based on contracts. The API boundaries between components are explicit, documented, and testable. That disciplines vendor relationships, since the contract is the product, and keeps each component honest against alternatives.

Leverage at the bargaining table, for good. Every renewal happens against a live market of substitutes rather than inside a suite’s gravity. Procurement teams that have lived both ways will testify to the difference in basis points.

And the strategic property underneath all three: the architecture’s shape matches the market’s shape. The site can follow innovation where it actually happens. The best search this year is not made by the best CMS vendor this year, and never has been. These gains are real, they compound, and the suite camp’s habit of waving them away as fashion is the tell that the suite camp is also selling something.

What composability actually costs

• Integration engineering as a permanent capability, not a project: the composed stack’s seams are yours forever. The identity passing, the data syncing, the event plumbing between five vendors’ services. Built once, operated always, staffed as a payroll line rather than a statement of work. It is the single most undersold line in every composable pitch we have refereed. Teams that cannot staff it are not choosing composable. They are choosing an unstaffed obligation.

• The glue nobody demos: the demo shows each component excelling. The site runs on what connects them. The session that must survive five services. The preview that must compose them. The search index that must know what the CMS published seconds ago. This glue tier is where composed projects actually spend their overruns, per our scars.

• Accountability blur when the experience breaks: the outage that spans three vendors’ seams belongs, contractually, to no one. The suite’s single throat to choke is a real operational asset. The composed site replaces it with your own integration team as the accountable party, which is honest only if said in advance.

• The suite tradeoffs, inverse and equally real: coherence purchased with gravity. Built-in preview, one identity, one vendor to hold to account. Bought at the price of the suite’s pace, the suite’s roadmap, and the switching costs that make every renewal a hostage talk in the other direction.

The verdict that annoys both camps

Here it is, from the sites we actually operate. Composability is a spectrum position chosen per capability, not an identity chosen per keynote, and most institutions belong between the poles.

The pattern that works, across our current book. A governed content core: the CMS tier where editorial operations, governance, and workflow live. The layer where coherence pays most and churn costs most, held stable. That core can be a suite, modern Drupal, or WordPress at scale. Then composing at the edges where change is fastest: search, personalization, commerce, events. The categories with real innovation speed, integrated by contract and replaceable on their own cycles. With the integration capability staffed honestly for exactly the seams you have chosen to own, and no more.

This position annoys the MACH camp because it declines the full decomposition, and the full integration payroll. It annoys the suite camp because it caps the suite’s footprint at the layers where gravity earns its keep. It has the referee’s virtue of coming from operations rather than either camp’s revenue model.

The decision method, as always. Capability by capability, ask where requirements are stable versus fast-moving. Where your team can staff seams versus needs accountability. Where the exit costs of each option actually land. Let the answers place you on the spectrum: architecture by requirements. The keynote on either side does not know your team, your governance maturity, or your integration bench. Every architecture that matters is operated by exactly those three things.

The oldest argument in enterprise software

The pattern note that files this fight where it belongs. This is the industry’s oldest argument: best-of-breed versus integrated. It ran previously at the ERP tier, the marketing-stack tier, and the datacenter tier. Now it arrives at the DXP layer with new acronyms. Its previous runnings all ended the same way. The poles proved to be marketing positions. The market settled into governed cores with composed edges. The organizations that suffered were the ones that bought an identity instead of an architecture. The full-suite sites calcified around a vendor’s pace. The fully composed sites drowned in their own seams.

The standing tools handle this round without modification. The requirements gate before any adjective. The durability rubric for each component’s vendor. The exit-cost survey in both directions. And the staffing sentence, an architecture is a staffing commitment with a diagram attached, read aloud in every decision meeting.

The composable wave will deposit real improvements. The contract rigor, the API-first expectations, and the replaceability norms are all genuine progress, and we welcome them. The suite tier will absorb the pressure by opening its own edges, the constraint-into-option pattern the commerce file just documented. And the sites that thrive will be, as at every previous running, the ones that refereed their own fight. Tool by tool, requirements first, scars respected. That is the whole verdict. It fits on the whiteboard where the fight is happening, and it will still be true when both camps’ logos have changed.