Technical architecture in action: Monolithic vs Headless

Modular components, headless front ends, and integrations make the new standard in commerce architecture flexible and future-proof. But how? This article will outline an example framework in simple terms and show how it provides value in terms of resiliency, accelerated time to market and process improvement.

How does a traditional, monolithic software ecosystem compare to a modern, headless setup?

Monolithic commerce architecture — definition & drawbacks
Modern headless architecture — definition & advantages

The technical architecture for large enterprise-level organizations has undertaken a massive reconstruction in recent years. Headless commerce and composable solutions reduce complexity and make your architecture more efficient. This modularity makes your digital ecosystem scalable and future-proof. But what does that mean?

First, let’s start with understanding what a traditional, monolithic commerce architecture does and why it is handcuffing companies.

Monolithic commerce architecture

“Monolithic architecture is the traditional model used by most software programs. These solutions are generally large and self-contained. The platform may have many modules, but the modules are all interconnected. A change in one module usually necessitates a change in other areas and may require you to redeploy the entire solution. “ - OROCommerce, eCommerce Site Architecture

Traditional monolithic architecture | Acro Media

All-in-one or “coupled” systems worked well in the early days of technical architecture, but now they present some significant drawbacks.

Bulky, complex and slow to change.

The overall system is large and complex, and it is hard to make changes quickly and correctly. Development teams are often caught up in bug fixing and trying to improve how each part of the system works since they depend on each other.

Limited innovation and the inability to use new technologies.

Adding a new system or piece of software takes much more work, and often, custom development is required. Frequently, legacy systems will not easily integrate with new technologies, making it impossible to innovate. You wind up needing more manual data entry processes to use a new piece of software, meaning more work to use a tool meant to increase efficiency.

Hard to maintain and update.

In a coupled architecture, defects can take down the entire system, and each major update can require a complete code redeployment, making continuous development difficult. Because of this reliance, updates to each piece of software in the infrastructure become much more complicated, and more time is needed to figure out the effect of issuing an update to a single part of the system. The extra time this takes makes updating monolithic architectures time-consuming and fraught with potential downtime.

Examples

Sage, your accounting system, has issued an update. It is mandatory for security reasons, so your IT team decides to do the update. The only problem is that this security update reveals a bug, and the update cannot move forward. You now need to allocate developers to figure out what system the bug came from and fix it, delaying the upgrade. Imagine that scenario happening for every update you may need to do to your entire system of platforms. You get a good idea of why monolithic architecture is slow to change due to its bulkiness and complexity.
Your new ecommerce system needs to access your ERP to pull product data and customer pricing information. But, your ERP is older than time, and the vendor has not made any updates available to integrate with newer systems. Your development team needs to figure out how to get the systems to talk to each other directly, slowing down the time it takes to bring the new technology online. The alternative solution is to add a manual workflow to get the data from one system to another. Adding these kinds of swivel chair processes reduces the effectiveness of any new tool.

Modern headless architecture

“Headless commerce architecture is the decoupling of a website’s frontend presentation layer — which includes items such as text colours and styles, images, graphs and tables, buttons, etc. — from the backend ecommerce functionality — pricing, infrastructure, security, checkout, etc. “ - BigCommerce, Headless Commerce: How to Create Unique User Experiences with Your Ecommerce Platform

We used this exact setup for our website in a recent upgrade. Read the case study here.

This headless architecture setup uses (but is not limited to):

A database where information, content and digital assets are stored.
Drupal 9 content management system for content creation.
A robust and full-featured design system for ease of branding and speed-to-market.
An API connects the content management back end to our front end of choice, React.

While we have chosen React as our front end, this setup allows us to connect to our publishing backend easily and effectively adapt to future technology.

While this is how we did headless architecture, this example doesn't show how a composable solution overcomes the downfalls of traditional monolithic architecture. The following graphic shows how various pieces of software and platforms work together in a headless architecture. Simple, common and robust examples show how this type of architecture grows with your business.

Options for headless architecture | Acro Media

Data is entered into each unique system as needed. APIs and microservices move the data through middleware and server rendering to the presentation layer, which could be your website or any other digital channel you choose.

Reduced complexity and easier to make changes.

In a decoupled architecture, each piece of software acts as a component of the whole. As the diagram above shows, this reduces the dependencies and means that if you need to make a change or upgrade one piece of the architecture, you only have to work on that single component. Your development team won’t get bogged down in chasing bugs from how software A interacts with platform B.

Innovate and add systems at will.

Adding a new system or piece of software becomes easier since you plug it into the database and configure an API that links to the front end. You can bring new functionality online faster than ever by not worrying about how new applications will interact with your other systems. This modularity also allows you to start small and add new functionality over time.

Swap systems and evolve your architecture.

Similar to adding systems, a decoupled architecture makes replacing systems easier over time. Developers can build middleware connecting the new system’s API while the old system is still in use. This parallel work eliminates the need for your operations to come to a standstill. When it’s time to make the switch, the new system is activated while the old system remains available should you ever need to switch back.

Easier updates and maintenance.

Because each piece of software is a component of the whole, there is less of a chance of a flaw or bug taking down the entire system. In the case of a problem, each component can be isolated and worked on individually, allowing all of the other components and the departments that use them to keep working. Incremental changes can be made to each component, improving the entire infrastructure over time.

The bottom line.

With a headless architecture, your business will gain agility and speed. You can choose the tech stack that suits your exact business needs rather than trying to fit it into a box of pre-built functions from a single monolithic solution. You can create your own suite of best-in-class software through integration.

If you want to learn more about headless commerce, let’s talk.