Headless, SaaS, and why those aren’t necessarily a package deal

I’m seeing a misconception in the Content Management System (CMS) market among new buyers. It’s been around for years, and it doesn’t seem to be going away.

People are conflating two concepts:

• A hosting model, which defines how your organization relates to your software vendor and the environment that your website runs in. Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) are hosting models.
• A delivery architecture, which defines the relationship between where your content is managed and where it’s delivered. Headless and Coupled (and the less common Decoupled) are delivery architectures.

These are not the same thing. Engagement models and delivery architectures can mix-and-match.

I’ll explain both below. I think you’ll realize they’re so different that I’m essentially writing two unrelated blog posts.

Hosting models

Twenty years ago, you often installed your CMS on servers you physically owned. Then you would build your website using that CMS, and install it on the same server.

(I remember once standing in a cold data center loading Ektron onto a rack server from a CD-ROM. It took a while, there was nowhere to sit, and it was freezing. We’ve come a long way from this.)

A few years later, most organizations moved their hosting to external companies. It was basically the same model, but you just installed the same thing to companies like Rackspace, SoftLayer, and – later – AWS (Amazon Web Services) and Microsoft Azure.

This is what’s still known as On-Premise Hosting (often shortened to “on-prem”), even if it’s sometimes not actually on the customer’s premises. This is when the customer takes complete responsibility for their hosting environments – they build the solution, and they host the solution. In this model, the CMS vendor has no relationship to any of it, they just sell and support the software.

Today, this hosting model is far less common. As enterprise software gets more complex, and more services move to cloud computing, software vendors have built custom-tuned platforms to run their software. These days, you don’t purchase software, as much as you enter into an ongoing relationship with a vendor to build and install your project onto their platform.

This is called Platform-as-a-Service, or “PaaS.” (Usually pronounced “pass,” but sometimes with a “z” sound, so it rhymes with “jazz.”)

With PaaS, it’s still your project. You do your custom integration and coding using the software toolset provided by the vendor. Your options are wide open. You’re making all the decisions, and the only limit is what tools and capabilities the software makes available.

For some customers, their needs are more narrow. They’re willing to accept functional limits in their software in exchange for simply using a service as someone else designed it. Rather than building on a platform, these customers are renting a defined service for which they can’t write or install any custom code. Rather, they point-and-click their way around an interface.

This model is called Software-as-a-Service, or “SaaS.” (Pronounced “sass.” You know, like the thing we get too much of from our kids…)

SaaS software is limited by design. You’re accepting the conventions and opinions of someone else. So long as your needs line up with how they built their software, this might work out just fine.

But with SaaS, you don’t build on a platform. Your options are limited to how that vendor has allow you to re-configure their software. If their software doesn’t do a particular thing you need, then your plans will often need to change to fit how their software works.

(To be fair, these systems vary and some offer much more power and configurability than others. But the larger point this: you’re stuck with what they offer.)

A handy analogy is housing:

• On-Premise Hosting is like owning your own house. You can do anything you like, and whatever happens is your problem.
• Platform-as-a-Service is like owning a condo. It sits inside a building that’s owned and maintained by someone else. But you can do whatever you want inside your own unit. Knock down all the walls, install a basketball court, etc. So long as you don’t affect anything outside your own space, go nuts.
• Software-as-a-Service is like renting an apartment. Your landlord owns the building, and they own your unit as well. Your couch is too long for the wall where you want to put it? Tough, buy a different couch.

Now, let’s move on about something completely different from hosting: how your management and delivery environment intersect.

Delivery architectures

The management of content and the delivery of content are related but separable. How they intersect is known as a delivery architecture, or a coupling model.

In general terms:

• Management is everything you do to content before you press the publish button
• Delivery is what comes afterward – the processes and tools that convert your content into a consumable artifact (ex: a web page) and deliver it to someone who wants it.

These two processes can happen in the same computing environment (the same server or set of servers) or separate computing environments (on different servers, perhaps even in different data centers on different continents). How these two processes relate is an architectural question.

Twenty years ago, the most common architecture was Decoupled CMS. The management of content was handled by a CMS which generated content artifacts (HTML files, images, etc.) and pushed them to another server environment to be consumed.

In this architecture, the “brains” of the operation are on the management side. It decides what content to push into a “dumb” delivery environment. (To be fair, the delivery environment might actually be quite sophisticated, but the point is that it doesn’t have to be. All it has to do is serve up what it’s been given.)

This had some advantages in terms of stability and performance, but it had a limitation in that by detaching delivery from management we lost flexibility. We could only generate one version of our content, and we couldn’t count on a connected CMS for information about our users and how they should interact with our content.

As customer needs got more complicated, the industry moved to what’s known as a Coupled CMS architecture. This is where management and delivery happen in the same environment. Editors manage content, publish it, and then it’s consumed from that same system. Content is always attached to the CMS; visitors are just accessing the “other side” of the system.

This is, far and away, the most common architecture in use today. In this model, management and delivery are combined and work together – both sides use the same brain.

Since your delivery environment is connected to your management environment, you can do much more interesting things with your content, like customize it in real-time for different visitors.

In the last few years, there has been a trend toward Headless CMS architectures where the management and delivery environments are again separated, but instead of pushing content from management to delivery by the CMS, the content is pulled from the management environment by the website (or mobile app, or whatever is consuming it – known generally as a “channel”). The CMS just becomes a remote content database which exposes an remote endpoint (called an “API”) for channels to retrieve content.

With headless, the brains of the operation are in the delivery environment. That website (or mobile app or whatever) is pulling content from a “dumb” CMS as it needs it. (The CMS might not actually be “dumb,” but it can be, because all it needs to do is store content and serve up what it’s asked for.)

Headless architecture became popular as customers wanted to use content in more and more places, so they needed a CMS that wasn’t bound to any particular channel.

Additionally, JavaScript frameworks like React have become so powerful that raw data can be pulled into a web browser and templated there, rather than doing this at the CMS. And by separating management and delivery, customers can develop their delivery architectures using a different technology stack than what their CMS runs on.

A system can be pure headless, that never does any templating and only serves raw data to some other system. Alternately, a system can be hybrid headless that can operate in a traditional coupled architecture, but also has tools to serve content headlessly. You can have both architectures in one system.

Where they intersect

I’ll repeat what I said earlier – I basically wrote two unrelated blog posts above.

I hope it’s now clear that the hosting model and delivery architecture of a solution technically have nothing to do with each other.

However, in practice, the market is trending in certain directions and combinations, which is where the confusion has come from.

• Most all vendors are moving away from anything on-premise. You don’t buy enterprise software anymore; rather, you lease it.
• Most vendors building pure headless systems have embraced the software-as-a-service model. Given that their systems are performing a reduced set of functionality, these systems are easier to run as configurable services.
• Hybrid vendors trend towards the platform-as-a-service model. These systems lend themselves to more complex integration scenarios, so the ability to write code is a key benefit.

Exceptions exist. Some open-source headless systems can be installed on-premise. And there are traditionally coupled vendors who sell their software as a service. And while it’s rare, there are some hybrid headless SaaS vendors.

And, it’s particularly worth mentioning, Optimizely is a PaaS platform with all sorts of headless capabilities. So you can have headless, and still build and deploy your own integrated solution.

The key point: pick and choose how you want these two models to intersect. If you want more control over your implementation, don’t settle for a SaaS hosting model or a headless delivery architecture just because you think “Headless SaaS” is a sealed package deal.

It’s not. It never was.