The future of the CMS in 2022
I wrote a post about how in 2018 the CMS landscape was changing. This is the promised follow-up post but it’s taken a bit longer than expected to get published 🤣. Fortunately, during this time new tools and terminologies have emerged which make this updated post easier to explain and write!
In my blog original post, I touched on two key points.
- decoupling presentation from your data source is great.
- But, there is a missing piece which is the editorial experience.
Editing websites with ease
Low code tools have been around for many years within the WordPress community and tools like Squarespace, Wix, and Weebly. Those aforementioned products are reluctant on the HTML structure and not an underlying fieldable data structure. These tools are great if all you need is a website, quickly, cheaply, and easily. If the requirements for a project expand beyond what is available out of the box or your content needs extend beyond just displaying on a website these solutions quickly aren’t suitable.
There are some new players on the block, Acquia Site Studio, Uniform, and Builder.io which for the first time have brought the possibility of low code to the enterprise sector.
Speed to launch like never before
Why is low code so important? In my last role, I witnessed first-hand how low-code tools such as Acquia Site Studio page-building can bring a site to market quicker than ever before. On one project, we helped launch over 300 sites in 18 months as opposed to the 60 months originally estimated.
Low-code also helped our clients in travel when the pandemic hit. We were able to help rebuild their website, to aid a pivot to their business proposition, launching the new website in 10 days (yes that’s right — days not weeks).
The fundamental flaws
Low code brings a host of new opportunities and gets us closer to bridging the gaps of the editorial experience that decoupling your CMS brings. Yet at the same time, the existing solutions all seem to suffer from a similar flaw. In order to be viable as a product on their own, low-code tools such as Uniform, Builder.io, and Acquia Site Studio, all require that you subscribe to an API service/platform.
Needing to subscribe to a hosted API service creates vendor lock-in and requires your data is sent outside of your CMS/data source. This is necessary to create a business model around the product alone. While this is a completely valid approach, it fails to deliver on larger data migrations because the underlying data structure is a black box. Also, in organisations where security and data ownership are key requirements these tools are a non-starter as they need to be sent to the platform API.
The solution is simple—build your low-code solution based on open first-party data.
This does mean that you need to look elsewhere for funding for the product such as becoming subject matter experts in the technologies, having additional services offering (such as personalization, content optimisation, hosting, and search), or gaining development efficiencies at scale.
Why decouple?
Since my original post in 2018 when decoupling was still very much in its infancy, the JAMStack scene has absolutely exploded. With tools such as Next and Gatsby in the picture, it simply doesn’t make sense to not use one of these frameworks. Compared to runtime build languages such as PHP these frameworks provide the following advantages:
- Speed
- Scalability
- Security
- Unified data-layer
Because they are based on React, you receive the improved rendering capabilities (Virtual DOM) straightaway. You are creating a separation of concerns. Optimizing the backend for backend tasks such as business logic and data manipulation serves as a quick and powerful API. While your presentation layer is optimised for creating the best, most performant user experiences. This is very important because I’ve worked on many Drupal websites where even with the best intentions, the data separation boundaries became blurred (I’m looking at you views-in-views).
A world of new opportunity
When you move away from the monolithic CMS, you open opportunities to create some fantastic new experiences for your end users. I’ve personally helped create Drupal APIs for billboards in Times Square, immersive spinning experiences, and Echo skills in addition to JAMstack websites.
Unified data
In 2019, Gatsby coined the notion of a “content mesh” which is taking content/data from multiple sources (Drupal, WordPress, Contentful, Shopify, etc.) and distilling them into a single GraphQL data layer. Data unification allows developers to pick and pull information from many different sources but then feed it into one cohesive experience for users.
It also boosts, performance because (in addition to Static Site Generation) you are fetching the least possible amount of data rather than a complex series of chained queries.
Improving the editorial experience
One of the key points that I touched on in my last post was fractured and separate experiences when you decouple. All of a sudden you have more than one system and experience to manage. Tools such as Gatsby Cloud and Vercel have worked hard to make this better and now provide preview environments which update as you edit from your CMS. This is much better than the experience we had a few years ago without preview environments but it doesn’t quite go far enough.
The “Experience Layer”…
In my current role, I’m working on what I’ve dubbed the “Experience Layer.” It is an extension of the existing preview environments that joins the dots between your content and presentation layers.
As an example of an “Experience Layer,” I’m currently focussing on a true WYSIWYG experience for websites that provides low-code page building for Gatsby. This is using the same React components for editing that are used to power the client-facing website. This solution integrates with the structured data provided by the JSON:API from Drupal and reads/writes the data.
Currently, the Experience Layer is focused on powering websites. However, in the future, I’m hoping to take this further and power additional experiences such as mobile apps using React Native, digital signage and voice interfaces.
The CMS is dead — sort of…
The main question here is what is a CMS in 2022? Well, today the lines around the capabilities of a CMS are blurred. Nowadays, client requirements for their digital presence extend much further than merely just having a website. I’ve seen requirements for integrating with PIM, PAM, DAM, CRM, CDP, ERP, Commerce, etc. (if there is an acronym for it a client probably wants it!) All of these integrations are blended together to meet the client’s specific needs and join the dots for their customers. While CMS’ still form a crucial part of this larger landscape, unlike 5 years ago they aren’t the primary part.
Every client’s needs are slightly different so when building a digital presence, the different functionalities need to be pluggable and modularised. This concept has been around a little while now and is called “composable architecture.” Conceptually, I think of this similarly to the plugin/module systems that exist in CMS’ but with cross-functional and cross-technology capabilities.
By looking at this broader remit and landscape, it becomes clear that in 2022 the CMS is a small part of the much bigger picture.
Enter the world of the Digital Experience Platform (DXP)
If in 2022 the CMS doesn’t cut it anymore then what does? Well luckily our friends at Gartner have come up with a new definition:
A digital experience platform (DXP) is an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.
(Gartner — https://www.gartner.com/en/marketing/glossary/digital-experience-platform-dxp-)
DXP is the next evolution of the CMS putting customer experience at the heart of your digital presence. Furthermore, this new world allows content managers to connect data from many more sources and output to many more channels.
There are many solutions that are aiming to tackle this. However, all solutions that currently exist (including the ones labelled open source), are all stuck behind a walled garden of proprietary code and services.
I’m on a mission to change that and build a DXP based on open-source.
If this journey sounds interesting, take a look at a look at a few of my other related posts:
And… let’s connect!
