CMS for the CMO, Pt. 2: The History & Architecture of Content Management Systems

p>This is a multi-part post aimed at helping CMOs understand the CMS and its technological implications, as well as how to procure the best CMS platform for their organization. Read part 1 here.

Last week, we began this series for CMOs by talking about the concept of the content management system as a whole. Much of that was focused at a high level on what a CMS is, what it isn’t, how it matters to your organization, and dispelling some common myths about web CMSs in general.

This week, we’re going to get into more specific detail about how the CMS actually works, including the types of CMS platforms and how they are architected from a technological perspective. This post should become your go-to guide in understanding the broad spectrum of products and platforms available to you, enabling you to make better and more informed decisions about your future CMS implementation.

Next week, we’ll wrap the series up by digging into procurement, including how CMS products are positioned and priced, how open-source licenses work, and what you need to do to find the platform or product that is right for you.

For now, let’s roll up our sleeves and get into where the CMS started.

First, Some (Condensed) History

I want to start by reviewing where the CMS industry gained its roots, as that will help us understand what options are available today. So many of today’s systems are still based on architecture from many years ago, so reviewing things in a historical context will make them easier to understand later.

Back in the early days of the mainstream World Wide Web—which, believe it or not, can be already dated more than 20 years ago—there wasn’t much in the way of content management. There wasn’t much content, either!

I began my career as a “webmaster” back in 1998, managing websites for a consulting company that specialized in mechanical engineering. The mainstay of the business was a series of intranet sites that we managed for clients that provided industry insights and findings. To say the least, it was content-heavy. There wasn’t much in terms of technical solutions for content management back then. In fact, we maintained the site by having thousands of HTML files, which linked back to a main index and other parts of the site manually.

My weekly regiment included uploading new content pieces, creating crosslinks, “tarring” up the site (basically, creating a compressed archive), and uploading to our clients around the world. They would unpack the files and the intranet lived on.

Despite the tedious nature of this process, I didn’t develop many gray hairs—I was just super bored. Ahh, to be young again…

WCMSs, or web content management systems, were created to change that workflow. As the Web grew, projects started to be developed to make these mind-numbing tasks easier. First, there was software such as Adobe GoLive or Dreamweaver, which amazed us with how they managed all these files for us. How cool it was to drag and drop new links instead of messing with A tags!

But those were just software packages aimed at HTML geeks. They weren’t content management tools in any sense. There were no real relationships between pieces of content, nor was there any thought of content types or modeling. You still needed a somewhat sophisticated level of understanding about web design and development to get anywhere.

Over time, as the problem became more and more prevalent, platforms developed to answer the typical use cases of those that managed web-based content. This meant that specific platforms were developed to handle specific problems. The advent of the “web log,” which we all know as “blog” today, brought about WordPress, for example. To this day, you can still see that WordPress is architected in a way specific to its history: posts and pages still are the backbone of the platform.

As the open-source platforms were being developed, private companies began playing in the same space. Sitecore, for example, can trace its roots back to 1998 when its founders started working as an implementation firm. Adobe and other enterprise players followed suit and before we knew it, there were literally hundreds of CMS platforms to choose from.

While we’ll dig into how CMS platforms are architected in a minute, it’s important to know that in terms of open-source or commercial CMS products, not much has changed from the core content-management perspective.

In recent years, commercial CMS platforms have been targeted more to CMOs (such as yourself) by focusing heavily on marketing-specific technologies. Open-source platforms have focused much more on extensibility, making them truer “platforms” in that they can be easily built upon. Commercial “products” haven’t focused on extensibility as much as they have on feature sets that help them demo and sell licenses more easily.

But one thing is common across all of these options: They’ve become more and more bloated as they try harder and harder to accommodate more use cases.

It’s worth noting—and we’ll review this in greater depth shortly—that commercial and open-source products that have roots going back more than a few years are all based on the concept of web content management, but not necessarily multichannel content distribution. The new world of mobile, set-top, or OTT devices and the budding Internet of Things (IoT) revolution has presented problems for many who need to start relying on their CMS to deliver to multiple channels, not just the Web.

While CMS product developers and the open-source community are working to make their systems accessible to other devices via API connectivity, since these systems were not created with this concept in mind, the architecture is being stretched beyond its original intention, ushering in what I would consider a pivotal era in the world of content management.

