With customers relying on both offline and online multichannel touchpoints and companies evolving their business models to keep up with demand, composable architectures are more important than ever before. MACH can be the enabler to help your company stay agile and not be constrained by its technology stack.

It’s very important to clearly separate your architecture from the architecture behind the MACH platforms. Your architecture may follow some MACH principles, but your business is more likely to be focused on building experiences to reach your customers across different channels rather than delivering APIs. The reason it’s important to separate your architecture from the architecture of a MACH platform is to highlight about how MACH affects and influences your architecture. The impact of MACH on your architecture is defined and also limited by its APIs. Unlike more traditional digital platforms that came before, MACH doesn’t (and arguably cannot) become the center of your architecture to give you the capabilities that you need. Your architecture can now be defined by your business goals and its complexities, not by MACH itself. Composable architecture isn’t built on or over MACH. Instead, through the value of APIs, MACH provides the capabilities and functionality you need that you cannot (or rather should not) build yourself.

Having separated your composable architecture from the architecture of MACH platforms, let’s now talk about MACH principles and how each one affects you. This is the key to understanding how MACH enables composable architectures. The effects of M, A, C, and H on your architecture are not equal and some components of MACH are more important than others. “M”, for example, stands for microservices but it’s very opaque. This is about how the platform vendor operates their platform. “M” means a lot in the ability to deliver great API experiences, but if one day, a vendor learned to operate the monolith in the same way, you wouldn’t notice a difference. This is arguably very difficult if not impossible, but the feasibility of operating an API ecosystem as a monolith is beyond the point. “M” doesn’t matter nearly as much as A does. It is the API-centricity – what “A” stands for in MACH – that changes the game and enables the composable architecture. “C” is also important but in a different way. A fully SaaS API platform has zero footprint in your ecosystem and that means you don’t have to worry about operating it. And the “H” in MACH is simply a byproduct of being not only API-first but API-only. The only way you can consume a MACH platform is with a headless architecture and completely decoupled channel experiences. While it is MACH from the platform’s standpoint, it should be considered mAch from your perspective.

There are four blueprints that companies typically use when integrating MACH into their architecture. Your choice will depend on what type of capabilities you are consuming (e.g. content, transactional commerce, order management, etc.), as well as the overall architecture of your solution and what problem(s) you are solving:

1. Client Device to MACH API: This is a very common and relatively simple solution. It has the smallest footprint on your architecture and allows you to benefit from the full capabilities of the MACH APIs – like using GraphQL and leveraging CDNs.

2. Rendering Engine to MACH API: Sometimes your architecture requires that you pre-render your experiences and that’s when you push MACH APIs a little down the stack and start working with them at rendering time before the experience reaches the client’s device.

3. Your API to MACH API: When your business requires you to integrate more capabilities alongside what’s provided to you by a MACH platform, you may find it easier to just make MACH APIs part of your larger backend API.

4. Back-end Service/Job to MACH API: Certain scenarios do not have a customer interaction component and yet are complex enough for you to decide to employ a third-party platform. A good example would be order management and fulfillment workflow orchestrations. A MACH platform providing these capabilities will be integrated outside of the context of the customer journey.

While these patterns are not the same, the principles are fairly similar – you will be consuming the APIs to enable required capabilities. This principle of only using the APIs and not building your architecture on top of a platform will ultimately impact how your team is organized. When you start using MACH, your team’s skills profile will be heavily skewed toward the technologies that you use, the technologies that make up your ecosystem. MACH doesn’t require you to use a particular programming language or deploy a specifically shaped runtime environment. These choices are yours to make. You will still need a small team of experts who understand selected MACH platforms in order to properly model your business using the abstractions and vocabulary of the selected platform, but this expertise – unlike previous digital platforms before MACH – is no longer what defines your team’s setup. Ultimately, you should focus on modern architecture principles, open technologies, API orchestration and cloud engineering.

Finally, let’s talk briefly about how to engineer with MACH. I will go into more detail in future blog posts so I will keep it short for now. You do not need to build an abstraction layer over MACH APIs just because you want an “anti-corruption” layer. The abstractions and vocabulary of the selected MACH platform will bleed into your architecture at the point of consumption. Don’t fight it, embrace it and build your solutions with that same vocabulary. By operating with the same vocabulary on the same level as MACH, you can decrease complexity in your ecosystem. The simpler it is, the faster you will be able to go to market and iterate on it.

The bottom line: You can continue to make your own technology choices, pick your own programming languages and frameworks, and continue to run your own tech ecosystem in the best way for your business. MACH simply enables you to support multichannel user touchpoints and changing business models by providing a powerful API that enables flexible and composable architectures.

If you are interested in learning more, watch our recent webinar on Composable Architectures & Repeatable Patterns: