Business Reasons for Adopting a Composable Architecture for your CMS Site

Choosing a composable architecture isn’t like waving a magic wand. Your site won’t suddenly rack up leads or drive sales growth because it’s composable now. So don’t expect golf claps in your boardroom because you announced that your site uses a composable architecture.

You should go with a composable architecture for a few simple reasons:

1. It lowers your costs by reducing the time it takes for upgrades.
2. It gives you more options to swap vendors as your business changes.
3. It offers better performance, especially for your mobile customers.

If you had those capabilities, you could go to market (GTM) faster because you could spend less time on software maintenance and more time on functionality and business growth.

You may be wondering if composable is worth the investment, thinking, “I have complete control over our site. We are on the latest {fill in with your top digital experience platform (DXP) Content Cloud vendor here}, and we make frequent changes to the site.” I agree that’s a lot of power, but what happens when you must wait for that feature, bug fix, integration, or God forbid, a security patch from that favorite content cloud vendor? That’s when you realize how much power you have — not as much as you think. Then you ask yourself the age-old question, “Should we build or buy a new digital experience platform?” Or perhaps, in our modern world, you should do a combination. That’s where composable architecture comes in.

To familiarize you with composable architecture and its benefits, I’ll summarize what composable architecture is and discuss the three reasons to go composable. Then I’ll delve into the role that your traditional content management system (CMS) plays as a constraint and put the practice of composable architecture in strategic business language.

Composable Architecture

Composable architecture is built of units of software that are independently replaceable and upgradeable and often backed by microservices or are microservices. In 2023, a composable architecture will usually be synonymous with JavaScript, the primary language for consuming services and data to create HTML.

Remember when widgets were first introduced into a page in the CMS world? As an author, you could replace different content on a page by simply dragging and dropping widgets. This provided a lot of power and allowed companies to change the content on their site at will. Simply put, they were able to go to market faster.

Now, businesses are demanding increased flexibility from the software industry, especially their CMS vendors.

Reasons to Go Composable

There are three reasons why I think you should pursue a composable architecture: lower costs, flexibility, and performance.

Lower Costs

Often, CMS-powered sites are built with several pieces of software that depend on each other to function. When doing an upgrade, the versions of these dependencies need to be in sync. Often, that can mean upgrading them as well. This is when things can become extensive and too costly. Instead of upgrading and testing a set of functionalities, you must do a complete upgrade and regression test. As you can imagine, this drives your costs higher. A composable architecture lowers your costs by reducing the number of dependencies or reducing the impact on maintenance that the dependencies have which makes updates faster and easier.

Flexibility

Moving to a composable architecture can simplify the responsibility of your CMS by removing the presentation layer and associated dependencies. If you need a CMS upgrade, it becomes far more straightforward. Or if you need to change out your CMS, it becomes easier. Thanks to composable architecture you’ll no longer feel like you’re a hostage to your technology vendors because you’ll have the flexibility to make changes and switch to the tools you want when you want.

Faster Performance

Regarding performance, developers will quickly talk about static generated pages and the edge network. Both are older proven technologies. Static page generation was prevalent in the late 1990s and early 2000s. It’s the process of creating your webpage, storing it as HTML on a file system, and serving it when requested. This was abandoned so companies could offer more personalized web experiences. These personalized experiences were generated on the server at the time of the request. Now it’s possible to generate personalized experiences from a user’s browser.

Regarding edge networks, I was part of a team that implemented caching using Akamai in 2004. Its business model was to have caching servers co-located in the ISP closest to the requestor. Two decades later, that same model is now called an edge network. From my understanding, the main differentiator for edge networks is the ability to run functions. Some vendors' functions are limited but can still provide great value. Static pages on an edge network are cached pages, and therefore, you could argue that they aren’t served any faster than traditionally cached pages if they’re on an edge network.

