“Using a MACH architecture allows you as a business to focus on those things that allow you to differentiate against your competitors, that allow you to innovate. And it removes a lot of those mundane and technical activities that don’t differentiate.”

John Williams
Chief Technical Officer

MACH architecture

MACH architectures are digital ecosystems designed with automation, modularity and scalability in mind. These architectures are the core technology of Composable Enterprise operating models.


MACH und composable are not interchangeable!

While MACH is a technical architecture style that comprises of four other architectural style. MACH provides a flexible and adaptable approach for building digital experiences.

Composable is more of a business strategy. It allows business to react to market changes using modular, best-of-breed technical components. It doesn’t define the use of any technical standards of architectural styles beyond the nod towards headless and services architecture.

MACH is an acronym and stands for a modern software and platform architecture that is composed of


Individual pieces of business functionality that are independently developed, deployed, and managed.

API-first principle

All functionality is exposed through APIs.

Cloud Native

SaaS that leverages the cloud, beyond storage and hosting, including elastic scaling and automatically updating.


Front-end presentation is decoupled from back-end logic and channel, programming language, and is framework agnostic.

MACH technologies support a composable enterprise in which every component is pluggable, scalable, replaceable, and can be continuously improved through agile development to meet evolving business requirements.

What is special about this architecture is that principles exist, such as the consistent separation of the frontend and backend used through APIs (application programming interfaces) and their data.

The technologies used correspond to the API-first idea and can be controlled completely via interfaces without a user interface. Cloudnative technologies are the basis for consolidation in the cloud or multiclouds for the automated orchestration of applications, data resources and processes. The interfaces to the respective user are frontends detached from the backend and tailored to the user and his or her needs, which are conceived and designed specifically for the respective requirements. To control business processes or operate applications, the frontends of the software manufacturers (back offices for administrators) are certainly suitable, but with the appropriate frontend technology, individual cockpits or dashboards can also be created.

To illustrate: within a MACH architecture, e-commerce with all its functions, front- and back-end, data, designs, content, products and processes that make up your capabilities no longer comes as a single monolithically forged and configured piece of software. This is because it is difficult to manage in the long term and to expand it in terms of processes and functions.

A shop within a MACH architecture thus consists of self-contained applications/microservices and self-contained systems that function independently of dependent structures and processes. It is possible to vary the entire presentation in the front end for users as desired and to expand it channel-specifically. The set-up and expansion with MAM/DAM and PIM is much more independent of technology restrictions, which has an extremely positive effect on the overall performance of the company.

For example, the data required for the shop is no longer welded to the shop monolith, but can be compiled at will from various sources via API and services. Nevertheless, it is possible that all shop and customer information is used by other systems. The actual interface and system communication and its design are considered just as detached. In order not to hardwire functions and information, it is necessary to clarify how, what, when, for what reason and to what end they are communicated. By using a messaging system and through unified and consistently defined communication procedures, the message- and event-driven IT architecture that is indispensable for today’s digitalisation requirements is created.

If a company converts not only its shop but its entire business processes to MACH technology, a business becomes highly scalable and communicative while remaining performant and flexible. Because it is modular. Roughly outlined, this is what the Composable Commerce Enterprise Model looks like – an important and evolutionary step in the digitalisation of the company.

Benefits of MACH

Like most things, when it comes to MACH architecture, the whole is actually greater than its parts. It gives the business far more agility and speed to try new things and innovate.

The modularity means that you can do things in smaller iterations, whether that’s building new things or migrating from the monolith to the new architecture. You can choose the pieces you want to move and you can do them in smaller iterations.

MACH means you can focus on choosing best of breed vendors. You can choose the suppliers that are fit for your business. And the great thin about MACH architecture overall is, that you can customize them to work with your business.

You can use the API to build integrations that work well with the way that your business works.

Deep Dive



Microservices is the first concept in MACH architecture.
It’s the M in MACH and in the tech community.

