Types of Content Management Systems: Traditional CMS, Next Generation CMS and Headless CMS
With almost 2 billion websites in existence and 100+ CMS vendors enabling these websites, it’s important to clarify that the intent of this post is to focus on enterprise-class CMS needs. That is how to deliver content and display content for mid-to-large companies that meet one or more of the following criteria either today or in the near future that require:
- Addressing complex technology and organizational needs (e.g., digital ecosystems requiring integration across many systems, dynamic websites, open data platform systems and other related digital environment).
- A highly unique digital presence from a design, experience and/or operational and asset management perspective.
- Support for multiple channels and content management needs beyond traditional websites. (e.g., mobile, mobile applications, native mobile apps, cloud native apps, tablets, digital signs, kiosks, social media, marketing automation systems, voice-activated systems, smart watches, virtual reality devices)
- A presence in different countries and/or require support of multiple languages.
- Support for omnichannel customer experience
- Updating website(s) and other digital environments on a regular basis.
- Collaboration across functions, countries and/or business units for web development and for creation and delivery of content.
- Scale.
What is the difference between the backend to the frontend for a CMS?
The common representation of an enterprise-class CMS typically includes reference to a backend and a frontend. When it comes to traditional content management systems, or “coupled” CMS, these two functions are part of the same vendor platform, intrinsically linked through custom code.
Backend Functionality:
- Storage: A database is used to store content and digital assets for content editors to easily manipulate. Digital asset management (DAM) system may be integrated with the CMS, and/or this may be part of the content management system.
- Content creation: An editor interface enables non-technical staff to create and edit content.
- Workflow and collaboration: Enterprise-class content management systems enable large, multinational organizations to collaborate across business units, regions, and functions for content creation, reviews, approvals, and translations as needed. To present content in this situation, highly structured content must be created but that can easily fall through if the collaborative processes involved are not well managed.
- Developer and designer interface: Developers and designers have the capability to create content and edit templates and modify digital experience designs.
- Backend code: Developers create code and/or utilize vendor-provided templates that serve as the foundation of the backend applications functionality. For example, code that enables managing content and form submissions and interaction with databases and other applications.
- Administration: Technical and non-technical staff use this area to manage the CMS application.
Frontend Functionality:
- Content delivery and presentation: This is where the entire experience created in the backend is delivered to the end-user whether for large sites, microsites, or single-page apps. Some parts of the site structure and style may also be created in the frontend either with or without backend interaction. (e.g., HTML, CSS)
- Input collection: The frontend is responsible for collecting input from the end-user, which dictates the user experience that is realized, either with or without communication with the backend.
- Frontend code: Developers create code that sits in the front end to manage communication with backend systems, control the user interface for the end customer, and enable the execution of applications that do not require a direct interface with backend systems. For example, in the frontend HTML controls layout on a website, the design is controlled by CSS, and basic interaction would be enabled through JavaScript. Single-page applications (SPA) and progressive web applications (PWA) are increasing the level of innovation available to developers in the front end, as well as the richness of end users’ experiences.
The Traditional CMS
As previously described, the first CMSs were developed to support one type of channel: websites. As a result, many of the industry’s first vendor-driven CMSs were designed as monolithic applications in which the user interface and data access code are combined into a single program to form a single platform.
More specifically, monolithic CMSs have been developed with the frontend and backend being designed into a single platform. At the simplest level, the front-end of the CMS access content from a database in the back-end, to be used within the layout (e.g., HTML and CSS) of one channel - the website. All content is pushed to the website in a predefined manner from a layout and presentation perspective.
The greatest disadvantage of a monolithic CMS (especially when compared to headless content management systems) is its lack of modularity, resulting in difficulty for reuse of application code and regular maintenance without disrupting application usage, and most importantly, significant challenges in supporting new business opportunities such as new channels and front-end applications (e.g., single-page applications or progressive web applications).
For example, as the number of web interfaces expanded beyond the personal computer (e.g., mobile applications, web-based applications), in addition to other types of channels, the monolithic CMS rapidly became cumbersome and detrimental to business growth. Owners of monolithic CMSs were forced to spend significant resources and valuable time to support these new channels demanded by their customers. Each new channel required new content delivery and presentation templates to be created by developers and designers as well as other related front-end coding work. (refer to the below figure)
Two other disadvantages of traditional, monolithic CMSs, in addition to their inability to accommodate new channels and business models, included:
- On-premises was the predominant model: Inability to support go to market in a cloud or SaaS environment. (more below regarding this)
- Designed mainly for developers thereby reducing the leverage of these systems by non-technical users. This also hindered companies’ agility to respond to market demands.
To overcome these challenges and enable companies to be more responsive to market demands, the current, the next generation CMS has evolved.
What is Important for a Next-Generation CMS?
The evolution of the “old-school” CMS has been driven by continuous innovation in the software industry, a hypercompetitive market of CMS vendors and the markets’ need for competitive differentiation from a digital experience perspective. (e.g., the need to support more channels and simplify digital ecosystem complexity)
The most innovative CMS vendors today either have or are working on development of next generation CMS capabilities to help their customers: optimize content for growth and revenue, go to market in a more rapid and efficient manner, and understand the “why” of what they’re doing (i.e., practitioner insights). The following are just of few of these capabilities that serve as differentiating points as you select your next CMS vendor:
- AI-Driven Personalization (artificial intelligence): End users and buyers are overwhelmed with digital content and on-line choices to get their information and to make transactions. One of the greatest opportunities for companies to engage their audience and differentiate their products or services is to customize the digital experience. The best CMS vendors have included the ability to personalize content and related digital experiences into their solution, using machine learning and AI, including tapping into internal, external and behavioral data to create personalized experiences on the web, mobile devices or any channel at the micro-segment or even individual level.
- Back-end extensibility for ease of integration: Extensive, stable and comprehensive APIs which provide the foundation to "play nice with others", be it the latest and greatest marketing software applications or legacy IT solutions.
- Business level enablement: API level interoperability alone is not enough: A CMS needs to enable business users to interact with and benefit from third-party tools through seamless integration. That is, interoperability from a business user perspective with minimal to no IT involvement for example.
- Microservices-based architecture: This architecture must support scaling and extension when needed, forming the building blocks of an agile digital marketing technology ecosystem.
- Cloud and SaaS Scalability: The advent of cloud and SaaS models have enabled lower cost models through subscription fees and less capital costs, more rapid set-up and deployment, greater accessibility by developers and applications users, easier application of software upgrades, greater software ecosystem integrations and increased scalability.
- Ease of Use: There are many potential users of a CMS, such as developers, administrators, marketers and/or e-commerce managers. A next generation CMS will enable these users with rapid and easy installation; start-up and adoption of its capabilities, such as through an intuitive user interface and ease of accessibility from multiple devices; as well as easy maintenance. Ease-of-use features are also included in other areas already covered in this list.
- Automated content creation: Tapping into the power of artificial intelligence and machine learning to ease the process and increase scalability for creating and delivering content across multiple businesses, channels and countries.
- Offer the option of a Digital Experience Platform (DXP): A DXP is a core set of software technologies that orchestrates the creation, delivery and optimization of personalized, content-rich digital experiences anytime, anywhere to delight customers, compel them to action, and enable a company to outperform its competition.
What is a Headless Content Management System?
A headless CMS provides all of the capabilities of the backend of a traditional CMS (i.e., the “body”), while giving the responsibility for content presentation/layout to the delivery channels (i.e., the head). For clarification purposes, “traditional CMS” from this point forward will refer to the next generation CMS described in the prior section, with back-end and front-end as part of the same platform and vendor.
Content is no longer pushed out to a channel in a predefined manner. Content is pulled or requested from the CMS by any channel, by way of a RESTful API, enabling each individual channel to take advantage of its own unique presentation capabilities. A RESTful API is an application programming interface (API) that uses the internet protocol HTTP to request data for a data source - the CMS in this situation.
In a pure-play headless situation, the headless CMS doesn’t generate any front-end code and provides content as a service, which is why headless CMS is sometimes referred to as “Content-as-a-Service” (CaaS). This process results in the best available digital experience for the end-users of a particular device since front-end developers are able to continue developing new functionality for any channel independent of the core/backend CMS.
As Wikipedia indicates, “a headless content management system, or headless CMS, is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.” Headless CMS can also be defined as only having the ability for creating, reading, updating, and delete (CRUD) content, while downstream channels that pull content from the headless CMS are responsible for its presentation to end-users.
Why is a headless CMS needed and how is it different from a traditional CMS?
Why are headless CMS solutions of such high interest to so many people in today’s market? At a high level, a headless CMS is the best way to future-proof your digital experience architecture, enabling support of any channels available today or in the future. (i.e., omnichannel content management).
Just as important, developers, experienced managers, and e-commerce managers will be able to create more interactive experiences for customers in a shorter time and with less investment, reducing time to market and giving you a competitive edge. More in-depth reasons why a headless CMS platforms are of such significant value include:
- Enabling content-driven digital experiences on any channel, today or in the future -> Content-as-a-Service: Most enterprise organizations are burdened with the traditional, monolithic CMSs that cannot support new channels. (e.g., mobile, mobile applications, tablets, digital signs, social channels, wearable devices, voice-activated devices, Internet of Things (IoT) devices) A headless CMS, by nature of its backend design, is capable through APIs of providing access to content for any frontend/channel. And the same content can then be used across any and all channels.
- Faster updating of the user experience (UX): Changing the user interface (UI) of a channel that is part of the frontend of a traditional, monolithic CMS or content repository is time-consuming and costly; and even if possible, optimal use of a new channel in this traditional scenario is unlikely. With headless CMS, the UI can be changed without changing the underlying (headless) CMS implementation, thereby increasing digital experience agility.
- Leveraging the most innovative UI frameworks: Online Experience offers businesses the potential for competitive differentiation across digital channels. And the best way to enable optimization of this experience is to give front-end developers the opportunity to use the most advanced front-end tools. In a headless CMS architecture, these advanced tools can be easily leveraged in channel or device (frontend) with little to no impact on backend functionality. Two examples of this are the use of single page applications (SPA) or progressive web applications (PWA).
- In an SPA, a website or web application located on a single page is dynamically updated - i.e., regular full-page loads from a server are no longer necessary, and only part of the site is dynamically updated to create more consistent and more engaging user experiences.
- PWAs are “web applications that load like regular web pages or websites but can offer the user functionality such as working offline, push notifications, and device hardware access traditionally available only to native applications. PWAs combine the flexibility of the web with the experience of a native application.”
- Overcoming technical or scale limitations at the front-end: Front-end applications may have UX or technical limits. Headless CMS offers the opportunity to bypass these limits. These limits may be imposed by e-commerce applications or portals, and result in negative business consequences or higher costs.
Headless CMS solutions can be used to enable a content hub that can inject content into an existing CMS as well as other channels. Companies can also use a headless CMS in parallel with their existing CMS to trial and/or replace traditional CMS systems.
Since the CMS is no longer responsible for the front-end, the channel which ultimately uses content from the CMS must create the layout and presentation layers. This may be accomplished by interactive Javascript frameworks (e.g. React, Vue or Svelte ), static site generators (e.g., Gatsby, Next Js, or Hugo ), workflows, serverless, and Edge functionality (e.g. Netlify, Vercel or AWS).
WebriQ - a Headless CMS Competence Center for the SMBs
SMBs typically do not engage with lengthy enterprise buying processes and it is not economically viable for vendors. Buying processes are often led by end-users and developers who simply want to test how a solution works and get it up and running fast. It’s also an approach that is beginning to eat its way into how larger enterprises buy solutions, too. The way customers buy software has fundamentally changed over the past decade. WebriQ eliminates frictions in the buying and the implementation process all the way.
WebriQ has solved the two major obstacles to Headless CMS implementations;
- Single vendor implementation
Headless implementations are typically handling multiple vendor relationships and pricing conversations which make makes the overall Total Cost of Ownership difficult to determine quickly and accurately. With full products, W-Studio and C-Studio, WebriQ overcomes this obstacle in a big way.
- Page Management
Using Page Management, you can empower editors to create and manage pages for your digital solutions using reusable building blocks.
With headless CMS page management, content editors can manage your site's page tree, and page-level SEO properties, and determine what content and functionality will be on each page. Content delivery becomes a breeze.
Compared to traditional CMS, a developer and architect will still have full control over what page templates are available to the editor, where they can place modules within the page, and what the modules can do. To sum up, the benefits of Page Management:
- Empowered editors who can do more without a developer
- Happier developers who can focus on new functionality and enhancements, and less time responding to new website content requirements
- Increased productivity for the website and the team behind it
- Fewer resources/expenses required
WebriQ has a full product offering for building Microsites and Landing Pages on a Headless Infrastructure. It is a low-cost and low-risk entry to a Headless strategy for your enterprise or organization.
The architecture of WebriQ Studio is built on the headless CMS principles, but also around the MACH philosophy.
What is MACH?
MACH is a set of architectural technology principles coined by commercetools that stands for Microservices, API-first, Cloud-native SaaS and Headless.
This acronym achieved widespread appeal within the commerce vendor market (here’s a short summary on what MACH architecture is for those that are not familiar).
The important thing to note with MACH is the close association with the @MACH Alliance and the relatively high barrier to entry for vendors and customers alike. The requirements to join the MACH Alliance today firmly set MACH into the Enterprise end of the market.
The MACH Alliance homepage itself highlights this Enterprise focus as a counter to legacy solutions: “Enterprise suites are no longer the safer choice. The MACH ecosystem is,”
The requirements to be a part of the MACH alliance,as well as the policing and enforcement of these requirements, helps to eliminate potential confusion in the marketplace. It actually means something to become a MACH-certified member. The MACH Alliance is like the Apple App Store: a walled garden that ensures high-quality members meet the requirements, helping to establish trust with retailers and brands.
WebriQ Studio has four major components:
- Sanity and Sanity Studio for the headless CMS
- Next Js as the production framework
- Serverless forms and payment forms through AWS
- Netlify for the entire publishing workflow and Edge functionality
The content schema is prebuilt and serves as the core of the publishing tool and as the only UI that users need to learn and understand.
For each page you build, you can choose from 20 different components and each component has 5 different variables.
Examples of pre-configured components are Navigation, Header, Footer, Text, Call to action, Testimonial, Portfolio, FAQs, Blog, and more.
Each page with a distinct URL can be populated with one or multiple components. All components can be reused on other pages and all components that are uniquely tagged are updated throughout all pages when content updates are done to that component. All components can be uniquely designed and branded through a Windtail CSS library.
All pages can be previewed before publishing.
SEO settings can be done on all pages separately and there is an SEO preview functionality embedded.
Last but not least, we provide the possibility to publish your WebriQ Studio to any TLD or subdomain of choice and all WebriQ Studios are de facto integrated with WebriQ analytics.
Pricing of WebriQ Studio
WebriQ adopts value-based pricing throughout its entire service portfolio, including WebriQ Studio.
Each customer will receive an unlimited service, for an all-in fixed monthly recurring fee. We use a unit-based approach to make creating unique and customized service packages as easy as possible. Each unit is valued at $1,000. Units can be broken into ½ units, ¼ units, or ⅛ units.
We come to value-based pricing by analyzing and quantifying any or all of the following criteria
- Expected usage of the product
- Branding and design of all components
- Additional Data modeling needed
- Data migration complexity
- The complexity of additional features requested
- Further API integrations needed
WebriQ Studio can be expanded to a full-blown structured content data model to satisfy all digital experiences needed by your customers
A couple of examples to illustrate live implementations of large content models
Over 400 different products with multiple variations for each product, indoor and outdoor versions, and much more. All data is stored in a data lake, accessible through APIs to multiple web assets and storefronts.
A complete product configurator with RFQ
All data is stored in a data lake, accessible through APIs to multiple web assets and storefronts.
Request a DEMO of WebriQ STUDIO or get access to a Sandbox account