Imagine you have bought a kitchen. The whole thing arrived from one supplier: oven, fridge, dishwasher, worktops and cabinets, all designed to work together. It looks fine. It works fine. Then the dishwasher breaks, and you discover it has been plumbed into a proprietary system that only accepts parts from the original supplier. That model has been discontinued. Suddenly you are having a conversation about ripping out half the kitchen.

That is roughly what happens when a tightly coupled digital platform reaches the end of its useful life. Everything is connected to everything else. You cannot change the CMS without disturbing the CRM integration. Upgrading search means retesting the front end. A contained improvement becomes a replatforming programme.

Composable architecture offers a different proposition. You choose specialist components and connect them through defined interfaces. If one component no longer works for the business, you have a credible chance of replacing it while the rest of the platform carries on.

That is the promise. For the right organisation, it is a powerful way to evolve a digital platform. For another firm, it creates more integration work, suppliers and failure points than the requirements justify. The difference usually comes down to operating capability and economics, rather than enthusiasm for a particular technology.

This is therefore a decision guide, rather than another introduction to composable terminology. The question is whether the freedom is valuable enough for your firm to own the complexity that creates it.

The minimum architecture you need to understand

A traditional suite bundles content management, presentation and other capabilities in one platform. The upside is cohesion: one principal vendor, an established set of integrations and fewer architectural decisions for the customer. The downside appears when the suite's boundaries constrain a change the business needs.

A composable platform separates capabilities. A CMS manages content. A search service handles search. The front end controls what users see. Other components might handle forms, identity, personalisation or asset management. APIs let those parts exchange data and invoke one another.

Headless content management is one element that often appears in this model. Content is managed separately from the presentation layer and supplied through APIs. The same structured content can then support a website, client portal or other channel. A headless CMS alone does not make an entire organisation "composable", and adding more services does not automatically make a platform better.

The useful idea is replaceability. How much of the platform can you change without an expensive chain reaction? Replaceability has to be designed, documented and tested. Two products having APIs is only a starting point. Data models, identity, business rules, monitoring and editorial workflows can still create deep dependencies.

What freedom is the business buying?

Boards do not need an architecture diagram as the opening argument. They need to know which costly constraint will be removed.

Incremental change. A firm with several active digital services may want to improve one capability at a time. Separating those capabilities can reduce the blast radius of a change and avoid replacing a service that still works. This matters when priorities change throughout the year and a large replatforming cycle cannot respond fast enough.

A route out of vendor dependence. A suite vendor can shape the firm's roadmap, price and available integrations. Composability can reduce dependence on a single product. It replaces that concentration with a portfolio of dependencies, however. The firm still relies on suppliers, APIs, delivery partners and the people who understand how the whole platform fits together.

Reuse across channels. Structured content and shared services become more valuable when they support several meaningful experiences, such as a public website, knowledge hub and authenticated client portal. If the firm has one fairly simple website, the theoretical ability to publish everywhere may have little commercial value.

Control over experience and performance. Separating the front end can give a team more control over accessibility, performance and interaction design. The architecture does not guarantee those outcomes. A poorly implemented composable front end can be slow and inaccessible; a well-run integrated platform can perform strongly. Treat performance as an engineering and content requirement to test, rather than a benefit conferred by the label.

Make each claimed benefit concrete. Which component is currently blocking change? How often does the constraint occur? What does the delay or workaround cost? What would become independently changeable? If those questions have vague answers, the business case is still architectural aspiration.

The complexity you agree to own

Every boundary between components creates work. Somebody must define the integration, secure it, monitor it, update it and diagnose it when a supplier changes behaviour.

A suite vendor absorbs some of that work inside its product. In a composable model, more of it sits with the customer and its delivery partners. The exact burden depends on how many services you choose and how managed they are.

Look beyond the initial build. The operating model needs to cover:

  • ownership of each component and integration;
  • release, testing and rollback across services;
  • monitoring of user journeys as well as individual service uptime;
  • identity, access, data flows and audit requirements;
  • supplier changes, version updates and end-of-life decisions;
  • content modelling and editorial preview;
  • support triage when several vendors are involved;
  • documentation and knowledge transfer if a partner changes.

This is where over-engineering becomes visible. We once assessed a professional-services platform assembled from seven services and several hosting environments. Routine publishing depended on specialist intervention, so the marketing team had largely stopped managing the site directly. The architecture was flexible in theory and restrictive in daily use. The useful lesson is the gap between technical modularity and operational autonomy. Can the people who run the service perform routine work without navigating the architecture team built around them?

Compare total cost of ownership, rather than licence totals

The proposition that composable costs more initially and less later is too neat to use as a rule. Either model can be expensive. The result depends on requirements, supplier terms, the rate of change and the capability needed to operate it.

Build a comparison over a realistic period and include:

  • product licences and usage-based charges;
  • design, engineering, migration and integration;
  • hosting, monitoring, security and support;
  • internal product, content and technical time;
  • regression testing when a component changes;
  • supplier management and assurance;
  • likely enhancements, rather than the fiction that the platform will remain unchanged;
  • exit costs, including data extraction and replacement of proprietary dependencies.

Then model uncertainty. What happens if content volume doubles, a portal is added, a vendor changes pricing or the firm cannot recruit the specialist it expected? A range is more credible than a single five-year number built from optimistic assumptions.

