CMS Buyer's Guide - Consideration #2
MACH vs Traditional Architecture
Once you have considered your technical maturity level, it’s important to understand the different types of architectural principles that are available to your business. We’ve broken this down further into four key areas. Before diving into a blow-by-blow comparison, let's summarize the two choices you have to make in 2020 and beyond.
MACH stands for Microservices, API-First, Cloud-Native, and Headless. To learn more about the MACH movement, check out the MACH Alliance.
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
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:
- You’re looking to create lightweight, highly performant customer-first experiences.
- These customer-first experiences are for one or multiple channels (from your website and beyond).
- 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
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:
- You have unique requirements for your business.
- 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.
- 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:
- You have minimal unique requirements for your business.
- You operate on a single “Web” channel.
- You require little-to-no customization of features.
- You don’t want to deliver customer-first experiences and create compelling customer journeys.
- You have a technical maturity of Level 1 or Level 2, and/or
- 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.
Transitioning from traditional architecture to MACH
If your organization has reached Level 1 or 2 technical maturity and is advancing to the next level, you will be faced with the choice of a full re-platform “rip and replace” versus a parallel approach often referred to as “dehydration” or “strangulation”.
Full “rip and replace” replatforming ideally allows your organization to have a clean break from the old platform over to the new platform, potentially cutting down on-going maintenance costs to run multiple solutions.
However, it is possible to keep your existing solutions and architecture in place and retain the system you may have already invested heavily into over the past 5-10 years. It’s easier to adopt a parallel approach to evolving your solution architecture if you’re moving to MACH, as you can tackle smaller pieces of the overall solution over time, rather than in one larger, longer project.
For Level 2 technically mature organizations that use Salesforce Commerce Cloud, Amplience offers a seamless integration with Salesforce’s Content and Content Slots that enable your team to begin to rapidly leverage the benefits of MACH without the need to completely replace Salesforce. This iterative, technology layering approach is less disruptive and fast to launch.
A word of warning - CMS vendors caught in the transition
Throughout 2018 - 2020 we have seen multiple traditional, monolithic CMS providers make bold claims that their solutions are in-fact already headless, when in reality they have simply bolted APIs onto their existing products. Some legacy CMS providers have either begun to acquire smaller headless CMSs or build their own from the ground up, which will take several years to reach parity with their original offerings. This has created a great deal of confusion for customers during their selection process as the pitches from these vendors typically contain a miss-match of legacy feature/functionality that is not compatible with the newer headless functionality (e.g. the admin experience and page builder are entirely separate from the headless APIs, therefore giving your marketing team no control over the frontend experiences should you chose to go with the headless implementation from one of these vendors).
Additional Considerations When Selecting Your CMS
One of the first and most important considerations is to understand your company’s technical maturity or whether your business strategy requires you to mature along the technical maturity scale from where you are today.
The next key consideration you must make relates to understanding your business requirements and exact circumstances.