There’s a big debate about what exactly a microservice is and what you can truly call a microservice.
For instance, microservices architecture is a way of building systems from small, independently deployable and scalable services. In this section we are goind to avoid the debate on what a microservice definition is and focus on the problems they solve and why you need to care about them:

Modularization of Code

Modularization of Applications with Microservices means when you take a system and you break it up into smaller units of development. To understand how microservices are different to the way we used to develop code, we are going to talk about two concepts and that’s loose coupling and tight coupling.
A good example of a tightly coupled system is a mobile phone. If you want to charge the battery in a mobile phone, you have to plug the whole phone into a larger. If you wanted to replace the camera, if you wanted a better processor or a better screen, you’d actually have to replace the phone with a new phone with those components in it because they saw tightly coupled together.

And in some ways, this is very similar to software.
So previously, we would build applications from blocks of code and libraries, and to build an application, what you’d have to do is take the interfaces of each of these blocks, each of these libraries and glue them together with another layer of code.
If you wanted to make changes or add new features, you’d have to start pulling the blocks apart from the application and reinserting them and re-gluing them together.

This is because you start to create dependencies between the blocks because of the glue code.

In fact, the whole application starts to build dependencies across its entire architecture and this type of development, where you are fusing the blocks together creates tight coupling.
So with tightly coupled development it becomes slower and less agile.

Microservices repairs software components and libraries with services, which are independent and loosely coupled.
You can think of Lego bricks as very loosely coupled because you can assemble them into lots of different structures without creating any real dependencies on the bricks themselves, and microservices connect together using an API web service.

This gives you a common standard so you can connect them together to build a larger application.

Connecting components in this way creates very few dependencies, hence the components are loosely coupled.

Decentralization of Data

Previously, when you architected applications and systems, data would be centralized into a large structured database. These large structured databases were designed to support all the data driven components in your system. This way of centralizing data also created tight coupling between the different data structures. One of the problems of that is some data structures. For instance, customer data may have very different views or requirements dependent on the context in which they’re used in the system. For example, the view for a customer looking at their personal data is very different to the view of a support operative looking at a customer record.
And if you have to make changes to a centralized data model to reflect these different views, you have to do a lot of testing to make sure you don’t break different parts of the system.

Often changes made in a centralized database can lead to risky, large scale migration processes, due to the widespread nature of those changes.

Microservices have a different approach: Microservices prefer to manage their own data.

This means you can design data structures specifically for that microservice without creating dependencies on other areas of the system. This has the advantage of allowing you to choose the best database for the job.
For instance, a high throughput content service may use a SQL database. Yet if you’re building something around social networking, perhaps a graph burst database may be better instead.
However, with this approach you do need to consider how to keep data consistent across all of these microservices.

Automated Deployment

Another important area that microservices improve is that of deployment. And at first you’d think that having lots and lots of small services would actually create a management overhead. However, the benefit of a microservice is that it’s very easy to automate its deployment and teams that develop microservices tend to use continuous integration and continuous development and automate as much as possible through infrastructure as code.

Be loosely coupled means that smaller changes and iterations can be made super quick, making microservice development much more agile.

Business Orientation

The thing we really love about microservices is that they are business oriented.
When you design an application with microservices, Business-oriented Microservices you split it up in terms of its business capabilities. So each microservice actually takes hold of a business capability, such as an API for managing a basket. So splitting up the system in this way allows you to focus the development on adding business value.

It also means all that agility you get from using microservices is geared towards agility in the business itself.

  • The most obvious one is the agility, which we just talked about.

  • Another big benefit of microservices is that because they’re loosely coupled, you can get a lot of reuse across many different applications.

  • And what developers love about developing microservices is it gives them the freedom to choose the technology they want to use.

  • Microservices are independently scalable, which means you can scale the services that are getting the traffic. Means that your scaling is much more targeted than just scaling an entire application as you had to do with the monolith.

  • The fact that microservices are independently releaseable, means you can be much more reactive to change.

  • Building systems from microservices can make them much more fault tolerant as an outage from a small service has much less impact.

  • Another big benefit of microservices is that you don’t have to build them all yourself. You can choose to buy business capability and then plug them into the rest of the architecture.