What are content creators to do?!

In more recent years, the SaaS concept has made it to the CMS space. Aided by the onslaught of new front-end technologies, the concept of headless CMS architecture has been mainstreamed by new providers who license CMS services much like any other subscription services. Primarily known as “headless,” but also known as “CaaS” (content as a service), this architecture is proving to be the newest wave of technology in the content management space.

Finally, the hosted self-service CMS model has evolved over time as well. Today, the leading players are Wix and Squarespace. These systems provide hosting and content management in one unified system. They also offer rudimentary scripting and customization, but the key word here is “rudimentary.” The total cost is so low, it isn’t even worth thinking about from a budget perspective. I don’t spend much time speaking about these platforms because for professional marketers, they are just a waste of time. Save them for your side project manufacturing dog collars, or whatever your part-time passion may be.

CMS Options by Architecture

Now to the exciting stuff!

The first concept you need to understand is the underlying architecture of a CMS system. This isn’t overly technical in nature, and I’m writing this with marketers in mind. It’s important for you to understand the differences in how these products or platforms are architected, and what that means for you.

To make things easier, I’m going to address these specific types of CMS architecture techniques, which are the most popular in terms of web content management systems:

• Coupled
• Decoupled
• Headless
• SaaS

Before I define each, I want to spotlight quickly what the key elements of a CMS are:

• Administrative Portal: The admin portal is where an administrator logs in to manage content. Primary functions are to add, edit, delete, and organize content. Workflows, user permissions, and other necessary features come into play as well. This is the core of a CMS.
• Delivery or Distribution: This is where the actual content is consumed by your targeted end user. For some CMSs, this is via an integrated theming engine that outputs HTML-driven pages. For others, it may be API delivery of content and data, which would serve the purpose of distribution (though it wouldn’t be a great user experience as a data feed).

See? That wasn’t so complicated after all. Now, some technically-minded folks could draw attention to even more feature sets and depth to the above architecture, but they probably are just interested in confusing marketers anyway!

Let me dig into each type of CMS architecture with a bit more detail.

Coupled

Coupled CMSs are also known as “monolithic” to many in the CMS industry. I think that terminology is a bit harsh, but in many ways, it is applicable.

The majority of systems available today are architected this way, including the most popular platforms such as Drupal, WordPress, Joomla, Sitecore, and even Adobe’s solutions. Here are some characteristics of a coupled content management system:

• Delivery and admin share codebase: If you have used WordPress in the past, you know that to administrate your website, you simply visit yourdomain.com/wp-admin. This is an example of coupled architecture, wherein the logic used to control your login to the CMS itself is the same logic used to present content to users on the front end.
  
  This is only possible in this manner via a shared codebase, or the front-end display utilizing the same code framework as the back end. This is the most common way to tell if your CMS is coupled as opposed to decoupled.
   
• Delivery has some level of a template-based system: In the same example as above (though also applicable to countless other systems available today), if your CMS has a template or theming engine, it’s highly likely that it is a coupled platform. This isn’t an absolute rule, and the reason I spotlight it as an indicator is simply because most CMSs that have a template engine were built for Web delivery only. Therefore, they wouldn’t qualify as a headless or decoupled solution without some additional features to accomplish that goal such as a static site generator.
  
  It’s worth noting that CMSs that feature template systems are usually more limiting in the front-end technology you can use, sometimes even requiring their own scripting schema. This is a good selling point for headless systems that focus on content delivery via API, opening up a vast library of front-end development options. Speaking of APIs…
   
• APIs are either not natively available or available as add-ons or afterthoughts: There has been a lot of talk lately about how APIs are coming to these platforms. Again, using our example of WordPress, the API was a late addition to the framework that was brought about by user demands and complaints that it wasn’t part of the platform. However, the system wasn’t architected around API delivery. It’s architected around what WordPress needed 10+ years ago. And worst off, these APIs aren’t meant to scale.

There are certain advantages to this architecture:

• Simple to install: You typically have a single-server environment where you simply unpack the software and it does the work for you. Some web hosts come preconfigured for the popular open-source systems.
   
