By Thomas Sigdestad, CTO and co-founder @ Enonic
What comes after headless CMS? A composable CMS marks the next natural step in the evolution of content management systems, and offers several benefits.
A composable architecture consists of API-driven components that are pluggable, scalable, replaceable, and that can be continuously improved. When building digital experiences, and websites in particular, using a headless CMS just like any other stack component has turned out to be complex.
The oscillating spiral of CMS history
The composable approach has not emerged from a vacuum. As we’ll see shortly, composable is a reaction to a type of architecture that itself was a reaction to another architecture, and so on. By understanding this background, we can more greatly appreciate what a composable CMS is and what it tries to achieve.
Let’s take a look at this pattern:
Traditional CMS: The editor is happy, the developer is unhappy
Headless CMS: The developer is happy, the editor is unhappy
In a traditional CMS, which also includes “suites” and fully-fledged digital experience platforms, the editor is happy due to a user-friendly editorial environment and having access to templates, visual page editing, and “everything in one place.” The developer, however, is unhappy because he must work within a fixed, “straightjacket” system, where the CMS and the front-end are tightly linked.
With the advent of headless CMS, the tables have turned. Now the front-end is fully separated from the CMS, allowing the developer to work freely with the tools and frameworks he loves. The editor, however, must confine himself to work with form-based content (at least in many first-generation headless systems), with limited possibilities for visual page editing, previews, and URL management.
In headless and modern stack solutions, the role of the CMS has been diminished, essentially becoming like any other API. With the mentioned limitations, this has become a problem for the editor, and by proxy also a problem for the developer.
The new kid on the block: the composer
So, neither traditional nor headless CMS are optimal for the entire digital team in your organization. In an effort to bridge the gap, another new tool is emerging on the market—namely the composer. The composer is itself not a CMS, but rather aims to act as a middleware - on one end offering a limited page builder, and on the other end acting as an integration API gateway to reduce the number of integrations that must be placed into your front-end.
As such, the composer allows you to use both headless and legacy CMS as sources when building your new solution—promising a smoother transition from a legacy stack to a composable architecture.
The downside however, is that the composer approach adds another complex equation to the central problem. You now have a new solution that must be updated, integrated, maintained, and constantly handled. Also, for editors to jump back and forth between the composer and their CMS(s) is inefficient.
The composable CMS
In the headless and composer approaches, the CMS has been reduced to “just another API”. But the role of the CMS is probably the most important part of your website, so why relegate it to such an unworthy position?
Why not use the CMS itself to do the work for the composer/integration layer?
Enter the composable CMS.
If your current or prospective CMS is capable and modern, you can orchestrate or direct your APIs and digital experiences from the CMS itself—you don’t need yet another solution or integration on top of that. The notion of making content and pages in one and the same tool simply won’t go away.
The “final” step in the history of CMS architectures is therefore the composable CMS. The composable approach offers a great balance, thus making the entire company happy. There are fewer systems to be managed, the developers are happy with the separated front-end, and the editors are happy with a user-friendly and visually oriented editorial environment.
Bonus: Just like in the composer approach, the composable CMS can also act as a bridge to your legacy CMS, and smoothen the transition to your new stack.
To sum up:
A traditional CMS does not work in a modern stack
A headless CMS is limiting and cumbersome for editors
The composer approach aims to ease the transition from traditional to composable, but adds more complexity
Finally, a composable CMS is the perfect compromise that helps your entire team work more efficiently, and can even help in the transition from legacy CMS to composable architecture.
A composer and a CMS do not fit tightly together. The composer is therefore a transitory solution for organizations stuck with legacy technology. A composable CMS, however, can replace the composer, by being a headless CMS and composer in one solution.
A composable CMS should also be capable of recreating functionality from a traditional CMS for the editor, like improved preview, visual editing and WYSIWYG—and it handles integrations and APIs. At the same time, the developer can freely build solutions in his preferred front-end framework, while getting access to content and basic services from the integrations provided via the CMS, or through direct integrations.
Learn more about the latest CMS trends
You might also like these related posts from Enonic
Enonic is a long-time member of the CMS Expert group. A forum where CMS analysts, thinkers, practitioners, experts and vendors can meet, set the agenda for future industry developments, provide feedback and share thoughts and ideas in an inspiring setting.
Feel free to leave a comment below and then you can also join us in person where the conversation continues at the CMS Expert conference track at the Boye Aarhus 22 conference and again in January at CMS Kickoff 2023 in Florida.
Finally, we did a vendor-neutral evaluation of Enonic XP in 2021, which you can download free of charge.