API-first principle


API-first is the second concept in MACH architecture,yet many people we talk to think that maybe API-first is a redundant concept as MACH architecture already has microservices and headless, both of which are API concepts.

Let us identify what API-first means in the context of MACH architecture, how it differs from microservices and headless, and how it differs from the previous approach of code-first.

The outdated way: Code First

Code-first was how we used to build applications. It’s how we used to build applications in the beginning.
As the name suggests, you would start with the design and then the code of an application, and then consider the APIs at the end.

You would insert the APIs once you’d finish the core functionality in the application.
What you do is you build that core functionality out of modules of code that you glue together.
With code-first approaches, you tended to build monolithic applications that were really accessible through a UX and only had a minimal set of API coverage.

So code-first development can lead to lots of delays and lots of revisions as you start adding the interfaces and adding APIs and altering those APIs to really work with what the consumers need.

So to help explain this, let’s look at a really simple analogy:
Imagine you’re trying to build a highway that’s going to join up two cities, City A and City B.
Imagine that City A and City B are 1000 miles apart.
So in the code-first approach, you take a look at the map, you’d look to see where the obstacles are.

Where do you need a bridge?
Where do you need a tunnel?
Are there any obstacles you need to curve around?

You might look at something like the climate and see what materials you needed to use for the road. What’s the best tarmac to use, for instance.
We are not an experts in road construction, but imagine you’ve went through that process first.

You then get your teams together and then start building that road.
So now let’s imagine that road is now complete, and you release it into the general public, and everyone’s really excited of getting on this new highway.
What happens is a week later, you get inundated with news stories of people being stranded on the road, families being left without food and water 500 miles in the middle of this road.

And why is that?

It’s because you neglected to think about adding service stations.

And not only that, you get a political storm where Cities X, Y, and Z have not been connected to the road because you didn’t put that in the design.

You didn’t think that was necessary.

And the real reason why that happens is that you focused on building the core functionality of the road and not about the consumers of that road.
You haven’t thought of the road as a service. If you think about the highway as a service-first and then build the core functionality, you wouldn’t have had those problems.
And that’s what API-first tries to address.


What is API-first?
Let’s start with the standard definition of API-first.

API-first in development is where you consider your APIs as first class citizens.

And what you’re developing is developed with the angle of API consumption in mind. It means that all functionality is completely accessible through the API. There is complete API coverage. There’s not one piece of functionality that can’t be accessed through an API.

It also means there are no restrictions on using that API. There is no special SDK you you have to use so that you can get access to a particular piece of functionality.

So to try and help understand what that really means, we are going to answer three questions:

API First vs Code First

So why is API-first different to code-first?

As we outlined earlier, in code-first, you build your application, you build your core functionality and then you bolt on your APIs.
Whereas in API-first, you start by creating the APIs and after those APIs are created, you then start building the core functionality to support those APIs.

So what this means is that you start focusing on imagining your business in terms of consumable services, and you start thinking about the business problems you’re solving with your services.
This strategy helps you merge your business model with all the new exciting functionality and technology you’re building.

So, basically, the API-first approach thinks of the highway as a service, who is using it, and how it’s going to be used.

API First vs Headless

So what’s the difference between API-first and headless?

Headless technology is about creating a system that is completely independent from the implementation of its presentation and user experience using sets of APIs.

That sounds a lot like API-first, right?
But the real difference comes down to API coverage.

Delivering the user experience is only a fraction of the functionality of a system.
For instance, an e-commerce system is not just about delivering the experience but it’s also about delivering a brand’s business model. It’s about delivering business user processes and allowing you to connect to other systems in that ecosystem.

And that is why API coverage is so important.
Without great APIs, it’s impossible to integrate these systems together and give you the business user experience you need.
It’s entirely possible to have a headless system and it’s still not be API-first.

API First vs Microservices

