Back to Blog

MACH architecture and how it supports Sitecore’s vision of a composable DXP

MACH architecture is a modular architectural framework that is receiving increasing attention from digital teams and tech providers. MACH architecture supports the “composable” Digital Experience Platform (DXP), consisting of best-of-breed SaaS solutions rather than the more traditional, monolithic DXP. As tech vendors like Sitecore increasingly see a future where the composable DXP is going to be a viable and even a preferred option, we can expect more focus on MACH architecture.

In this article, we’re going to explore what a composable DXP entails, what MACH architecture is, its advantages and disadvantages and how it can support Sitecore’s vision of a composable DXP.

What is a composable DXP?

In a recent article for CMSWire, my colleague Ryan Bennett defined a composable Digital Experience Platform (DXP) as “when a DXP is assembled from a series of best-of-breed solutions” that “work together via APIs to deliver content and digital experiences to customers in a more agile and flexible way than a single, integrated and essentially monolithic platform”.

Ryan’s article goes on to explore the advantages and disadvantages of a composable DXP, including the greater flexibility and scalability of a more lightweight approach and the increased agility of operating in a complex omnichannel world, as well as keeping your options open for the future by avoiding vendor lock-in. However, this can entail significant investment costs and a reliance on technical expertise – it is not necessarily an approach that will work for everybody, or come to fruition overnight.

What is MACH architecture?

MACH architecture is a framework that is receiving growing interest across the IT and developer community, as more technical providers and solutions focus on supporting a composable DXP and headless publishing.

MACH stands for Micro-Services, API-first, Cloud-native and Headless:

·       Microservices: moving away from a monolithic architecture to a range of separate, independent business capabilities focused on supporting a single function that can be maintained and deployed independently

·       API-first: using APIs to allow the disparate elements of the application to communicate and build a cohesive experience for the user

·       Cloud-native: using SaaS applications and cloud-based functionality for all aspects of the application, to ensure flexibility, scalability and speed

·       Headless: decoupling front-end experiences from the back-end systems that powers them, such as your core content management system.

MACH is a modular and flexible style of architecture that can support a composable DXP, but it’s not the only option; for example, you may use Jamstack to support the front-end experiences within your composable DXP.

Sitecore’s vision for the composable DXP

One of the most significant announcements at the 2021 Sitecore Symposium was the launch of the Sitecore Explorer Manager Cloud – a fully cloud-native CMS offering. The availability of a SaaS version of Sitecore is no surprise, and has been mooted for a long-time having been mentioned at the 2020 Symposium and reflected in Sitecore’s acquisition of a number of smaller providers who already offer solutions on a SaaS basis.

A core element in Sitecore’s SaaS strategy is support for the creation of a composable DXP, a term that is featuring in much of the messaging. Sitecore’s new emphasis on the composable DXP means the company is advocating for MACH architecture. They have a dedicated web page relating to the topic, and have also created a video that explains the basics of MACH.

In the video, Thomas Desmond explains how each of the four elements of MACH architecture equate to characteristics of the separate applications or “Packaged Business Capabilities” (PBCs) that make up your composable DXP. Let’s say one of these is email marketing. This needs to be:

·       A microservice: Available as a microservice, independent of other applications which make up your DXP

·       API-first: Have a REST API to be able to work with other parts of the DXP

·       Cloud-native: Be available on a SaaS basis 

·       Headless: Be completely independent of the front-end experiences that you define for your users, and supporting omni-channel publishing.

Desmond also advocates for MACH architecture, describing it as “what we want to see in our composable DXP technologies” – a system that “gives us the confidence we need to know that all these different technologies will integrate with one another”.

Why introduce MACH architecture?

There is considerable overlap between the advantages of deploying a MACH architecture and making the business case for introducing a composable DXP. Some of the key benefits are explored below.

More flexibility escaping the constraints of a monolithic dependencies

One of the advantages of MACH architecture is that it provides more flexibility for digital marketing teams to meet customer expectations of digital experiences in a fast, high-pressure, omni-channel world. The separation of back-end CMS and front-end experience enables a more flexible approach to delivering new experiences across multiple channels, escaping the dependencies and constraints of a monolithic DXP that can limit flexibility and scalability.

More agility through faster speed to market

Linked to more flexibility is greater agility, with reduced development time and time-to-market for creating new experiences. Because MACH architecture is comprised of separate microservices, developers only need to focus on the specific section of the composable DXP you need, rather than considering the impact on every element of the system as with a monolithic architecture.

Supporting best-of-breed tools that your team prefers

Because MACH architecture is made up of independent, best-of-breed tools, your team can choose the applications that they love using, that excel in their particular capability or that you are currently licensed to use. Having this choice with MACH architecture allows you to evolve your optimal composable DXP to suit preferences, needs and circumstances.

No need to re-platform

The decoupled nature of the composable architecture makes  it much easier to swap functionality in or out without disrupting the DXP as a whole or needing to start from scratch. This means you can avoid having to replatform your entire DXP, which is an expensive and time-consuming project..  Want to use a different email marketing tool? You can swap it out and update the relevant microservices without having to touch the rest of the application.

Future-proofing for innovation

MACH architecture means you’re not indebted to one particular vendor in the same way that you are in a monolithic system. This flexibility means you can better future-proof your overall approach to your DXP, adding new applications and solutions to meet needs as they arise, as well as experimenting with new customer experiences with less risk.

Our view

We think MACH architecture is a very useful architectural framework that establishes an underlying common standard for what is required to deliver a composable DXP, so it’s good to see more teams and technical providers like Sitecore focusing on it.

However, it is important to realise that we are only at the beginning of the sector’s collective composable journey, and there are plenty of learning curves ahead for both marketers and development teams. The initial investment, technical resources and potential new roles required to support a composable DXP are likely prohibitive for smaller and medium-sized companies right now, and it is certainly not the “easy win” that characterises some of the current conversations about MACH architecture and composable DXPs.

However, if the future of digital experience is more “composable”, it’s important to drive awareness of what is required across the developer community. Knowing about MACH architecture is a good start.

If you’d like to discuss MACH architecture, composable DXPs and how this might impact your current Sitecore instance, then get in touch!

Back to Insights

How can we help?