Experience Delivery — CMS Architecture Patterns

Since the advent of web applications there has always been a constant need to administer the content in a marketing friendly way. This was initially achieved by creating custom administration applications when content was still being managed in relational databases and delivered via custom application code. These were followed by content management systems that provided an administrative interface out of the box with the ability to publish and deliver the content to the web. Although useful at the time, these products were tough to manage as the management, delivery and upkeep of the content required heavy involvement from IT partners. Slow speed to market and meeting consumers needs and expectations became constant challenges for the marketers.

Fast forward to today’s digital marketing landscape, marketing needs has transformed to delivering engaging experiences to their customers at a rapid pace while supporting new delivery channels like IoTs, Kiosks, Digital Isles, Commerce, etc. Marketing teams are also maximizing their customer acquisition potential by incorporating personalization and targeted content delivery into their strategies. This inherently means that the path to publishing new content and enabling new experiences needs to be the path of least resistance with increased focus on process automation and delivering features in intuitive self-service business interfaces. To support this rapid pace of innovation, the following are some of the basic expectations that digital marketing and IT operations expect to support:

1. Content creation, authoring and publishing seamlessly without day-to-day support from IT partners.
2. Ability to personalize, measure and target content in a meaningful and engaging way with complete awareness of the customer needs and expectations.
3. Creating an omni-channel experience as the customers move through different stages of the marketing and sales funnel.

With these expectations in mind it is important to understand the different flavors of Content Management Systems (CMS) and for technical teams to pick the right implementation pattern that suits marketing team’s needs. Today, content management systems follow 3 different paradigms as described below.

Traditional vs. Decoupled vs. Headless

Traditional vs. Decoupled vs. Headless

Traditional CMS

These are typically page based Content Management Systems like Wordpress, Crownpeak, EpiServer, Kentico and a few others that are built around the concept of visually creating pages where content is tightly tied to a page. If the same content fragment needs to be used on a different page, the author must duplicate the content on the other page.

Traditional CMS platform encompasses both content management and content delivery capabilities and are tightly coupled. Authors can create content using a WYSIWYG editor which is stored into a content repository and rendered based on the associated page layout/ presentation template.

Pros

• All-in-one solution: Single platform that supports both content management and deliver with common licensing and infrastructure.
• Single tech stack: Usually built on a predefined tech stack which is easier for developers to adopt and built on a single technology.
• Ease of content creation: Greater flexibility for authors to preview and edit content in context with the presentation using content preview capabilities.

Cons

• Increased development timelines: Tight coupling between front-end and back-end application results in longer implementation time for even small changes.
• Content reuse: The nature of tightly coupling content with the presentation makes it difficult to reuse the content across multiple channels.
• Scalability: Scaling the presentation tier to support higher volume of site visitors involves setting up more publish environments which could increase the overall licensing cost.

Decoupled CMS
The need for Decoupled CMS was clear from the pains of ongoing maintenance and management of the traditional CMS. The tight coupling of the back-end (content management) and front-end (content delivery) in traditional CMS created a lot of overhead for development teams. Decoupled CMS separates the content management and delivery via a content API layer while maintaining the traditional CMS capabilities of content administration.

Platforms like Sitecore, Adobe AEM, Drupal, Opentext, Oracle WCS etc. have evolved to become a decoupled CMS over the years, retaining the front-end delivery layer (create pages using templates, pre-configured layouts with WYSIWYG editor), while allowing for headless content management at the same time. Content can be created in context of a page, component or content area and can be easily reused and delivered on a presentation template or via API.

Pros

• Best of both worlds: Decoupled CMS provides best of both worlds: the headless content management of a headless CMS and the WYSIWYG editing capability for authors of a traditional CMS.
• Enable marketing teams: Teams can deploy landing pages and microsites based on predefined templates on an ad-hoc basis. This capability enables faster time to market on the web and other touchpoints to provide a true omni-channel experience.

Cons

• Best of both worlds: Since the decoupled CMS is a combination of the traditional and headless CMS architecture, there are no significant cons for us to mention.

Headless CMS
Headless CMS is primarily used only for content management: authors will create content using a WYSIWYG editor which gets stored into the content repository. Content is presentation agnostic and is exposed to the front-end application (presentation tier) via RESTful API’s. Headless CMS does not have a native front-end, it delivers content via API and custom front-end applications are built and hosted outside the CMS platform using any framework and tools.

Growing number of devices and complex channels like IoTs, Kiosks, billboards etc. and other marketing demands need to support rich user experiences across all channels. Supporting these varying demands with a realistic approach and strategy calls for the versatility of a Headless CMS. There are open source and commercial platforms that exclusively support headless architecture, like Hippo, Contentful, Kentico cloud and Prismic.io.

Pros

• Front-end agonistic & faster development: Developers have the flexibility to choose their front-end framework and tools to support different devices and channels. There is less dependencies with the back-end team and the development cycle is much faster than the traditional CMS approach.
• Scalability: Since presentation is not tied to the CMS the front-end can scale independently to support a large volume of site visitors.
• Integration pattern: Using industry standard API patterns and practices which are widely adopted and are future proof.

Cons

• Content Preview: Content authors miss out on the capability to preview the content or perform inline editing of the content.
• IT Dependency: Marketers lose the capability to create pages using existing templates and components and the ability to publish to the required channels themselves. Marketer heavily relay on IT for creation of any new pages.

Choosing the Right CMS Architecture

Choosing an architecture that separates out the front-end (content delivery) from back-end (content management) is important in this digital age where we need to deliver richer, faster and more responsive user experiences across numerous devices and channels. With that in mind, Decoupled and Headless are the two options that are heavily debated and evaluated when considering an architecture pattern.

Consider the following criteria when assessing the architecture:

Decoupled CMS

• Frequent need to create and publish pages using existing templates and layouts without developer involvement.
• It is important for the authors to preview and approve the content in context of the presentation before it is published.
• Limited developer support as the site is managed by the marketing team with minimal IT overhead.
• Primary use cases are to support web and mobile with a limited number of devices and channels to support.

Headless CMS

• Support many devices and channels where the presentation layer could be different for each.
• Need a centralized repository for content storage without concern about the final presentation.
• Presentation layer need to scale for larger volumes.
• Dedicated front-end developers available to support building the presentation layer.

Considering a CMS platform should include a serious assessment into the platforms architecture. Your new platform may limit your company by impacting its speed to market and capability to deliver an omni-channel experience to your customers. Understanding your marketing teams needs and organizational strategy will be key in selecting the right platform. We at Slalom have partnered with many organizations helping them choose the right platform architecture that fits their need and successfully implemented platform solution.

Credits: Authored by Sridhar Andavar and Vivek Varadarajan.

Sridhar Andavar is a seasoned digital marketing technologist with Slalom. He has 15+ years of experience in leading large-scale digital transformation across Finance, Insurance and Retail domains. Specialized in delivering omni-channel customer experience leveraging marketing technology platforms like Content Management Systems, Digital Asset Management systems, Marketing Automation, Search and Personalization.

Vivek Varadarajan is a Solution Architect with Slalom’s Digital Experience Management Practice. He is focused on strategy, architecture and implementation of digital platforms that help clients manage, measure and deliver engaging experiences to their customers. Vivek has 15+ years of experience helping clients in Financial Services, High Tech, Retail and Consumer Goods industry.