So what’s the difference between microservices and API-first?
We already know that microservices are essentially aware of building application APIs. It focuses on grouping APIs around functional demands.
It’s not necessarily about the API coverage. Therefore, again, you can have a system with a sets of microservices and it’s still not to be API-first.

API-first means you develop a system that delivers value to all the consumers of that system far more quickly and efficiently than just leaving your APIs as an afterthought.

Cloud Native


So, Cloud Native is the C in MACH Architecture, it’s the C in the acronym …

… but are you fed up of hearing that every single bit of technology these days is regarded as cloud, and you just don’t know what it actually means?

Even the old monoliths are now calling themselves cloud because they basically took their applications and put them on some cloud infrastructure.

To differentiate between technology born and built in the cloud and those just migrating to the cloud MACH Architecture has formed the term Cloud Native.


The first dimension is about platform delivery, and this dimension describes how the software delivers its service. Does it deliver it as a multi-tenanted scalable service or does it deliver it as a managed service delivering instances?

The second dimension we are going to use is that of API coverage. As we are use the context of MACH Architecture, it’s important to understand how well it opens up the system using APIs. What’s really interesting is when you bring these two dimensions together, it forms four distinct quadrants and we’ve named these quadrants to help you understand what they really mean:

The Cloud Tower - Monolith in the cloud

This is cloud enabled or a managed service with very little API coverage.
Towers are often created when you get those large monolithic on-premise systems being packaged wholesale and moved onto cloud instances.

Cloud Towers often have massive amounts of functions and features that they’ve developed over the years, but very few of them are available through APIs and web services.
Towers do take away the pain of managing your own infrastructure, but that does still come at a cost that you get with monoliths.
You still get protractive development time, softwares still require long complex and risky migrations.
Core changes require long release cycles, getting to high availability and resilience still requires a lot of investment, integration with other systems can be quite tricky because of the lack of APIs.

Towers might be very strong at delivering in one vertical channel, but they’re very weak when it comes to multichannel and omni-channel delivery.

The Iceberg - legacy / monolithic SaaS

These are multi-tenanted systems with a low API coverage.
Icebergs are little like Towers where they’re large monolithic systems that are very feature rich.
Unlike Towers, there’ll be architected to accommodate an entire customer base.
Where we’ve seen Icebergs arisen is from the older SaaS based platforms.

Those early cloud pioneers that’ve invested heavily in infrastructure and heavily in features, but that’s been at the expense of re-architecting their systems to really benefit from new cloud-based technologies and investing in increasing API development.

Icebergs will have large, scalable, distributed infrastructures, but the lack of API coverage comes at a cost.
Development still means that core changes require extensive development cycles.

The closed nature of Iceberg architectures means that developers can be quite difficult to find and quite expensive because often, they need to know proprietary languages or proprietary frameworks.
Although integrating with Icebergs can be quite challenging, what we’ve seen are large ecosystems developing on these Icebergs, partner start developing plugins and accelerators that work with these Icebergs and are delivered through marketplaces.

If multichannel is provided, it’s often limited, if delivered through small sets of APIs, delivering little tiny Iceberg peaks.

The Factory - Packaged cloud instances

These are systems that are managed services but have a lot of API coverage.
Factories focus less on shared large distributed infrastructure and more on software architecture. They focus on delivering software as discrete components that are nicely wrapped in APIs.

This approach means that packages of that technology can be built on automated production lines that can churn out shrink, wrapped instances for each customer at super speed.

Factories often evolve from companies that have heavily invested in API development before moving to cloud or companies who take open source software and shrink-wrap them into managed services.

The API coverage of manufactured instances provides a great platform for developers for integration, but they still suffer from the downsides of managed services. The way that these packaged instances are deployed and managed may increase the costs of scaling, redundancy and resilience.
You won’t see the economies of scale you get with multi-tenanted platforms and upgrading to new versions on that production line may not be that simple and may require further development and further migration.

However, it’s significantly less than the cloud Towers.

Cloud Native