• Coupled means less infrastructure to manage: As I mentioned on the previous point, most coupled systems don’t require anything more than a hosting account. The exception to this rule would be the large, enterprise systems that need administrator-level or root access to a server or special configuration.
   
• Lots of support given size of open-source communities or commercial products available: All of these platforms have large communities or corporations behind their development to provide support.

That being said, there are also disadvantages:

• Age: This architecture was meant for another era. Marketers, I know you don’t care much about multi-channel distribution, but you should care about security, scalability, and speed.
   
• Security: This is a major concern, as your admin panel is only as secure as the front-end experience. There are ways for malicious players to backdoor into your admin from the front-end experience, and when that happens, all bets are off. Can your company afford that risk?
   
• Fewer Front-End Options: There are fewer front-end technologies you can choose from that will seamlessly work with the platform. Typically, you’ll be stuck working within the confines of the templating solution the CMS brings to the table. The latest technologies, including all of those nifty JavaScript libraries, are typically a pain to integrate and manage.
   
• Upgrades & Updates: “Integrated” means if the CMS goes down or needs updating, you are risking your front-end experience (or your budget). And they need updating a lot, which is unpredictable.
   
• Stuck in the CMS Cycle: As CMS evolves, you may find massive updates or upgrades force you into a redesign or reimplementation. The CMS cycle is vicious, and if it feels like you have to rebuild your CMS every two years, it probably is because it’s true.

Decoupled

Decoupled CMSs obviously differ from the coupled systems mentioned above in one major way: they separate, or decouple, the administrative experience from the front-end user-facing display.

This can be accomplished a variety of ways. One way is to take a coupled system,and have it output files that compose a website for hosting in another location. There are actually ways to take a monolithic CMS and have it output static HTML files remotely. This would qualify (as awful as it sounds) as a decoupled architecture.

Another approach would be to separate admin and delivery by having the front-end access data (AKA content) either via an API or even a direct database connection on the back end. Using this architecture, you can have your CMS live in one place, locked down for security purposes, while having the user-facing experience in another location accessible to the world. This also means you have a world of new infrastructure technology to help you scale your web presence.

If you are planning worldwide domination, this approach can work pretty well. Some would call this a quasi-decoupled approach, claiming that the front end making any logical connection to the back end is just an extension of the CMS. I reject that notion based on the fact that a connection to a database or API on the back end isn’t sharing logic—it’s just sharing data, which is essentially what a headless system does, just in a slightly different way.

On that note, many confuse decoupled with headless. They are subtly different in that headless is often making content available only via API, and those systems typically will not have any influence over the control of the front end, such as how a web page loads or displays data. Decoupled systems, on the other hand, can offer heavy web page management functionality, including live previewing, if done correctly. Headless solutions don’t do this off-the-shelf (though you could build that if you were so inclined), and frankly, they don’t really need to.

In our practice, custom CMS solutions are, at a minimum, partially decoupled for most installations. This enables the CMS to live separately from the view, creating a separation of powers and ensuring longer lifespans for the CMS. It also means a higher level of security for the CMS itself.

In many ways, decoupled CMS architecture is not new. This approach is almost as old as content management in general, but because it’s more complex, it lost favor over the years. All the same, the advantages for a marketer, especially for multinational purposes, are plentiful.

So what are those advantages of a decoupled system?

• Solves many security concerns: CMSs can be locked down in ways vastly superior to integrated solutions. Even rudimentary firewalling of the CMS is a step in the right direction, something that is difficult with integrated systems.
   
• Lifespan: Decoupled CMSs that are separated from the view will have fewer updates and upgrades, and can last for many years—even through multiple redesigns of your website. We’ve seen CMSs live for 8-10 years when built with a decoupled methodology.
   
• Flexibility: There is a deep library of front-end technologies that you can lean on, escaping the mundane sameness of template engines.
   
• Scalability: It’s difficult to scale WordPress or integrated systems. Once you cache an integrated CMS, your multi-server options get much more expensive and complicated. Decoupled systems are scalable from day one, given that the CMS will almost never need to scale—just the user experience.

As with anything, though, there are disadvantages:

• Development: Decoupled systems are typically custom-built or accomplished by heavily modifying integrated systems. You’re going to own your CMS for a while (but that is also a good thing).
   
