MACH: Microservices, API-first, Cloud-native SaaS and Headless; a concept that’s suddenly in the spotlight. Although the separate concepts are well-known and not quite new, the ‘MACH Alliance’, which was launched in June, attaches an umbrella concept to this technical view. Does ‘MACH’ constitute the new ‘Cloud’, and could it be just as influential as ‘SaaS’, or would that be giving it too much credit? ISAAC CTO Friso Geerlings anticipates that MACH will present a complex challenge that will also provide companies with a focus on an incomparable and omni-channel customer experience with plenty of value.
MACH developed as part of the ‘digital transformation’ tide. Starting out mainly as a way to design larger web applications, mobile channels and front-end facing projects built from separate, independent components from different vendors, this view is starting to permeate the entire IT sector from the outer edge of companies.
Openness and interoperability are typical of the MACH architecture; applications built up in manageable components instead of monoliths. Geerlings: ‘A MACH architecture is built up in (micro)services, accessible through structured APIs. These may refer to services a company builds itself, because they are not yet provided in the market for instance, but most services by far are purchased in the cloud. Any required services are then combined into a private and special value chain.’
‘In addition, a MACH landscape relieves many concerns in relation to upgrades, scalability and flexibility. The landscape largely runs in the cloud, and the architecture with microservices and APIs creates plenty of flexibility and manageability. Replacing, improving or removing services is relatively easy and does not require the landscape to be completely reformed. Because the back-end and system integrations are decoupled from the front-end (‘headless’), MACH is completely moving away from large and vertically integrated platforms which usually come with a strong connection between the user interface and the underlying business logic. In short, the composable MACH architecture provides a great deal of flexibility and in particular the possibility of a much higher rate of change when compared to a classic (on-premise) platform that mainly requires a well-defined approach’, Geerlings says about the characteristics and differences.
In recent years, many companies have become increasingly dependent on huge ‘suites’ of classic platform vendors. Geerlings: A combination of sizeable CMS systems or DXPs, extensive commerce packages and extensive marketing packages have become the rule rather than the exception. Although search, analysis, ranking, content, workflow, etc. are included, these packages are expensive and the more use you make of upgrades, the more difficult things become. The customised extensions; complex and static integrations; other dependencies all present considerable effort to upgrade. One of the main questions may be: ‘Does it feel as if you are constantly busy upgrading your systems?’.
Many companies find themselves confronted with this. Geerlings often hears that meanwhile, companies spend more money on keeping the platform up and running than developing new business functionalities. ‘Fussy point releases are becoming quite an issue, while the recurring upgrades to the latest version of Sitecore, Adobe Experience Manager, Magento or SAP Commerce come with high costs. And then there is the issue of the mediocre innovative power of the classic vertically integrated platforms. Innovation often moves slowly, involving the occasional annual feature release, but it may take years for one to have ‘that one handy feature from Google’. Things in this area need to be accelerated,’ says Geerlings.
"Companies spend more money on keeping the platform up and running than developing new business functionalities."
It is increasingly important to provide a unique customer journey that can be adapted quickly and effectively to changing circumstances. Geerlings: ‘One challenge many companies face is a unique product versus a unique experience. Take meal delivery services. Apart from the fact that Thuisbezorgd.nl and Deliveroo focus on a slightly different target group, in essence they provide the exact same product: meal delivery. They compete in the area of customer experience which requires a customised front-end – perhaps several even, such as a (native) app, conversational commerce and website. You will want these front-ends to be linked to a range of services that can be combined and expanded in various ways, based on your company’s unique proposition. This requires composable architecture instead of a platform that provides a rather tight business format.’
Many companies have attempted to set up these unique experiences – and complexly organised value chains – on the classic platforms. In many cases, they find themselves confronted with a laborious configuration which requires 100% knowledge of a platform, while ultimately their use of the functionalities does not exceed a mere 15%. In addition, they depend on slow release cycles and are confronted with a lengthy and expensive upgrade process relatively often. MACH solves many of these issues. The landscape is built in microservices, permitting a specific selection of what you require. This allows for a more targeted investment in knowledge. In addition, a MACH landscape runs in the cloud, so scalability, infrastructure and possible peak load problems are not an issue. Various components – uniformly linked using APIs – can be used to select any required services throughout the entire value chain and customer journey.
So does MACH only present advantages? Geerlings leaves no doubt about this: ‘No, it’s not that MACH only brings advantages; it also presents new and other challenges. You might compare starting with a MACH architecture with making sketches on a blank A4. It involves considering how to build a system, the services to choose and the areas in the selection process that require attention. A classic platform provides more grip, because it provides a clear view on how things should work.’
‘Classical platforms provide assistance and direction in certain processes: how an order is handled in a commerce monolith or how the CMS works in terms of edit-flow. This is largely set in a DXP. Varying takes effort, but the default is 80% correct and usable’, says Geerlings.
‘This gives a leg up, but on the other hand it may provide less freedom. MACH provides greater freedom in that respect. If your customer journey requires few or even no unique aspects – because your product itself is already more than unique or niche, for example – a classic platform may well be the better choice. In this case, a unique customer journey is less important for the product,’ says Geerlings.
"MACH brings increased complexity as a result of the entire landscape that must be overseen, increased integration tasks and more individual choices. The development of technical knowledge is actually the biggest challenge in switching to MACH."
‘However, we should bear in mind one main current challenge: vendor selection,’ Geerlings emphasises. ‘No platform or community is able to provide adequate assistance with this, like the Cloud Native Computing Foundation (CNCF) or, if you are able to look beyond that marketing veneer, Gartner and Forrester offer. They provide footing in the areas of cloud infrastructure and ‘classic main vendors’, but not yet for MACH services. In late June 2020 however, an initial step was taken with the launch of the MACH Alliance’, says Geerlings.
‘The fact that an industrial group of technology companies have labelled vision and architecture with Microservices, API-first, Cloud Native SaaS and Headless will certainly advance things, as will the fact that they will further propagate and boost the MACH vision’, Geerlings outlines. But this is not all. ‘Technical choices involve a need for stewardship: a genuinely independent and more extensive overview of all MACH services – including companies that are not MACH Alliance affiliates – the options and limitations that can be consulted.’
‘The MACH Alliance might be able to help by understanding the position of services in terms of features and what USPs are, in addition to sharing information about the maturity of the services; how long has a service existed, how many customers avail of it and how satisfied are they with it? For example: what industries are successful with this MACH-CMS or this MACH-Search tool? It is as yet uncertain whether the MACH Alliance will develop into an independent consultancy, but companies will require this once they get to work with MACH.’
The answer to the question whether you should (quickly) switch to MACH is not an easy or straightforward one. Geerlings: ‘Whether it is interesting to get started with MACH depends on several factors. If you have a ‘green field’ to start a new landscape, I would recommend considering MACH, whether for a new target group or market or not. This is interesting from the viewpoint of flexibility and scalability, and in addition may prove to be cost-effective because you only have to pay for the use of services. Things are naturally quite different if you already have a platform, such as Magento, Hybris or Drupal, and you wish to use and create a unique experience or converge a complex value chain in your platform. If so, it might be a good idea to investigate a business case for a medium-long period – three years is a good starting point – to consider re-platforming versus upgrade costs. It is important to start by clearly mapping the business and digital strategy, to determine the services required in the new MACH architecture.’
Classic platform vendors are also moving towards MACH services. The question as to whether you should make the switch thus becomes even more tricky and subtle. Geerlings: ‘I personally think that only a few classic platform players are able to sufficiently reinvent themselves. Sometimes things go inch by inch; consider ‘Drupal Headless’, the APIs of Magento 2 or a PIM such as Informatica. Some platform players will miss out on things if they continue to simply keep their existing license models in position for too long while innovation is also limited. This will help them retain certain customers – probably those who are not too keen to change and develop – but they will surely miss out on the wave-like motion of re-platforming under the pressure of accelerating digital transformation.’
This blog is the first of a blog miniseries about MACH. Next week we will deal with the questions you should be asking yourself once you have decided to get to work with MACH and how to handle your vendor selection.