Composable architecture: The CMS as your digital experience orchestrator

A composable architecture is made up of API-driven components that are pluggable, scalable, replaceable, and can be continuously improved. When building digital experiences, such as websites, using a headless CMS as a stack component can be complex, however.

The CMS history ping pong

The composable approach is not a new concept, but rather a response to the limitations of previous architectures. By understanding the evolution of CMS architecture, we can better understand the purpose of composable CMS and its benefits.

One common pattern is the trade-off between the needs of editors and developers. In traditional CMS systems, which include suites and digital experience platforms, the editor is satisfied with the user-friendly environment and access to templates and visual editing tools. However, the developers are often unhappy because they are restricted by the fixed system that tightly links the CMS and front-end.

With the emergence of headless CMS, the front-end is decoupled from the CMS, allowing the developers more flexibility with their tools and frameworks. However, the editor must now work with form-based content and has limited options for visual editing, previews, and URL management.

In modern stack solutions that use headless CMS, the CMS becomes just another API, diminishing its role. This can create problems for both the editor and the developer, as the limitations of the headless CMS become apparent.

See also: Enonic: the ultimate composable CMS »

The composer tries to orchestrate

Neither traditional nor headless CMS systems are ideal for the entire digital team within an organization. To address this, the composer is emerging as a middleware tool that offers a limited page builder on one end and acts as an integration API gateway on the other end. This allows for the use of both headless and legacy CMS systems when building new solutions and facilitates a smoother transition to a composable architecture.

However, the composer approach also adds another layer of complexity to the central problem. It too requires updates, integration, maintenance, and constant handling, and can be inefficient for editors who must switch between the composer and their CMS(s).

Composable CMS saves the day?

In headless and composer approaches, the CMS is reduced to "just another API." But the CMS is crucial to a website's functionality, so why diminish its role?

Why not use the CMS itself to do the work of the composer/integration layer? This is where the composable CMS comes in.

If your current or prospective CMS is capable and modern, you can use it to direct your APIs and digital experiences. This eliminates the need for another solution or integration, as the idea of creating content and pages in one tool will not go away.

Therefore, the composable CMS is the “logical end point” in the evolution of CMS architecture. It offers a great balance and makes everyone happy. There are fewer systems to manage, developers are satisfied with the separated front-end, and editors are happy with a user-friendly, visually oriented editorial environment.

As an added bonus, the composable CMS can also act as a bridge to your legacy CMS and smooth the transition to your new stack.

See also: Why we are building our new website with Next.js and headless CMS »

Summing up composable vs. alternatives

• A traditional CMS is not suitable for use in a modern stack
• A headless CMS can be limiting and cumbersome for editors
• The composer approach attempts to make the transition from traditional to composable easier, but only adds more complexity

A composable CMS, however, is the ideal solution that helps your entire team work more efficiently and can even assist in transitioning from a legacy CMS to a composable architecture.

The composer and CMS do not fit together well, as the composer is a temporary solution for organizations still using legacy technology. A composable CMS, on the other hand, can replace the composer by being both a headless CMS and composer in one.

A composable CMS should also be able to recreate the functionality of a traditional CMS for the editor, such as in-context preview, visual editing, and WYSIWYG, while simultaneously handling integrations and APIs.

At the same time, the developers can freely build solutions in their preferred front-end framework and access content and basic services from the CMS integrations or through direct integrations. Win-win.