• Money: From a budget perspective, upfront costs are higher, though maintenance can be significantly lower over time.
   
• Resources: Requires more effort from an infrastructure perspective, though not much.

Headless

Headless architecture has been making waves in the CMS space for a few years now. In a nutshell, headless CMSs separate the entire admin experience from the front end, focusing on making content available via a data layer, or API. This enables developers to craft creative, original front-end experiences that are available not just to Web, but to virtually any platform that can call an API for content.

While multichannel content distribution is typically not a worry for CMOs, uptime and security are, and these platforms ensure a hands-off experience which should result in less stress.

It’s important to know that headless systems are not as feature-friendly or as impressive in a demo as any integrated system. That’s because the beauty and elegance of the solution is in the fact that they are separated, flexible, and extensible. Marketers are easily inclined to be dazzled by feature-heavy CMS platforms. The fact is, for a large majority of you, you’ll never use most of those features anyway. Large CMS platforms demo very well, but in reality, when you are given the keys to run wild, you’ll use the basic features 90% of the time.

Headless systems excel at the features that you need to be successful, and they give you the blank canvas to put them to work in a way that will benefit you.

Some of the other advantages include:

• Clean: I love to call these systems “clean,” in that you can determine how you will use them your own way. I think the most innovative products in the world have many uses and allow you to determine how they will work.
  
  Just look at Twitter—it has thousands of communication use cases. The founders didn’t even know what they had on their hands when they made it. Same goes for headless CMSs. It’s a blank canvas, and how you use it is up to you.
   
• Content is Future-Proofed: Because of the clean nature of this system, content is neat and portable. This is nearly impossible with coupled systems that were created with content models aimed at particular use cases.
   
• Scalable: These systems are architected on the back end to scale out massively, meaning you no longer have to worry about database clustering or replication, load balancing, caching, etc. If you have a high-availability requirement and are unsure how you need to scale in the future, headless is a great option.
   
• Great for multisite: Headless systems make multisite management super easy, an area where every CMS tries and, most of the time, fails miserably. Basically, it doesn’t matter how many sites you have, as the system will handle it from an organizational and load perspective.
   
• Hands-off infrastructure: Great for CMOs is the fact that you can leave your IT team behind, along with their corporate policies. The headless CMS is hosted by the provider and as such, they don’t even need access to it. Headache averted.

As much as I praise it, the headless architecture has a few disadvantages:

• Ongoing License Fees: You will need to license this technology from the provider, and that will be an ongoing commitment.
   
• Development: Headless systems will require you to develop a front-end experience. This means custom design and custom development. There are no themes to choose from. But as CMO of a quality organization, you shouldn’t ever consider themes anyway.
   
• Control: I’m a bit of a control freak, so giving up control of the core part of your digital ecosystem feels a bit wonky, at least to me. Pick a provider that has a stable business and avoid start-ups. You don’t want to rebuild in a year or two in if they go out of business.
   
• Integrations: Integration to most third-party systems has to happen on the front-end. For example, form submissions are best handled via front-end communication to your CRM directly. The CMS in this case is removed—again, we’ve cut it off at the head.

SaaS

Honestly, I don’t even want to talk about Wix, Squarespace, and all that play in that arena. It’s not worth our time, and it won’t do what you need. So don’t even consider it unless your budget is literally less than $100!

Why Architecture Matters

This entire post was dedicated to the architecture of these platforms, which is something that is essential for you to know as a CMO shopping for a CMS. Why? Because we want you to stop rebuilding your CMS every couple of years. And the best way to do that is to understand what the industry is selling you.

Your CMS is the foundation of everything digital you do. Remember our last post, where we defined how the CMS fits into your ecosystem. It isn’t an interchangeable part; rather, it is the core.

Choosing your next CMS wisely will have long-ranging effects on your organization and your roadmap to marketing success. Because you still may be unsure of what you need, here is a cheatsheet detailing each solution that will probably determine 90% of your procurement efforts. Refer to this guide in determining what structure works for you.

Settling on an Architecture: The Cheat Sheet

Coming Up Next Week

Next week, we’ll dig into the financial aspect of CMS implementations, including license models and terms, and top-line implementation project processes and budgets.

See you there!