The Content Management System (CMS) has undergone a lot of changes over the past decade. This post will serve as a high-level look back to see how content management systems have evolved to support the needs of businesses and customers today.
On Premise CMS
Historically, on premise content management systems were comprised of multiple software installations that were installed at a customer’s location (on-premise or on-prem). I write about multiple software installations as there’s many moving parts to a CMS, but typically you have two segments – the Content Manager (CM) side where business users can create, edit, manage, and publish content and the Content Delivery (CD) side where the actual end content is delivered. Think a website and a database.
How does on-prem work?
A customer pays for a software licence and then has access to the software installation media and take on the services of their digital agency or their internal dev-ops teams to build up the infrastructure and perform the installation. Today, we refer to these types of CMS as a “legacy CMS”.
Web Content Management (WCM)
I’m struggling to think of a CMS from the on-prem era that wasn’t built to work within the web-browser, so let’s (for my old brain’s sake) that we agree that these systems were local software installs where users performed their content management duties via accessing the CMS via browser, known as the Web Content Management System (WCM).
Enterprise Content Management (ECM)
Very much the same concepts for WCM, but enterprise content management was built to support the needs of enterprise companies. Features that one would typically find in ECM over WCM are:
- Written in a more ‘enterprise’ language such as Microsoft .Net, Java.
- A de-coupled architecture of content management and delivery, to support globalrollout of websites and apps.
- A ‘multi-tenant’ system,meaningmultiple websites can be created and managedwithin a single system. It’s common for enterprises to own various different brandstake for example GM with Cadillac, Chevrolet, GMC etc.
- Advanced editing features such as departmental workflows, security and contentarchiving.
- Extension points to integrate with other systems are part of the larger enterprise,such as a (Customer Relationship Management) CRM, (Digital Asset Management)DAM system and/or E-Commerce tools.
Mass Market Cloud
Then along came cloud services like Amazon and Azure and they disrupted everything. Agencies like ourselves saw the Cloud as an opportunity to expand our services and take full ownership of our customers’ entire eco systems by installing on-prem CMSs into the Cloud.
This was a big win for Content Bloom for two reasons:
- We could now grow our service offerings.
- Our customers no longer needed specialized expertise to install and maintain their CMS infrastructures.
The cloud also offered key features that permitted automatic scaling and the ability to spin up clones, development versions, and create a custom CDN (Content Delivery Network) with only a few clicks.
It’s worth noting that CMS vendors also began to offer their own Cloud Managed services to their customers. In these scenarios, the vendor managed the infrastructure and agencies like Content Bloom provided the strategy, design and implementation.
Content Services (CS)
Then along came Content Services (CS) which allowed development teams to consume content and write applications in any language, without having extra knowledge of the inner workings involved with a dedicated CMS templating language. It also allowed sharing and syndication across web, mobile, and any device connected to the internet; referred to as Internet of Things (IoT) devices.
Earlier I mentioned Content Delivery, now think of your Delivery architecture as the CS and your applications that consume it. To give you a clearer picture, let’s look at an example. At one point, we once consumed content from an enterprise CMS and we did this to supply data to a chain of railway timetable style flip boards, located in stores for a global coffee chain. This situation and many like it, gave rise to the “Headless” approach for the CMS and introduced some very cool Cloud-based headless CMS vendors.
The Headless CMS
The CMS was the WCM (and it still is) that gave birth to dedicated Cloud-only CMS vendors (like Contentful) that offered the WCM and a Content API for which to consume content within your channels, applications and IoT devices.
Why Headless?
An on-prem CMS needs to be kept up-to-date in terms of security, third-party software updates (i.e., Windows version updates, technology framework updates, etc.) Not to mention updates to the CMS tool in terms of new versions and bug fixes.
Anyone who has ever had to upgrade a CMS can tell you that it can be quite complicated. The infrastructure scales the globe, the update itself has hardware and software dependencies and of course, a CMS should be up and running 100% of the time as it’s a business-critical system.
Feature Updates
I’ve not talked about feature updates in the CMS world but that has rapidly grown too, one great example is personalization. Now, I’m old experienced enough, to remember when personalization on the web was not on everyone’s radar. Whereas, today’s customers expect digital experiences to be tailored to meeting the needs of consumers across web, social, and even in-store interactions. Headless CMS gives companies the flexibility to do just that. It offers the ability to create multi-channel content for digital agencies and quickly build and design ways to present it.
Headless CMS requires no maintenance and no upgrades, it just works as is. Over time, features are added and existing features are fixed, one of the main benefits of the Headless CMS, is that it grows with the needs of the content management world, and it requires no attention to keep it up and running.
You might be wondering if there any drawbacks to the Headless CMS.
In my opinion the main points to note is that you don’t own anything. You’re essentially renting the CMS as a service, which means your data (Content) is not stored within your own system.
If your organization wishes to migrate to a new CMS vendor, you’ll need to build a way to migrate your data from the old system to the new, however, that argument is also true to on-prem systems. We’ve actually built a number of Content Bloom tools to migrate in and out of various Content Management tools, but it takes a considerable amount of effort.
Migrations of this nature are rare, and often only happen when a customer has opted to move to a new CMS at a time when their website is undergoing a major transformation, like a fresh redesign and/or a complete content overhaul.
Selecting a CMS
Today, on-prem and cloud CMS vendors exist together and while each have their pros and cons, it’s worth noting that since no two businesses are alike, the selection process depends on your companies’ specific needs and goals. In some instances, certain CMS tools are built around providing solutions to companies within a particular industry or country, for example the US has very precise legal rules around banking and data.
In all honestly, I could probably write an entire volume of books about the history of the CMS; get really detailed and delve into specific vendors, integrations, industries, digital experiences and even hands-on stories from client specific implementations.
But I hope this brief rundown has provided some clear insights into just how much Content Management has evolved to support the needs of businesses and consumers over the years.
If you’re eager to learn more, don’t hesitate to reach out.
