Kin and Carta plc

10/12/2021 | News release | Distributed by Public on 10/13/2021 10:50

Why a MACH architecture is boosting enterprise agility and speed to market.

What is a MACH technology architecture?

MACH stands for Microservices, API-First, Cloud-Native, and Headless. They aren't new terms for technology, and individually they have been an option for tech for a long time. What is new, is uniting them as a strategy for your technology architecture.

Microservices

This is a strategy to create a decoupled system, as you separate your platform logic into discrete services, you remove critical dependencies and make release and updates easier, as you can change and update in isolation without redeploying the entire system.

API-First

This is a concept for the creation and management of data within the platform. As this MACH approach is focussed on Software as a Service providers, it means that although they often provide an easy to use web interface, the interface itself is built as a layer over the top utilising the same APIs you can use to integrate. Most of these APIs are becoming very familiar working with JSON data and common protocols across vendors.

Cloud-native

In a recent discussion with a colleague we agreed that the promise of Cloud computing is starting to come to fruition, Google, Microsoft and AWS have matured their platforms to provide inherent security, scalability and performance. This means you focus on how to use the resources rather than managing them yourself.

Headless

Often used in the context of a CMS, but this means to decouple the front end technology (the viewing of the data in the marketing experience) from the management and authoring environment technology (the creation and management of the data). This separation also reiterates the microservice architecture. By creating this separation you can consume your content or data, or change the entire experience without replacing the whole backend or doing a "lift and shift"

Why is MACH becoming so popular?

MACH as a martech strategy, is helping organisations to connect the best-of-breed vendors together. Rather than looking for a single vendor to deliver the entire business requirements in a single platform, the organisation can look for SaaS vendors for specific capabilities and then connect them as a group of micro-services using the APIs to talk to each other.

This API-first approach is seen as a 'lean' way of working, as you are only using the platforms that deliver your specific needs. There are a growing number of Martech providers entering the market providing out of the box integrations and 'connectors' to help increase the speed to market and avoid developers having to recreate the wheel each time integrating systems with custom code.

Benefits of using a MACH approach to martech

One of the key benefits of using a MACH architecture is flexibility, and the flexibility spans a number of areas of the overall solution:

Rapid prototyping and feature releases

A martech MACH architecture creates the opportunity to be very agile. Should a new requirement or opportunity arise, you can rapidly prototype or develop the capability without compromising your existing systems, you can either develop the capability internally and choose your preferred technology connect the APIs how you need to and off you go, if it doesn't work or you want to buy in, then you can bolt on a new vendor without needing to rip and replace your entire platform.

Focus and separation of concerns

With the separation of concerns that a microservices architecture and MACH approach delivers, it also gives focus to the teams who develop and use the platforms. Instead of the content authors needing to learn a bit of HTML or knowledge about testing, they can focus on writing the content that will be channel agnostic. Your developers can focus on building the experience in their preferred technology and display the content as the designers designed without having to fight against the way a certain platform works.

Stacks not suites

This is a somewhat annoying term currently used by headless vendors to push their proposition, but it applies to the MACH ecosystem. Typically when you buy digital marketing software from a vendor, you are buying a "suite" of tools and features that are great to get you started but they probably don't deliver the breadth and depth as a vendor that works specifically to provide a certain requirement. For example, A/B testing features in a suite are rarely as comprehensive as those features from a vendor that builds specific A/B testing software.

It's often a case that when people buy into suites, they buy into a grand vision of the future but then this vision rarely delivers to its full potential, in fairness this can often be a combination of skills, experience as well as the software itself, but the situation becomes a self-fulfilling prophecy, because the business invested in the big toolset, they are reluctant (or cant change for 3-5 years due to agreements) this causes delays and frustration.

In a MACH system, the agreements are often flexible and on a more of a "pay as you go" type model, if you need more resources as you grow, you change your agreement, if something doesn't work, change it.