CMS Architecture

You want to go headless but the big problem is you have a monolith.

Listen to John Williams go through 3 ways you can move from your legacy monolith to a fast agile headless MACH based architecture.

Headless vs Cyclops

Definitions

*Headless CMS: A back-end only CMS built from the ground up as a content repository that makes content accessible via APIs for display on any device. The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository).*

Cyclops CMS: A CMS where the body (platform logic) and head (frontend) are intrinsically linked together to power a singular, rigid, template-driven website.

When a headless architecture is the right choice:

Headless Architecture is a great fit for you if the following statements are true:

1. You’re looking to create lightweight, highly performant customer-first experiences.

2. These customer-first experiences are for one or multiple channels (from your website and beyond).

3. You want/need to leverage modern programming languages, frameworks and technologies.

Examples of a headless CMS include: Amplience, Contentful and ContentStack.

When a cycloptic architecture is the right choice:

If your business is only interested in operating a single website where you don’t need or want to create a differentiated experience, then a cycloptic CMS is likely a great fit.

Examples of a Cycloptic CMS include: Wordpress, Drupal/Acquia, Adobe Experience Manager (AEM), Salesforce, SAP, Sitecore, Oracle, Episerver, and Bloomreach.

Monolith vs Microservices

Definitions

Monolithic Architecture: A single-tiered software application in which the user interface and data access code are combined into a single program from a single platform. A monolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.

Microservice Architecture: A variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of services that are, loosely coupled, independently deployable, organized around business capabilities and are highly maintainable and testable.

When a microservice based architecture is the right choice:

1. You have unique requirements for your business.

2. You are willing to trade-off out-of-the-box features to build (and continuously update) the exact experience you want, and do so much faster than a monolithic architecture would be able to support.

3. You have or are aspiring to become a digital maturity of Level 3.

These attributes are vital for delivering customer-first experiences. Examples of CMS vendors that use a microservice based architecture include: Amplience, Contentful and ContentStack. Essentially, this architecture is more customizable, but will require a development team to levage the CMS of your choice and pair it with a frontend technology, language and framework to create your customer-first experience.

When a monolithic architecture is the right choice:

1. You have minimal unique requirements for your business.

2. You operate on a single “Web” channel.

3. You require little-to-no customization of features.

4. You don’t want to deliver customer-first experiences and create compelling customer journeys.

5. You have a technical maturity of Level 1 or Level 2, and/or

6. You want a standard website “grid” based experience up and running fast with the use of templates.

Examples of CMS vendors that use a monolithic architecture include: Wordpress, Drupal/Acquia, Adobe Experience Manager (AEM), Salesforce, SAP, Sitecore, Oracle, Episerver, and Bloomreach. Essentially, a monolithic architecture is more rigid by nature, and so it will become difficult, timely, and costly if you want to create customer-first experiences with the vendor’s out-of-the-box capabilities.

Cloud-Native vs Self-Hosted

A CMS that is cloud-native typically comes with lower maintenance costs and headaches as the software vendor maintains the product for you. Cloud-native providers are specialized in supporting their own products and services and typically your business will pay a monthly or annual subscription fee for the maintenance of the CMS in the cloud.

A self-hosted CMS is typically installed onto your own servers and therefore comes with increased maintenance costs, potentially greater security risks and patch upgrading cycles to keep the software up to date and operational with the latest features and functionality. Expect to maintain a team of development resources to keep your CMS up to date.

Some legal teams at larger corporations will often request ownership over the code or where the CMS is geographically located, which may lean your organization towards a self-hosted version of the CMS where you have access to the code-base.

Cloud-native vendors typically do not grant access to the source code but can offer reassurances for their customers by adding software escrow agreements into enterprise level contracts and allow you to select from multiple geographic locations as to where to host your data. This should provide peace of mind should anything untoward happen to your selected CMS vendor in the future.

API-First vs API Bolt-On

API-first content management systems are built from the ground up as a collection of API endpoints providing full coverage over the platform’s features and functionality. This grants businesses that leverage an API-first platform with more flexibility as they are able to programmatically hook into any part of the CMS that they need to request data from or send actions to. This typically makes it easier for development teams to follow industry-best practices when it comes to cleanliness of code and ultimately reduces implementation and on-going maintenance costs.

Platforms that develop APIs as a “bolt-on” are relegating their APIs to become second class citizens for their solution. A CMS provider with bolt-on APIs provide far lower API-coverage of their product feature functionality. This typically results in rigid functionality designed for a singular purpose and custom frameworks that require specialized developers. This creates longer implementation times, clunky work-arounds and increased costs for more custom projects that try to leverage a bolt-on API that must fall back on the monolithic approach when the API capabilities are lacking.

Not All APIs are Created Equal

Typically, a legacy CMS will largely follow the API “bolt-on” pattern such as SAP, Wordpress and Drupal whereas more modern CMS providers will provide an API-first approach including Amplience, Contentful and ContentStack.

Integration Approach & Partner Ecosystem

A traditional monolithic platform typically adopts a plugin based approach to extend functionality beyond what is offered out of the box. These plugins are built under the CMS platform’s own opinionated framework and they typically offer marketplaces where these can be browsed and installed with one click. This is great if you want to get a piece of functionality deployed quickly, but it can be hard to know who is responsible for maintaining the plugins underlying code that your business comes to rely on. Plugins typically interact with and affect multiple areas of a CMS, including the backend logic and the frontend views or templates. Installing multiple plugins over time can lead to compatibility issues and bugs which become more difficult to isolate and fix. This is due to plugins being granted large surface areas of access and control over various CMS components, leading to a tangled web that can become difficult and slow to support and maintain.

As mentioned earlier, MACH architecture consists of multiple microservices that communicate to each other, typically through lightweight serverless functions and UI extensions. Serverless functions are small discrete pieces of code that handle the data transformation and actions required between services via webhooks and queue based systems (such as syncing product catalog data to or from a CMS). UI extensions on the other hand provide administrators with more powerful content types where the underlying data is stored in another dedicated microservice. Amplience, Contentful and ContentStack all offer webhooks, serverless function examples and UI extensions to rapidly extend CMS capabilities and integrations with other services. These extensions do require a developer to implement and are best suited for a Level 3 technically mature organization to create, support and maintain. Typically the maintenance and hosting costs for these extensions is very low, given their size, scope and hosting requirements (i.e. run only on execution via Serverless, AWS Lambda, Netlify or Zeit functions).

The MACH Alliance is a not-for-profit organization whose members are committed to providing pre-built integrations between each member organization, making it far faster and easier to deploy a full solution that meets all of your business needs.