CrafterCMS

Web CMS Architectures: Coupled, Decoupled, or Headless?

For many enterprises, choosing a web CMS platform to power their websites and other content applications can be a tough one to make. According to CMSWire, there can be upwards of 14 rules that businesses need to consider when choosing a content management system. 

On top of all these rules, there are also many different vendors available, not to mention the different CMS architectures. Coupled or decoupled? Headless or not? If decision-makers want to keep their heads on, they need a way to weave through the jargon and make sense of everything. 

Generally speaking, there are two main types of CMS architectures: coupled and decoupled. Historically the term "coupled" has referred to the relationship between the authoring tools and content delivery of your live site. With the introduction of headless CMS platforms, the landscape has become a bit more complicated because there are more options on how to deliver content. Many headless vendors market their systems as decoupled, when they are really not. 

In this article, we'll break down the various CMS architectures, highlighting their strengths and weaknesses to give you an understanding of each so that you can make the right choice for your business.


What Is a Coupled CMS?

A coupled CMS enables users to create and edit content then “make it live” to end users through the frontend attached to the CMS. The content authoring system and backend database are tightly coupled together. WordPress and Drupal are excellent examples of a coupled CMS. 



 

The classic example of a coupled CMS architecture is a blog engine. In a coupled system, the underlying store for your content serves both authoring and delivery. Your authoring capabilities are part of the live delivery system but are available only to those who have permissions. In a coupled system, the process of making content live is typically a matter of setting a flag in the database.


What Is a Decoupled CMS?

By contrast, a decoupled system puts authoring and delivery in separate applications, and usually, on separate infrastructure. 

In this instance, the process of making content live is done through a publishing mechanism where content is pushed from the authoring platform (and underlying content repository) to a content delivery infrastructure. CrafterCMS and Adobe AEM are examples of decoupled CMSs.



Coupled vs Decoupled CMS

So which architecture is the right approach for your business? The reality is, it depends on your business requirements, your current processes and overall goals. Choosing between a coupled or decoupled CMS isn't a recent debate. However, it has traditionally been based on the assumption that there is a one-size-fits-all way to manage and publish content. 

Each architecture has unique strengths, weaknesses, and ideal use cases that must be acknowledged before determining which one is the right fit.  


Advantages and Disadvantages of Coupled Architecture

Let's take a look at the advantages and disadvantages of a coupled CMS architecture.

