#Summary
There's a lot of discussions about MACH architectures lately – however, what's important to know is that MACH (Microservice, API, Cloud-native, Headless) architectures aim to guide enterprises towards building composable architectures using building block APIs like "Legos" to define a stack that works for them.
Enterprises have historically relied on legacy “monoliths” – suites that do everything – to drive their digital transformation. While this has worked (to an extent) in a web-only world, these monolithic architectures are becoming an obstacle as businesses try to match their customer expectations in a digital-first omnichannel world. The conversation today is about whether that approach is doing more harm than good, and how companies can embrace a better architectural approach to building “experience architectures” that scale with their business needs and ambitions.
In this eBook, we take a look at what MACH architectures are, what the MACH alliance is, what making a move to a MACH architecture could look like, as well as whether your business needs to make the move.
#MACH architectures
MACH architectures, in a nutshell, are enterprise architectures built using modern, modular, and API-first services. Enterprise architectures in the past and, to a large extent, the present has consisted of one-size-fits-all suites that “do everything” in an acceptable manner. In contrast, MACH architectures consist of multiple solutions that do a few things extremely well, coming together via API to create highly optimized stacks designed around a business’s needs.
The building blocks of MACH architecture, as defined by the MACH Alliance, are:
Microservices: Individual pieces of business functionality that are independently developed, deployed, and managed.
API-first: All functionality is exposed through an API.
Cloud-native: Software-as-a-service (SaaS) that leverages the cloud beyond storage and hosting, including elastic scaling and automatic updating.
Headless: Frontend presentation is decoupled from backend logic and channel, programing language, and is framework agnostic.
These four principles enable a modular approach to enterprise architecture, where businesses can create a tech stack by selecting MACH components that are best-fit for each area of business and where each component is designed to integrate easily with other solutions via APIs.
MACH architectures are gaining popularity as businesses are running into the limitations of monolithic systems in our digital-first world. Many of these monoliths were designed when ‘digital experience’ just meant having a website, and as they’ve been expanded to meet new needs, these platforms have become so large and layered that making any change to the experience can feel incredibly risky - and happens very slowly.
MACH technologies drive a paradigm shift by helping companies utilize the most innovative and flexible enterprise solutions available. Built to be composable, MACH solutions can be independently added, modified, and removed from an architecture without a major replatforming effort so that businesses have the flexibility to evolve their tech stack as needs change.
With a MACH approach, companies can now step away from the all-in-one suites that have dominated the enterprise landscape and replace them with modular, future-proof architectures that better align with the digital-first world.
Composable elements that go into a typical MACH architecture. Credit: MACH Alliance
#Do you need MACH?
The individual principles of MACH (microservices, APIs, Cloud, headless) have gained a lot of traction in the enterprise space. In a survey of 500 enterprise technology leaders, 85% reported increasing the percentage of their MACH infrastructure in the past year, and 81% plan on increasing that percentage in the next 6 months. The main drivers of adoption revolve around the need to accelerate change in enterprises.
According to the survey, this move to MACH has paid off. Organizations with a significant increase in MACH infrastructure in the past year, compared to those with no increase, rate themselves over 20 percentage points higher in the ability to deliver customer experience at speed and ahead of the competition.
While a MACH approach can offer increased speed and flexibility, it can also require a decent amount of technological change and working methods. Before making the move to MACH, an organization should make sure that the potential business benefits outweigh the investment. If your current infrastructure is easy to maintain and lets your team work at the pace they need to, there’s no reason to break it apart and add complexity just for the sake of not having a monolith.
However, the following signs are a good indication that it’s time to start exploring a MACH approach for your organization.
You’re held back by the cost of change:
Your team has a lot of great ideas that never get implemented because of the time and resources it would take to launch them. Your monolith has become so layered that simply maintaining it takes up the majority of developers’ time, and any change risks a waterfall of errors that could take down the whole application. Improving the customer experience is a slow process, with updates bundled into infrequent releases that require substantial downtime for testing.
You’re experiencing scaling pains:
The processes in your monolith are so tightly coupled that, to ensure performance, you have to pay for the resources to scale the entire application instead of individual capabilities. You’re not able to take advantage of elastic scaling for peaks (seasonality, promotions, flash events, etc.) which has led to not having enough capacity at critical moments or to the high cost of on-call resources that sit unused most of the time.
You need more channel flexibility:
Customers are engaged across multiple channels, but the customization it takes to get your monolith to support new touchpoints means that your team rarely experiments with new experiences. Regional and brand sites increasingly need unique features and integrations, leading to one-off workarounds that are hard to maintain.
You have independent, domain-driven teams:
You have distinct teams for different business domains (e.g., payment team, loyalty team, product discovery team) that work in parallel. Teams are familiar with DevOps practices and view technology in terms of products, where the team is responsible for the full lifecycle of technology rather than as projects that are handed over after launch. A major blocker to the autonomy of these teams is the high level of coordination needed to roll out their changes in the monolith.
Your ambitions outpace the monolith:
Your monolith has served you well, but it doesn’t have the right capabilities for the next phase of digital at your organization. To support an ambitious roadmap and diversifying business needs, you’re interested in a modular approach that lets teams choose the best-fit technologies for each channel, domain, and customer need.
#Making the move to MACH
The major benefit of a MACH approach is that there is no one-size-fits-all architecture, which also means there is no one-size-fits-all roadmap to go MACH. While each organization’s strategy will differ, here are some do’s and don’ts that are generally advised when moving from monolith to MACH.
Do: Provide incremental value
The modularity of MACH means that there is no need to wait until the end of a big-bang replatform to start driving value. Most organizations step off the monolith one piece at a time so that it never feels like flipping an expensive switch but like gradually turning the dial from monolith to MACH. Breaking the move into distinct steps also makes it easier to validate your team’s approach early, gain momentum internally, and adapt the roadmap if the business and market need change.
What piece of the monolith to break off first will vary depending on customer needs, productivity needs, team capacity, cost, and other business priorities. Some companies start with a single service with clear boundaries, like checkout. Others start with a small slice of the experience, like a product page, and bring in all the MACH elements needed to power that slice. Others start by creating a fully MACH architecture for a less complex regional or brand site that is then expanded to support the more business-critical channels.
Do: Define existing business domains
To be able to break apart the monolith into small, independent pieces, you first need to figure out what those pieces should be. Look at what’s happening inside the monolith from a customer, internal user, and developer perspective to see what distinct domains the business is organized around, even if the code itself isn’t. This includes taking a high-level concept like “customer session” and breaking it down into individual units such as “profile”, “wish list”, and “payment”.
Image source: Zhamak Dehghani, How to break a monolith into microservices
As you define the boundaries of each domain, also map out how these pieces interact. Which domain is responsible for which data, how and how often is that data shared, and what workflows are involved? Understanding and documenting these dependencies helps teams create the roadmap of which pieces to break away from the monolith, define development best practices, and flag challenges early on.
Do: Decouple the frontend early
Headless, the idea that frontend presentation is decoupled from backend logic is an essential part of MACH architecture. It’s the reason MACH is such a good approach for an omnichannel strategy because, with headless, all data is communicated in a standard way via APIs so that the same content can be used in many ways across different channels. This standardized way of sharing data also makes it easier to add, modify, and replace parts of a MACH architecture without having to rewire the whole system.
A common first step in a MACH transformation is to decouple the frontend from the monolith so that all interaction happens via APIs. This way, as you continue to replace backend services, you can just switch the relevant APIs without disrupting the frontend experience.
A headless CMS is typically adopted as part of this step. While it is possible to use a frontend framework alone to detach the monolith, a headless CMS offers the best practices to model content and handle data for an omnichannel approach. It also gives developers and editors the tools to quickly and continuously improve the frontend, independent of the more complex service migration on the backend.
Don’t: Reinvent the wheel
After being locked into the monolith’s working methods, it can be tempting to overcorrect and custom-build every part of the new architecture. For this to be sustainable, you not only have to have in-house experts for every business domain, but you also need to have the team resources to continuously maintain and improve each service.
For most organizations, it makes sense to have the in-house team focus on building the capabilities that are going to differentiate the business and buy more commodity services and domain solutions for areas where there isn’t internal expertise.
Fortunately, there is an increasing amount of MACH-based technologies on the market that support this composable approach. MACH vendors typically focus on a particular area of the experience, like commerce or content, which gives your team access to a steady roadmap of improvements in that business domain. They are delivered as software-as-a-service (SaaS), which takes monitoring and maintenance off your team’s plate, and the microservice design of MACH solutions means that you’re never locked into using all functionality a vendor offers but are free to mix-and-match built and bought services to meet your needs.
Don’t: Feed the monolith
Every migration step should aim to move dependency away from the monolith. That might mean making productivity less dependent on the monolith by breaking off parts of the architecture that are changed the most frequently and cause the biggest bottlenecks, decreasing financial dependency by moving business-critical domains to MACH technologies or reducing structural dependency by modernizing foundational parts of the architecture so that it will be easier to decouple the rest of the services down the line.
It’s also important to retire the old code in the monolith once the new service is tested and in production to avoid a situation where teams are maintaining redundant code or, worse, creating new functionality that depends on the outdated code. As well as getting into the practice of adding any new capabilities as an independent service instead of creating a quick-fix in the monolith that will need to be replaced down the line.
Don’t: Create a distributed monolith
A disturbed monolith is a situation where you’ve broken your architecture into services, but those services are still so intertwined that you don’t have the advantage of fast, independent release cycles. It’s the worst of both worlds, with the complexity of microservices and the inflexibility of a monolith.
One way to avoid this is by keeping an eye out for “MACH-washing” during technology selection. As composable increases in popularity, some software providers will claim that their solution is MACH without actually offering the full benefits of the approach. For instance, a vendor might add an API layer and market themselves as “headless” while all the backend capabilities of the platform are still very tightly coupled. Or a large suite provider might acquire a microservices solution for one domain but only offer it as part of a bundled license that still locks companies into using the legacy monolith.
Even with fully MACH technologies, it’s possible to create a distributed monolith. For instance, if services rely on a shared database, they will continue to be coupled. Instead, each service should own its data and have a clear API contract on what data it needs to expose. Teams are then free to change how that service stores data, what events it publishes, and how it operates internally as long as that API contract is maintained.
It’s also key to watch out that perfectly independent services don’t become gradually coupled thanks to Conway’s law, i.e., the idea that organizations design systems that mirror their structure. If a single team is responsible for multiple services, those services will likely become intertwined. For instance, if multiple teams get into the habit of coordinating releases, the service architecture can quickly start to reflect this monolithic release practice.
#Moving to MACH case study.
Dr. Oetker harmonizes platform infrastructure with MACH architecture
Dr. Oetker is a global leader in the Food and Beverage industry, operating a portfolio of 45 brands in over 40 countries. As digital became more business-critical, the organization felt the growing pains of their legacy monolith. They wanted a way forward that would make it easier to keep the experience consistent across brands, continuously improve this experience with fast update cycles, and also empower regional teams to adapt the experience to each market.
To do this, Dr. Oetker created a composable architecture that includes MACH vendor solutions for headless content management (Hygraph), search (Algolia), and the frontend framework (Next.js). Combined with in-house services and legacy applications for storing product information (PIM) and recipes.
This headless architecture allows Dr. Oetker to harmonize the core infrastructure across all brands, websites, web apps, and portals, which makes it easier to streamline business processes, ensure compliance, and roll out global updates at a fast pace. Each regional team can build off this core tech stack, adding services and creating unique frontend experiences that best fit the needs of their market.
With Hygraph, this composable tech stack combines into one powerful editing experience. From a single user interface (UI) teams can create editorial content, pull in relevant recipes and product information, and use search insights to combine everything into market-specific experiences that help customers discover the right products.
All of this is made easier with Hygraph’s granular permissions, which ensures that each person only sees the products, content, and data that are relevant to their region and role. This allows over 100 stakeholders to simultaneously manage unique experiences across 40 countries from the same content solution.
#Content Federation vs. MACH
One challenge that comes with a composable approach is how to orchestrate the content and data that live in different parts of the stack.
Some organizations try to manage this by using their CMS as a content repository, where all data is regularly synced into the “content hub”, but this requires duplicating data, which leads to data integrity challenges that make it hard to scale. Another approach is to create custom middleware to aggregate APIs, but this requires companies to take on the burden of having to develop, host, secure, and ensure the global CDN performance of their middleware model. Either way, businesses end up devoting a large amount of time and budget to backend data management that drives zero differentiation to the customer experience.
As we, the Hygraph team, helped more enterprises move from monolith to MACH, we realized that we were uniquely positioned to simplify data management in a composable architecture. Our content platform is built with GraphQL, a query language designed around the need to fetch data from multiple services efficiently, and we saw that the same Hygraph GraphQL API used to support a multi-channel frontend could be evolved to connect a multi-service backend.
We call this Content Federation, a novel approach to fetching remote data from all the services in your architecture and exposing it from one fully managed, secure, and unified GraphQL API.
Content Federation makes it possible to use a single API call to fetch just what you need from multiple sources rather than coordinating multiple API calls to fetch a full set of data from each service. When information is requested, Hygraph grabs it directly from the source, which means there is never duplication and data is always up-to-date.
Hygraph’s federated content platform offers the technology and tools to streamline service integration in a composable MACH architecture. Freeing engineering teams to focus on more differentiating capabilities and empowering non-technical users to create digital experiences that combine multiple sources without writing code.
To understand how federated MACH architectures and content operations can assist you in your digital transformation journey, get in touch!
#About the MACH Alliance
The MACH Alliance is a [501(c)(6)] non-profit organization, governed by an independent board and does not endorse specific vendors, members, or otherwise. The Alliance was formed in June 2020 to help enterprise organizations navigate the complex modern technology landscape. It aims to guide and show the business advantage of open tech ecosystems that are Microservices based, API-first, Cloud-native, and Headless. All MACH Alliance members meet certification principles that are published on the website.
Founding members include Amplience, commercetools, Contentstack, EPAM Systems, and Valtech. The MACH Alliance welcomes technology companies and individual industry experts who share the same vision for the future.
Learn more at machalliance.org.
#About Hygraph
Hygraph is the first GraphQL-native Headless Content Platform, enabling teams across the world to rapidly build and deliver tomorrow’s multi-channel digital experiences at scale.
It was designed for removing traditional content management pain points by using the power of GraphQL, and take the idea of a Headless CMS to the next level. Hygraph integrates with any frontend technology, such as React, Vue and Svelte.
Get started with Hygraph by creating a free account, learn how our customers are solving real-world problems, gather information about next-generation CMS from our resources or academy, or learn more about the applications of Hygraph.
To discuss how Hygraph can help you transform your digital projects, reach out to us.