Cloud Native is multi-tenanted with full API coverage often with an API first mindset, meaning that every platform interaction can be delivered through an API.

Cloud Native technologies have fully embraced the cloud at every level. They use large scale cloud infrastructures and processes to deliver multi-tenanted platforms. These technologies are designed to scale for all of their customer needs, not just the biggest customer, but all of their customers all at the same time.

With Cloud Native technologies, all customers get the same version of the platform. In fact, there’s only ever one version of the platform. There is a constant stream of new features and new functionalities all delivered through automated CI/CD processes, meaning that there is very little or zero downtime.

These systems are significantly faster to develop on and allow businesses to be nimble and agile and meet the demands of the future.



For us, headless is the defining characteristic of MACH.

But what does it really mean?
With so much feed in the market right now, and everyone saying they’re headless.
How can you really tell that they’re headless?
And what does headless truly mean?

Let’s have a look what headless technology has been designed to solve, what it actually is, and why should you even care.

Why go headless?

To understand why we need headless technology, let’s first look at some of the previous architectural patterns.

The way we used to design applications in the past, was that we used to separate them into tiers.
And you could actually visualize these tiers with something like a layered cake.

In the bottom tier, you would put your databases, your data repository.
In the middle tier, this would be where the business logic and the application logic would live
and the very top, you would have your presentation layer.

And this would be where you design and implement your user experience.
And this pattern was used in nearly every single monolithic system in the past, whether that was an ERP, a CMS,an e-commerce platform, a search engine, or even a recommendations engine, and the same pattern was used when you built a larger platform, based on these technologies.
In these systems each component was mapped into the layers using code to glue them together.

Components in one layer would have dependencies in components in other layers.
For instance, a page in the presentation layer, maybe generated by CMS, would have to be represented in the data layer.
And the business layer, would basically translate what a page is, and what it means, and how it could be used by the presentation layer.

Although, layers are really useful to help you understand the system at a logical level, in reality, those layers are fused together.

And ultimately, this is how we organize what we know today as the monolith.

One of the downsides of this approach is that, to implement the presentation layer, you’d have to use a specific set of technology.
And that technology was often prescribed by the technology in the layer below.

For instance, you may need to use ASP.NET with .NET architecture, because the layers are tightly coupled and the components are tightly coupled.

You often had to represent presentation elements within the database, so that the business layer could actually translate what those objects were to the presentation layer.
This makes it almost impossible to implement the presentation layer for different digital channels.

And this approach can lead to building monoliths for all your different digital channels that use different types of digital technology in the presentation layer.
Which as we know, leads to lots of duplication and lots of siloed content and data.

What is headless technology ?

How does headless technology address this?

Well, first of all, we remove the presentation layer. In other words, we remove the head. This means that you do not need to implement any type of user experience. It means you do not need to implement an SDK or any other front end technology components for the technology to actually work.
To do this, headless systems replace the presentation layer with an API layer.

These APIs are web services, typically a REST service. In the future we may even see the technology of GraphQL, starting to replace REST interfaces.

As these APIs, or web services, there is not tight coupling between components or any dependencies on what the front end technology has to be. It can be an iOS native app, it could be an Android app. It could be web technology and using any of the new frameworks like React, or Vue, or even Svelte.
And it doesn’t have to stop there, you can implement voice interfaces, or interfaces into IoT devices.

Now there’s one subtle thing about real headless technology and it goes back to the layers discussion we had earlier. In the data layer for a headless system the data is only concerned with the business model or the application domain. It will not include any specific dependencies on how that needs to be presented, like we used to have to do in the old world.

And again, the business logic layer does not have any dependencies on what the presentation layer is. It’s this reason why headless technologies can not only be used for different devices, different front-end technologies, but they can also be used in lots of different digital channels, in different digital contexts.
For instance, they could be used in store for different in-store devices and different install applications, they could be used in customer support, or even a grill.

Headless technology is more than just removing the presentation layer. It’s about creating a system that is completely independent of how you have to implement the presentation and the user experience.
And this is why we see implementations of monoliths, that have been wrapped in an API, failing again, and again, and again, in a headless system and a MACH based architecture.

