I’ve written many posts about CMS architecture by now—the methodology, the technology, the inner workings of the most popular CMS platforms. But ultimately, most clients have no way of knowing which would work best for their business based off of blog posts alone.
The fact is that every situation is unique. That’s why most of our projects begin with a discovery phase where we work to discover the best CMS platform for the enterprise in question. How a business works, how they plan to use their content management system, and how their digital ecosystem is structured all determine the best platform for the mission.
To take it a level deeper, how a system is architected plays a direct part in the future success of a business’s digital efforts. Simply put, architecture matters. The particular approach that may work best for you depends on a variety of factors specific to your situation.
So how do you determine what will work best for you?
First, let me break down the most popular reasons companies utilize a CMS based on their mission. Then, I’ll discuss which CMS architectures work best for each particular model.
Common CMS Use Cases
To begin, the most common use cases we see for CMS-based projects fall within the following categories. I’m not saying, by any means, that this is the most comprehensive list. I’m just pointing out that 95% of projects we see fall into these categories.
Marketing / Informational
This is the broadest category. You can include sites that range from your local mom-and-pop small business all the way to the largest companies in the world.
A marketing website typically has the same mission regardless of the company’s scale: attract, educate, and convert users. Typically, this “conversion” means the user supplies their contact information in exchange for additional details about the company’s products or services. Whether you are an electrician, a restaurateur, a medical practice, or a multi-national oil conglomerate, the mission is essentially the same.
The primary client contact here, in most cases, will be the marketing management of the organization. Over the years, IT has slowly removed themselves from the responsibility of running corporate, information-based websites. Today, marketers spend more on technology than even their IT counterparts. Since marketing is now based on metrics, data, and analysis, the field has become much more technology-driven.
It’s also within this world that the largest area of divergence appears in terms of costs. Both licensing CMS platforms and procuring services to design, develop, and manage corporate websites can vary broadly. A local restaurant can utilize a system like Squarespace, while ExxonMobil utilizes Sitecore. On one end of the spectrum, total Squarespace licensing costs are minimal while Sitecore licenses can run into the tens of thousands of dollars.
Likewise, the services required to implement both systems vary greatly. A local college kid can configure a Squarespace site in a few hours. But an expert-level agency or marketing team would be required to configure Sitecore properly and maintain all levels of regulatory requirements with which large enterprises must comply. The pricing in this regard can range from $100 to easily in excess of $1M.
E-Commerce
E-commerce is also a broad category, and it usually encompasses at least two other categories mentioned here. E-commerce is definitely an application, and it has a marketing aspect as well. In fact, if a publication is selling access, I’d consider that e-commerce as well. So, in many ways, e-commerce is a strategy implemented by a feature, but I consider it a type of CMS application simply because it has a large contingent of platforms aimed specifically at fulfilling its mission.
Broadly defined, we’ll treat e-commerce as any application where one pays for the delivery of goods, services or content via the Web. E-commerce is a feature that is primary to platforms such as Magento, Shopify, or BigCommerce, and it’s offered as a secondary feature for most CMS platforms available today via plugins. WordPress, for example, provides WooCommerce and many others. Joomla and Drupal have plugins as well.
Online commerce requires special attention to security, both for transactions and user data. In this way, these systems are usually on the higher end of the budget spectrum to install and maintain, especially when you’re on a platform that updates often like WordPress.
Applications
This is another broad category that I use to define any web presence (or other channel, for that matter) that utilizes custom web development to accomplish a specific series of uses cases. For example, applications can be developed for custom e-commerce, but they can also be used to build communities, portals, SaaS offerings, intranets, or any number of other digital properties.
It’s important to remember that this category exists. Website owners and operators would be wise to treat their complex, custom-developed properties as applications, not just a simple website. Applications are created to solve specific use cases, after all —if your website is custom-built, the developer most likely needed to create something from scratch (or via heavy customization) to meet those use cases.
Applications are typically not built on top of existing platforms, as that can limit flexibility and functionality. It’s more likely that an application is built on a coding platform such as an MVC (model-view-controller) platform or similar framework. We see frameworks such as Laravel, Ruby on Rails, Symfony, and the like prevalent in this space, as opposed to off-the-shelf CMS platforms.
Publications
I’ll define this category as a property that gets its revenue from the creation and distribution of content. That can be text, photos, videos, and the revenue that can be generated from advertising, subscriptions, or any other monetization method.
Publications have a unique set of requirements: complex content creation and management workflows, content flexibility, multi-channel distribution, etc. With these types of projects, CMS architecture matters greatly, and any number of solutions makes the most sense, depending on the larger business requirements.
CMS Architecture Types
Now that we know the types of projects that are most often requested, how do you match an architecture to a project?
The best way to explain the possibilities are to summarize the architecture methodologies and match them to the use cases above.
Coupled
This architecture—typical of most web CMS platforms—is a platform where the back-end administrative portal and codebase are coupled with the front-end display functionality and codebase. This is best explained by example: WordPress is a coupled system where you can access the administrative interface by adding /wp-admin to your website URL. The administrative panel and the front-end logic code are sharing one installation and one codebase, thus the moniker “coupled.”
Most WCMS systems have this architecture. While many are taking steps to decouple and even go headless, historically, the architecture of these systems has been one where the only delivery method of content was intended to be Web.
Coupled platforms are best for marketing and informational sites, as well as publications where you are delivering content to the Web with no future delivery channels considered. Most marketing and informational sites do not need to worry too much about scaling for high-traffic levels. In most cases, marketing teams are familiar with WordPress or similar.
On the high end, enterprise-level software such as Sitecore are designed with marketers in mind. They develop functionality specifically geared toward the CMS, and they seek out partnerships with third parties specifically to deepen their offerings toward marketing teams. With Sitecore, for example, they have just inked a deal with Salesforce to be tightly integrated into their offerings. This holds massive appeal for those who are tasked with creating and maintaining an informational, marketing-driven web presence that has to play nice with the company’s existing sales and marketing tools.
We do not recommend this architecture for all purposes. E-commerce on a coupled CMS is possible, but most CMS platforms don’t care much for security. So, if you’re running an e-commerce project, a coupled commerce platform like Magento is fine, but adding a commerce module to Joomla wouldn’t necessarily be recommended.
Likewise, any security concerns you may have should make you second-guess a coupled platform. From a custom-coding perspective, CMS platforms are not coding frameworks. Be wary of over-customizing a platform at a foundational level when you could just use a code framework to build the same thing from a deeper level, in a better way.
Another area of concern when it comes to a coupled architecture is for those who want to heavily customize their front-end experience. These platforms typically have their own built-in way of doing things and as such, building a custom UI/UX can be difficult.
Decoupled
By definition, decoupled platforms separate the administrative layer from the display layer. Some coupled CMS platforms already allow this to happen—in a way. Sitecore comes to mind as one example. You can decouple any CMS that is open-source if you really wanted to, but at the risk of severely limiting its further upgradability and functionality.
Not many CMS platforms are sold as decoupled, and not many have an easy way to do it. But the advantages are there for those who know to ask for it.
The biggest advantage is security. A decoupled site can publish flat files to a third-party destination, completely concealing the back-end CMS from the world. That is powerful, especially if security is a chief concern of your company.
Another area decoupled excels is with complex, high-availability applications. If you have a web presence that requires a multi-server infrastructure with many layers of redundancy, it makes sense to have a decoupled admin panel overseeing this entire system. In fact, I’m unsure how else you would want to do it. In this way, a custom CMS excels, as it can be built around those requirements and the infrastructure you have in place.
Decoupled is overkill for most marketing and informational sites, as long as they are not worried about the CMS being vulnerable. But if your project includes building an application, it can make a lot of sense to consider this approach. Also, if your project involves multi-channel distribution, decoupled will facilitate that better than a coupled approach, as the method of decoupling can be utilized to power those separate distribution channels.
Headless
Decoupled and headless often get confused. The way I’d define the difference is that decoupled can mean any number of methods that separate the admin from the display. You could publish the site in flat files, you could do direct database connections from the front-end to the tech stack, or you could build some other method of data transfer.
Headless, on the other hand, is targeted at API-driven experiences, and the truest “headless” players are hosted applications where most of the heavy lifting is done for you. This means that you log into their platform, define content types, and manage content, and the API makes all of that data available to you.
This works well for a variety of situations. Let’s say you wanted to utilize the newest front-end technologies such as Angular, React, or Vue.js. API-accessible data from a headless system gives you a CMS out of the box that takes minutes to set up and requires no ongoing maintenance or oversight.
Another area the headless CMS architecture excels is in multi-domain environments. I find that having data available in such a clean, organized way makes it easy to share the content from one domain to another. Enterprises with many domains that need simple content management would do well to entertain the headless approach.
If you have a multi-channel distribution methodology, headless also makes a lot of sense. Headless systems store content in a clean way, which means it is platform-agnostic. The API connectivity gives you many options to pull content from the system. This plus heightened security, less ongoing maintenance, and costs all adds up to headless being the best multi-channel distribution CMS option available.
SaaS / Hosted
I hate to even mention it, as these are the bottom-feeders of the CMS space, but I need to throw it out there. By SaaS or “hosted,” I am referring to services such as Squarespace, Web.com, GoDaddy, and others that offer up an entire solution from hosting to CMS and in most cases, design as well.
These services are severely limiting, and not for any enterprise setting. However, since they measure as the second largest CMS architecture presently available, it makes sense to mention the possibility that rudimentary projects can be handled within this medium.
Conclusion
In wrapping up, it’s important to summarize the point of this post: CMS platforms are architected in different ways, and based on the type of project you are undertaking, you will benefit from knowing the difference between the various architecture types. What works for one project may not work for another, and knowing you have options is important to getting your project and business on the right track.
