MACH: what does it mean?
Product marketers sometimes come up with the most extraordinary abbreviations, names and product associations. Today I will discuss a. term that - out of the blue - crops up frequently: MACH.
What does mach stand for?
MACH is not a product but a vision of the architecture of platforms. The abbreviation stand for four principles:
Microservices
API-first
Cloud-native SaaS
Headless
The article continues under the architecture image of Plate
The MACH movement originated from companies undergoing digital transformation. MACH wants to help these companies to set up processes and systems as efficient and flexible as possible to get a stronger competitive position. In doing so, best-of-breed technology is chosen to provide an optimal customer experience. This is also called a Happy Flow. The result of this flow is an integrated approach, but because customers often use different systems for a total process, these applications must be integrated. A simple example to make this clear.
Actie
Applicatie
In order to achieve a scalable and measurable process, all these applications must be integrated. The MACH concept is a good yardstick for this. If an application does not comply with this vision, it becomes costly and time-consuming to make, maintain and extend integrations. And with more and more applications being used for specific purposes, such as LeadInfo, Gong and other tools, there is more and more pressure on this process.
Below, I explain all the different aspects so that you can make the right choices when selecting your next application, for example your CMS, if digital transformation is on your agenda.
Microservices
In fact, there are two ways to create an application. The first way is a monolith, in which you often use one programming language and link all the parts of the application together. When a developer starts writing an application, they often start small and fine. But as soon as customer needs and requirements accumulate, all these functionalities are built directly into the overall application. On the other hand, you can build an application in all microservices. If we take a CMS as an example, you could put all components in separate 'services'. Think for example of version control, user management, inline editor, copy functions, etc. All these functions are part of the same application but are developed separately (perhaps even in different programming languages) and communicate with each other via an API, often a GraphQL.
Watch the basics of microservices in this video
Benefits microservices
The biggest advantage of microservices is that applications do not necessarily have to use all services and that services can therefore be exchanged. Suppose you prefer not to use the forms builder from the CMS but from the CRM package you have, you can easily let these two applications communicate with each other (via the GraphQL). In this way, you choose the parts of your application that it is really good at and connect them together into one happy flow.
This ensures that microservices are super flexible and robust. Also, for each microservice you can look for a programming language that fits the purpose of that application so you get the most powerful ecosystem. Also, because parts of the application can easily be exchanged, you can leave the content in your current CMS but still use the inline editor from another CMS or a personalisation feature from an e-Commerce system.
To be honest, there are also drawbacks to microservices. If you once built an application as a monolith and you have to convert it to a microservices environment, this costs an enormous amount of time in refactoring. Management is also more complex, and testing is extremely important because everything must continue to work together (even if a separate microservice updates). The final potential disadvantage lies in performance. If you connect the microservices together in a complex way, the application will become slower, because there is a need for continuous coupling between the various components. Often, this is not so bad, but definitely take it into consideration.
API first
Building an application 'API first' is different from extending an existing application with an API. API first means that all functionalities of the application are accessible via an API in order to make a real connection between two applications. Often you see that not all functions of an application are accessible via an API.
There is also a difference in the types of API (REST, GraphQL, etc) and it is also important that an API is well documented. Without that, it is difficult to make an API without the help of someone with specific knowledge of that product.
Cloud-Native Saas
A mouthful, but the bottom line with 'Cloud-Native Saas' is that the application must truly be a Cloud product. Not an 'on-premise' product that is installed on a server in the cloud. Cloud-Native' is more than an internet plug in an oldskool application. It includes hosting, storage, scalability, provisioning (I don't know what to call it) and central updates that make upgrade management per customer redundant.) If an application is not cloud-native, it is difficult to connect to that application. You must then first connect to a local server, with authentication issues and more.
Headless
In another article I will discuss a headless CMS in detail. The word "headless" boils down to the following: the front-end user experience (e.g. a site you see) is completely decoupled from the back-end logic, which allows for complete design freedom when creating the user interface and for connecting to other channels and devices (e.g. existing applications, IoT, A/R, automatics, sensors, etc.).
This way, you can manage your products from one headless database and display them differently on different applications. A sports shirt on nike.com looks different (read: it has different information, ed.) than in the Nike app, or on the touch displays in the Nike store. The more channels a brand has - omnichannel - the greater the value of headless is because you can build a digital experience for a specific channel and target group independently.
Conclusion, why do you need to know what MACH is all about?
Not every company necessarily has to listen to the MACH vision. For some companies, the added value is just not that great or the impact of the digital transformation is not very strong.
But I still very often see companies that accept a slick demo of a product that is still installed on a server, or an application that is not connectable via an API. Just think about how many different applications you use within a process and you will see the impact of how your company should score on the MACH scorecard.
With Plate we are working hard to achieve the full 100% score on the MACH vision with our Content Management Platform. This year we hope to have the entire platform divided into microservices, including APIs to access all services.
Plate has been Cloud-Native SaaS from the start and we have also released the Headless component internally. It is possible to use a modern front-end framework like Vue. is to create a website or web app in Plate and still use Plate's inline editor and user-friendly CMS.
Would you like to know more about this topic or brainstorm about the digital transformation of your organisation? Feel free to book an appointment with me. Want to wait and see? Follow us on LinkedIn and stay informed of all the developments we are working on.