Why should I care about Headless?

Digital channels are now the primary channels for businesses – it’s never been so important to deliver great experiences at every digital touchpoint, wherever your customer is.

That’s why headless technology is so important today.

Headless is critical to deliver consistent, omni-channel and multi-channel experiences.
Headless technology finally gives the opportunity for businesses to be more agile and more nimble, when it comes to creating content and creating digital experiences.

You can now create platform agnostic content, create it once, and deliver it everywhere. Deliver it into every single channel you have, by separating the layers, and pulling out the presentation layer away from the business logic, away from your content, and away from your data.

This means you can innovate far more quickly in the digital experience.
Headless technologies make it easier to experiment and innovate without large scale developments and large scale deployments of technology.


It was 2019 when it was decided to open the Qilin.Cloud technology platform for the development of its products to the whole developer community in the e-commerce domain, it became increasingly clear, that “MACH” alone is not enough.

Involving the community is only half of the story, it’s ridiculous if code is only accessible to a few:

From this demand for transparency, the open commerce idea was born, where the “O” in MACH-OPC is for open commerce.

At the same time, the Qilin.Cloud leadership team noticed in their daily feedbacks from users that -especially with advanced growth- they were increasingly relying on process models to manage their business. This is also reflected in every single detail of the Qilin.Cloud technology platform: processes are defined, established, analyzed and optimized at the highest level down to the smallest detail.
This process centricity is reflected in the “P” of MACH-OPC.

And last but not least, the “C” which stands for the composable character. There we have it:


While the MACH part refers to architectural decission and therefore is more about techniques, the OPC stands for business patterns. Getting technical and business patterns combined into MACH-OPC is -in our eyes- the most powerfull symbiosis for the next decade of businesses.

While the MACH part focus on architectural decisions and is therefore more about techniques, OPC stands for business patterns. This combination of technical and business practices in MACH-OPC is in our eyes the strongest symbiosis for the next decade of enterprises.

Why are more Brands moving to MACH-OPC

“We stopped working with a waterfall workflow and introduced a new workflow that distributed the work across multiple people, so the developers were no longer the blockers, because that’s where we came from.

It allowed us to share the work across the team. That was the most important factor.

The second most important factor was the consistency of the site; being able to create templates and create a consistent look and feel was also very important.”

Katie Patt
e-commerce Merchant Lead
Crate & Barret

 “We are moving to MACH because we believe that this evolutionary architectures is the right platform for speed of growth and driving innovation in our customer experience.

Working with leading SaaS vendors enables us to let us innovate on a digital customer experience where we wish to drive innovation.”

Neil Memmott
Head of Technology
The Very Group

 “One of the challenges for us as an engineering company is to keep our engineers engaged and if you doing that on old technology you are simply going to loose the engineering talents.

A huge amout of what we do in terms of the service is having the best engineering talent, the most engaged and the highest sort of expertiese on problem-solving individuals. And if you not giving them new challenges, if you not presenting new technology -it doesn’t have to be bleeding edge, but certainly cutting-edge- and allows them to upskill and achieve new things and solve new problems – thats a very important part of our organization and why we adopted MACH technology.”

Ross Humphreys
CX Partnerships, EMEA
Grid Dynamics

 “What we are aiming to do is to become the destination for cosmetic treatments. Thats realy involved bringing together a number of different worlds: It’s bringing together content, it’s bringing together search, it’s bringing together e-commerce. But it’s also building a marketplace, beeing able to book on the platform. So, you know, what realy drove us down the route was the need of that flexibility to have that best-of-breed approach. We recognized that having a one-size fits-all monolithic solution wouldn’t actually solve our requirements as a business, because we don’t need lots of redundant functionality not going to use. Having that MACH approach, being able to consume exactly the specific functionality we use, was the key driver.

It actually enabled a quite complex vision and bring it all together in a seamless way.”

Rob Pye
Chief Executive Officer