Advantages

    • Easy to set up and deploy a single instance.
    • Authoring and delivery are on the same infrastructure, making it easier to manage.
    • Publishing is simpler; in fact, there is no real publishing whatsoever. Flip a bit in the underlying database and the content is then “live”.
    • There is a relatively easy administration of production systems for single sites.

    Disadvantages

    • Coupled infrastructures are generally more complex to scale, as they typically depend heavily on database scalability and require complex database synchronization schemes.
    • Content is typically captured in a database schema meant for delivery on the site. This can make integration and migration difficult.
    • Software complexity is higher because the codebase contains both authoring and delivery concerns. All but the most trivial CMS projects involve some development, which can become a development issue.
    • Pushing content in and out of the CMS to and from third parties occurs in the same system that runs your live site. Integration is not native to the architecture, and it may impact the system's performance.
    • Security, or lack thereof. Your content authoring tools and team all exist on the live site, making it much easier to hack and/or deface your site, gain access to your enterprise network, and compromise other corporate systems.


    Advantages and Disadvantages of Decoupled Architecture

    Let's take a look at the advantages and disadvantages of a decoupled CMS architecture.

    Advantages

    • Easier to scale for high traffic websites. 
    • Managing multiple sites and delivery channels using the same CMS is much easier.
    • SLAs for authoring and delivery are decoupled. Authoring can be down for upgrades without impacting delivery. 
    • Scale only the components that you need. If you are not adding more authors, then there is no need to scale out authoring. This affects the complexity of the solution and also license costs where they are involved.
    • Code complexity is isolated within each of the two components (authoring and delivery). Each piece can be as simple or complex as is needed without impacting the other.
    • Integration is a built-in concept, as content is natively published to a remote delivery system. It is generally straightforward to push to other systems as well. Also note, integration takes place on the authoring tier safely away from the live site protecting stability and performance.
    • Content migration and sharing with other systems are generally much more innate to the architecture.
    • Multi-channel support is available by nature, as publishing to mobile apps, social channels, and other digital channels is a natural extension of the native publishing capability.
    • Content sharing and syndication are naturally supported.
    • When complexity is isolated, and scaling is simple, it's easier to develop and deploy rich features to your users.
    • Integrating with DevOps is much easier. When you need to integrate your development tools, process/automation and source code repository, you are inherently entering into a discussion about security and systems administration — all of which are significantly more approachable if authoring and delivery systems are separated.

    Disadvantages

    • Setup has more components and can be more complex.
    • Publishing may introduce additional points of failure.
    • Sub-division of components can go too far driving up complexity and driving down the cohesion of the user experience.


    Choosing Between Coupled and Decoupled CMS

    It's clear that each approach has its strengths and weaknesses. A coupled system may work well in one scenario, while a decoupled system may be much more appropriate in another.

    A coupled architecture can work well for smaller websites, microsites, and landing pages that need to be set up and put online in short order. It's also beneficial if you do not need to scale quickly or publish content beyond the website itself. 

    On the other hand, a decoupled architecture is ideal for websites or content backends that require high performance, high availability and ease of scalability. Also, if they need a lot of tailored functionality, integrations with third-party business systems, or publishing content to one or more digital channels beyond the website itself. Managing multi-channel digital experiences is better with a decoupled CMS.


    So What Is a Headless CMS? And Is a Headless CMS a Decoupled CMS?

    Coupled and decoupled architectures each provide unique benefits and work well in different scenarios. However, that doesn't explain where a headless CMS fits into the equation.  

    Headless CMS technology provides content to the presentation tier (or content consumer) as a service, typically via a RESTful interface in JSON or XML format. This is also known as Content as a Service (CaaS.) The main advantage of a headless CMS architecture is that content is written and published once but can be requested and presented uniquely by any number of different channels/content consumers.

    While headless CMS architectures do separate, or "decouple", content and presentation, they do not dictate anything about the CMS's authoring or delivery capabilities. And while decoupling content and presentation is certainly one of the most important things you can do architecturally, it's not the only major architecture decision you need to consider. 

    Therefore, it is crucial to maintain the traditional use of the word decoupled CMS as it relates to the separation of authoring and delivery capabilities.

    The reality is that a headless CMS can either be coupled or decoupled. Any CMS worth its salt today, whether decoupled or not, must support some headless or content as a service (CaaS) based content delivery.

    Many headless vendors say that they're decoupled, but in reality, they aren't. A headless CMS's primary characteristic is the use of APIs to connect to different front-end layers, and many headless CMS vendors still couple their authoring capabilities to the headless delivery system. On the other hand, a decoupled CMS has both authoring and delivery instances; they're just separated. 


    Going Headless With the Truly Decoupled CrafterCMS

    When deciding on a modern content management system, architecture is fundamental, and many CMS platforms have chosen to label themselves as a headless CMS. While headless is a great feature, it's not the only thing crucial for enterprises today. 

    CrafterCMS goes beyond headless into the realm of headless+, providing everything enterprises need from a modern CMS today. For example, a modern CMS should also provide you with robust content authoring capabilities, developer support for both modern JavaScript frameworks as well as HTML5 templating frameworks, DevContentOps support, high performance, ease of scalability, flexibility of deployment, and more. CrafterCMS is a truly decoupled CMS that separates authoring and delivery capabilities into their own subsystems in order to achieve these and many other benefits. 

    To learn more about Crafter’s modern decoupled architecture, check out this CrafterCMS Architecture page in the open source project’s online documentation.