Everyone should be familiar with this slide – it is used by almost every vendor to compare different offerings (either within their own offerings, or as a way to differentiate from competitors). I happen to be using a version from BMC software, but any search for “SaaS vs. IaaS vs. PaaS” would pull up hundreds of instances of a similar chart.
Interestingly enough, this isn’t particularly useful in the context of WCM as it describes architecture, but not use cases. For example, both Site builders like Wix.com and HubSpot, as well as Content-as-a-Service / headless systems would all meet the definition of “true SaaS” but have significant differences in terms of real-world usage.
WCM is also somewhat different in comparison to many SaaS spaces in that customization of the solution (rather than configuration) is embedded into a lot of the idea of what WCM is, and the value it provides. More than merely the ability to control the front-end output, many WCM systems drive customer experience (which is where the line between “Web Content Management” and “Digital Experience Management” blurs) and these interactions often require integration with backend systems such as authentication, CRM, eCommerce, Customer Data Platforms, etc.
In other words, that “application” box contains a lot of complexity in the WCM space. It really needs to consider;
- Application (i.e. the WCM software itself running)
- Site instance management;
- Can you manage domains? Easily clone sites? Create new instances/domains for campaigns, etc.
- Ease of upgrades (even if not “true SaaS” – can this be easily upgraded, even “in-place”)
- Elastic scaling (both for infrastructure and the CMS license itself)
- Your front-end (visual) implementation
- Your back-end (business logic)
- Content Delivery Network (CDN) for site performance
- Your integrations with 3rd party tools (translation, CDP, personalization/testing, etc.)
Because of the complexity of these stack elements and need for extensibility, SaaS has not taken off across the WCM space as it has for some others in martech, where the default or only consumption model would be SaaS. This includes categories such as web analytics, CDP, content marketing platforms, customer journeys, etc.
Because of the complexity within the “SaaS” category, I’ll group by types and try to summarize advantages/disadvantages to each approach. Some of this content is copied from, or references a larger article on WCM sub-types but tries to expand on the differences.
Spoiler alert: They all exhibit compromises in some way – the trick is to find the approach that works with your organizational needs.
A Site builder is often a good choice for a simple business that wants a web presence with minimal difficulty. It will often handle tasks such as the visual design, domain registration and hosting as well, but usually at an expense of customization and flexibility.
However, this category should not be ignored or dismissed – although they all grew up in the small and mid-sized business (SMB) space, they are all adding more complex frameworks to enable a fair bit of custom development on a SaaS model or better support integration cases (such as with eCommerce). This includes things like adding development platforms such as Wix Corvid or features such as SQL databases and local development.
Advantages: Often a SaaS site builder can be an easy and cheap way to get a site online, usually with a decent visual design template. It’s appropriate for an SMB who has simple needs and just wants a presence with basic web, marketing (and sometimes commerce) functions. You can often get a simple site running with little to no code.
Disadvantages: Lack of robust API support. Support for customization and back-end processes is usually non-existent. For example, while you can use any headless CMS or WordPress as a content source for the static-site generator Gatsby, you cannot easily get page content from a site builder in a consistent structured fashion (or at all in some cases). This limits many of the omni-channel, multi-site, multilingual use cases.
So while it’s easier to do the infrastructure and basics of site design, it’s impossible to do some of the harder tasks that require integration or customization.
Content-as-a-Service (aka Headless)
Larger explanation of the philosophy around headless and a “COPE strategy” here.
In the context of comparison to “enterprise” or “hybrid headless” it’s important to remember that part of the “agility” that comes from using a headless CMS is not just the actual SaaS application, but in many ways the fact that pricing is clear and you can usually spin up new PoC instances extremely quickly (minutes) and often in a “freemium” model.
In many ways, Content-as-a-Service is the opposite of a sitebuilder – you don’t get any of the site management features of domain management or visual layout. However they do share many of the core expectations for a SaaS-first business in that editor performance is usually excellent, pricing is clear (usually cheaper, often with a freemium model) and extremely fast provisioning.
But where sitebuilders fall hard on APIs and content re-use in a multi-channel world, this is where headless systems excel. As a rule, their APIs around content creation and publishing are extremely robust, with numerous extensibility points into the application interface itself (to enable use cases such as integration with a DAM or other systems).
Hosted/managed “Enterprise WCM platform” *
(With an asterisk * as this definition for “SaaS” is the hardest to tackle)
Many vendors are choosing to address this in different ways, both for “managed Platform-as-a-Service” and long-term SaaS roadmaps. It could be said that the main differentiator of a WCM platform is the ability to have full control over back-end processes and integration as well as front-end. In the past, this has generally meant that the need for customization has conflicted with the desire for infrastructure agility, which is why true SaaS has yet to take off at this level.
Adobe, Sitecore, Acquia and Episerver have been dealing with this demand for more robust management by continually expanding the management offerings of their “platform-as-a-service”. A warning: some vendors do this better than others; for example, often application/implementation monitoring is not included, so while they will usually make sure your cloud instance is powerful enough and your database is running, they won’t necessarily actually ensure your site is running adequately (which is ultimately your end goal).
Episerver and Acquia also have expanded their SaaS add-on offerings around their core WCM. For example, Acquia Lift (Personalization) and Episerver Find (Search) are SaaS-only services provided on top of their WCM offering.
For their managed cloud offerings, Episerver does a good job keeping upgrades easy to manage. Acquia has a good model for multi-site dashboards with Cloud Site Factory. But in general, for any “managed cloud” offering you need to go through the list of requirements and services with a fine-toothed comb rather than making assumptions because you may find that must-haves are simply not covered by the offering or Service Level Agreement (SLA).
Expanding beyond the managed cloud model, Acquia and Sitecore have announced SaaS offerings recently. I like the model of the Acquia Content Cloud offering (currently in private beta) as it clearly fits in with existing Drupal investments – allowing an organization to start to work in a headless fashion, while still retaining the ability to work with existing investment and push content into those sites. The Sitecore SaaS strategy with a product release sometime in the summer of 2020 was announced at Symposium and indicates a different track from the current WCM codebase (while also *not* being built on the Stylelabs existing SaaS content and architecture model – based on this Sitecore SaaS FAQ).
Similarly, no timelines were indicated for when Experience Commerce or the Experience Platform (i.e. CDP and personalization/testing) will be supported on SaaS.
While many questions remain about the upgrade path of existing investment in Sitecore, integration with other platform elements, and how this balance of agility and customization will be achieved, the early indications on the developer experience presentations to the MVP community by Nick Wesselman, Product Manager for Developer Experience were well-received.
There are a lot of things to consider when looking at WCM systems, and to that extent “SaaS” is largely a meaningless term relative to your requirements. At this point it can largely be assumed that most companies have existing investments, and understanding the existing investment in content and processes is key to making technical decisions going forward. It’s not enough to say “we want to go SaaS” because there are so many definitions of what that actually means, and you need to really know what advantages are being gained, and what the trade-offs are because they will almost always be different than your current set of compromises.
Second, you need to look at existing organizational investments and processes to determine what you want to keep and what you want to discard and if this matches the SaaS models of vendors. Often, instead of doing a thoughtful “Marie Kondo” approach to curation (“Does this whitepaper or workflow process spark joy?”), organizations tend to treat replatforming as a purging exercise; burn down the house entirely and build a new one (then frantically scrambling to save some family heirlooms they forgot were actually important – usually content can be saved, but often context and SEO value from old URLs is almost always lost in the fire).
It could be that you build onto your existing investments in Enterprise WCM platforms to increase content interoperability (with hybrid headless) while leveraging other tools and services for net new investments. It could be that the vendor is pouring gasoline around your house in attempt to goad you to move into the shiny new rental property they are building and you’d damned well better be planning for a move and packing your furniture to flee the house on your schedule, not theirs.
Either way, more than simply picking based on a buzzword – understanding your needs, choosing and planning appropriately are the keys to success.