Don’t get me wrong. These solutions take advantage of the network layer, which plays a vital role in performance. For example, the most significant Denial of Service (DOS) attack in recent times was against GitHub. They had their pages cached with Akamai, the DOS was foiled, and their customers didn’t notice any degradation in service. Taking advantage of the edge network is a great option.

A positive side effect of this approach is that when implementing a composable architecture, performance is a higher priority for developers early in the process. They aren’t trying to shoehorn performance tweaks into your site before it goes live. With a composable architecture, your web pages are generated and stored on the edge network, allowing mobile users to pull down the requested HTML pages quickly.

The Role of Your CMS

The top CMS vendors that also have a DXP typically control the creation of HTML for a webpage. It’s the process of your code binding together content, data, and HTML and is done on the server (head). Often, this is called the delivery layer. This has changed in the last several years since the headless CMS was introduced. A headless CMS is a CMS that’s no longer responsible for the delivery layer but only for retrieval, storage, and organization of content and data that supports your site.

You might be asking, “What would be responsible for the delivery layer?” Your development team will often choose a programming language, frameworks, products, hosting model, and CDN, where most of the delivery layer happens via hosting and microservices in conjunction with JavaScript that will generate your webpages and store them in the edge network. This means your end users will no longer have to wait for their request to return from the server because it will be instantaneous. This is critical for creating a great digital experience for mobile users on lower bandwidth networks.

Business Reasons

Now, I’ll talk about composable architecture, from a business perspective. Your CMS vendor is a supplier. As a supplier, you rely on them to deliver functionality promptly. That functionality, in turn, allows you to deliver your products, services, marketing, or some combination of the three via your website. If you run out of supplies or lack enough, your company can go slower than desired or grind to a halt, allowing your competition to catch up, and steal revenue and market share. You want control over that supply. I have mentioned that the causes of these slowdowns are the CMS vendor’s architecture combining the delivery layer in the CMS. The reality is that maintaining the delivery layer within a CMS is becoming far less effective for the pace at which business runs today.

The complexity of standard CMS architecture causes long upgrade cycles, often costing nearly as much as the original price to implement it in the first place. Your business can reduce upgrade time and costs by going to a headless CMS. You can create the delivery layer on your own or work with other vendors, or their traditional CMS vendor to go headless. Because a headless CMS only delivers the content and data to your site, it increases reliability and allows your business to find a more appropriate technology stack for the delivery layer and supporting infrastructure — one that can keep pace with your business’s needs.

Changing to a composable architecture has some favorable business outcomes. First, it improves your bargaining power with your CMS vendor since it lowers their responsibility and complexity. Second, because it is less complex, it reduces your dependency on a single supplier. Moving to a different supplier for your services is possible without a large migration overhead.

I believe a headless CMS is for mid-market and enterprise companies. Why? At the time of this article, doing this type of architecture requires the right expertise and management of resources. In this architecture, complexity is moved to the presentation layer. Support for this type of development is growing quickly, but it’s still relatively new. Therefore, the short-term costs are higher for this type of architecture, making it challenging for small companies and start-ups to afford. Another reason headless is for mid-market and enterprise companies is that most businesses use a composable architecture to get a collection of best-in-breed services instead of bundled services from a single vendor. A bundle always comes with a price break that suits smaller companies, but the value is only realized if you use most or all the items in that bundle.

Why Composable Architecture Will Save You Time and Money in the Long Run

Given the complexity of a website, the software industry looks for ways to segregate functionality so that it is less complex, scalable, performs better, and lowers costs. Moving to a model where the responsibilities of the presentation layer are delegated elsewhere, and webpages can be put together on the server with the resulting HTML stored in the edge network means lower maintenance costs and less responsibility for your CMS.

Regardless of your company’s size, if you choose a headless CMS, over the long term, you’ll see returns on your investment with lower maintenance costs and lower risk. You’ll also gain the ability to switch vendors with greater ease as your business changes.

Want to know more about the benefits of a headless CMS? Reach out. Our experts can walk you through all the reasons to make your CMS composable.