The cost of delay belongs in the comparison too. If the current platform prevents the firm launching a valuable service or makes every modest change disproportionately expensive, staying put has a price. Give that constraint evidence. Avoid turning a frustrating backlog into an invented revenue figure.

When composable tends to fit

Composable architecture deserves serious consideration when several of these conditions are present.

The platform supports genuinely different services or channels. A website, client portal, knowledge product and internal tool may share content, identity or search while needing different interfaces.

Integration is central to the experience. The platform has to exchange reliable data with CRM, case management, document, identity or marketing systems. Those connections are explicit product requirements, with owners and defined outcomes.

Change is frequent and uneven. The firm expects to improve different capabilities at different speeds. Independent release and replacement therefore has practical value.

Technical product capability exists or is funded. Someone can make architecture decisions, manage interfaces, oversee releases and challenge suppliers. This can be an internal capability or a durable partner arrangement, provided ownership remains clear.

Content can be structured and governed. Content teams are prepared to model reusable information rather than recreate pages for every channel. They have workable preview, approval and publishing processes.

Leadership accepts continuous stewardship. The platform will need regular maintenance and improvement. It is treated as an operating capability, rather than a capital project followed by several years of neglect.

When an integrated platform is the better choice

A coherent suite or conventional CMS is often the stronger decision when the needs are simple, the team is small or the expected rate of change is low.

A 30-person consultancy that needs a well-designed website, useful articles and an enquiry route may gain little from owning several services. The ability to replace search independently has no value if basic site search is enough. A platform the marketing team can operate confidently may beat a more elegant architecture that turns routine changes into development tickets.

An integrated choice does not have to be careless or permanent. Ask about data export, APIs, front-end flexibility, accessibility, security support and the cost of leaving. Keep content structured where it is useful. Document integrations. Those choices preserve options without paying today for a hypothetical future estate.

Budget also matters, although the useful question is capability rather than a threshold. If the firm can fund the build while lacking any budget for monitoring, maintenance and improvement, it cannot afford the proposed operating model.

Assess organisational maturity before choosing

The technology decision is often easier than the organisational one. We assess four connected areas:

  1. Technical capability: can the firm or its partner manage APIs, deployments, security and cross-service diagnosis?
  2. Integration demand: are there enough important, well-understood connections to justify separation?
  3. Content operations: can teams define, govern and reuse structured content while retaining an efficient editorial experience?
  4. Organisational commitment: will leadership fund continuous ownership and make somebody accountable for the platform?

Do not turn this into a decorative maturity score. Record evidence and consequences. "Low technical capability" might mean the firm must recruit, choose a managed approach or reduce the number of components. "Weak organisational commitment" may mean postponing the wider architecture until ownership is resolved.

We had this conversation with a financial-services COO facing an expensive platform upgrade. The integration need was substantial, while leadership still wanted a one-off replacement followed by minimal investment. A fully composable estate would have created an operating model the organisation had not agreed to support. The recommendation was a contained first step: separate the content layer, stabilise critical integrations and revisit the broader decision after capability had grown. Architecture readiness can change, so the answer need not be permanent.

A practical middle ground

The debate is often presented as a binary choice when it is really a boundary decision. You can separate one part of the platform without assembling a collection of specialist services on day one.

For some firms, a headless CMS and a well-designed front end provide the useful first boundary. Search, forms or personalisation can remain simple until there is evidence that a specialist service would improve an important outcome. For another firm, the current CMS may be adequate while a client-facing application is built separately and connected through a limited set of interfaces.

Call this progressive composability if the phrase helps. The principle is more important: introduce a boundary when its benefit exceeds the cost of owning it. Avoid a catalogue of tools selected in anticipation of requirements that may never arrive.

Set exit criteria for the intermediate state. Which future demand would justify another component? What operating measure would show that the current arrangement is failing? Who will revisit the decision? Without those triggers, a "transition" can become another accidental permanent architecture.

Make the decision from evidence

Begin with what is driving the conversation. Is the current platform blocking a specific service, channel or rate of change? Is the firm exposed to an unacceptable supplier dependency? Or has composable simply become a proxy for "modern"?

Then map the current landscape. List the important user journeys, systems, integrations, suppliers and owners. Mark where changes become slow or risky. Estimate the cost of operating the current estate and the proposed one. Test the readiness of the teams who will publish content, support users and manage incidents.

The final recommendation should state:

  • the business constraint to solve;
  • the minimum architectural boundary needed;
  • capabilities the firm must own or procure;
  • expected costs and uncertainties;
  • risks introduced as well as risks reduced;
  • a sequence, with evidence required before the next step.

If the evidence points to a single well-run platform, choose it without apology. If several independent capabilities will create measurable freedom and the organisation can operate them, composable may be the stronger foundation.

We run 14-day assessments to help firms work through these decisions before committing to a platform. The purpose is to make the trade-off explicit, test readiness and identify the smallest sensible next move. The most expensive composable platform is the one you build before you are ready to run it.

There is a companion set of content in Section 4 of The Briefing Room covering the business case for platform investment. If the technology direction is becoming clear and the next problem is securing board or partnership support, that is the useful next read.