Coupled CMS Architecture - Advantages and Disadvantages
Niklas Winkels
2019-04-29
In the last couple of years, the headless CMS architecture has gained a lot of traction. While some believe a headless CMS is an ultimate choice for everyone, others argue that the traditional CMS architecture is better.
For a regular CMS user, the design and CMS architecture of the system running the web pages rarely – if ever – comes to mind. But as a developer, the structure of a system makes a big difference in how content creators and administrators will interact with the system. The underlying architecture makes a substantial difference for the user experience (UX) as it affects the interaction between the backend and frontend of the website, as well as dictating a system’s capabilities.
In the following series, we’ll be looking at the various designs of different CMS architectures in use today as well as discuss the advantages and disadvantages of each system. Here, we’ll look at the most common architecture in use today: the coupled CMS.
You can find more articles in the series here:
Overview of the Coupled CMS Architecture
The coupled CMS (sometimes referred to as a “traditional CMS”) is perhaps the simplest in terms of layout and general functionality. Underlying elements of the system are “coupled” together and dependent on many of the same resources In a coupled architecture, the backend of the system is closely integrated with the frontend meaning the CMS has its own delivery tier. Unlike some of the designs that have surfaced in more recent years, components such as the database that stores content, the interface(s) where content is created, and the publishing engine are directly integrated into the backend of the coupled CMS. These pieces are inherently linked, meaning these components share some of the same resources and rely on the same services to function. The front end of a coupled CMS is primarily used to display the content on the site. Virtually all the CSS used for layout will be stored in the same place as the code of backend components (i.e. application integrations, core layout components, plugins, templates, etc.). The frontend is ultimately responsible for compiling the data and outputting the information on any given browser.
Advantages of the Coupled CMS
The major advantages of the coupled CMS design mostly root in accessibility and the close integration of tools for authoring and publishing content. This makes this design ideal for marketers as content that’s created and stored in the underlying database is integrated with publishing tools. As such, it makes it easy to create anything from a core site page through to a blog, so long as the user has the proper privileges. Like other business systems, multiple users can be created with different sets of privileges that define what each can do while interacting in the system. For example, many companies employ teams or marketers (e.g. bloggers) who create content based on an editorial calendar or maybe spin current events, which is published after a round or two of editing. These users can be restricted to do just that, while editors can have the final say on whether or not to publish a page. These accounts may also be limited to only interact with this portion of the coupled CMS, meaning they won’t be able to interact with core functions of the system.
To break it all down, the biggest advantages of a coupled CMS architecture are as follows:
Integrated Frontend and Backend
While this is technically a weakness as well, the design is advantageous for marketing teams.
The database that stores digital assets (like content and images), the system for managing content, and application where designers apply their designs, are all part of the backend. This ties directly into the frontend where changes are immediate. The results of troubleshooting or tweaking some element to “look just right” are immediately visible in a preview mode, meaning these teams can quickly polish content and images for a quality publication.
Easy Administration
Authorization of users is role-based to determines which portions of the system they can and cannot access. This is also tethered to the ability to publish content created on the backend, which is helpful for functions like editing a blog or new page, as this helps ensure only polished material becomes publicly visible.
Ideal balance
The coupled CMS architecture means that there’s an ideal balance of who's in control. Because it’s a singular system, marketing and development are equally in control of the experience, versus headless CMS architectures where usually developers are more in control and the marketer oftentimes loses certain editing features.
Disadvantages of the Coupled CMS
To an engineer or a developer, the design of a coupled CMS has some obvious shortcomings. The integrated architecture makes the deployment cycle more convoluted as everything needs to align on both the front and backend. Developers are often limited to the tools embedded in the system. The restrictions this creates means adapting around the system, rather than the other way around (which most – if not all – developers prefer!). It also means that optimizing the delivery has to take place in the confines of the coupled CMS architecture, which might result in not necessarily using the latest and greatest web technologies unless the vendor supports them.
This is the reason systems running SaaS or PaaS applications, and those that provide some other service like authentication, all run on different machines. This avoids the potential for conflict among core components as well as the applications or services provided by a system.
As such, the most prevalent disadvantages found in a coupled CMS are as follows:
All-in-one Design
While this makes user interaction simple, it also means that any problems encountered are more severe. One small, faulty portion of the software could leave the entire system – and the data it stores – vulnerable to being exploited.
Also, the ability to author and deliver content is fundamentally linked for each user, which can get messy for formal publishing endeavors.
Restrictive Development Environment
The tight coupling of the monolithic architecture of the coupled CMS puts a boundary on the development of microservices of the system.
A good analogy for this would be to think of video game cartridges from the 16-bit era – you couldn’t plug a Sega game into a Super Nintendo or vice versa as they wouldn’t fit! While developers can usually develop around a coupled CMS’s architecture, if a developer isn’t as familiar with the language required, this could lead to issues with security vulnerabilities or functionality problems.
Database Restrictions
A singular database is helpful for the sake of simplicity, but it becomes problematic for complex functions. Information is pulled from these databases in specific to how the underlying code pulls data – this restricts certain development processes as well as makes these systems more difficult to scale.
Final Thoughts on the Coupled CMS Architecture
If you’re looking to make a relatively simple marketing site, a coupled CMS is a good choice for its simplicity. Also, the delivery tier of a coupled CMS architecture often times performs better in regards to page load time compared to rendering the front-end externally. For those looking to host multiple sites, apps or kiosks or single page applications (SPAs) more complex systems such as a decoupled, headless, or hybrid CMS, would better suit these needs.