MACH: the future of software architectures?

MACH, WHAT DOES IT MEAN?

TERMS AND DEFINITIONS

Since the beginning of the 2000s, we find architectures (Web, in particular) composed of solutions that can be qualified as “monoliths”: a structured and coherent application set, with a “front-end” part, i.e. interfaces visible to end-users, a “core” part, with functionalities, a data model  and a “back-office” part to configure and then operate the solution.

This structured set can be an e-commerce solution, a web content management solution (CMS), or a specific business application.

These applications were generally hosted “on premise”, on its own machines, by a hosting company, and priced according to the “technological power” required to operate the application.

Technologies have evolved a lot in the last 20 years, and the “MACH” architectures, which break with these old architectures, have gradually become a reflection of this.

Here is the definition of what is behind this new acronym, M.A.C.H. :

M = Micro-Services: an architecture in which each component, each “service,” provides a specific, technically and functionally well-defined function that can be designed, developed, and deployed individually. These are referred to as components, sometimes as “Lego™ bricks”.

A = API-First: an architecture in which each solution, each component, each service, will expose its own APIs and consume the APIs exposed by the other components (or third-party/external services)

C = Cloud-native: architecture available in a cloud, where components are natively considered to be deployed in a cloud (public or private) and take into account the characteristics related to these infrastructures such as scalability, isolation, security, configuration

H = Headless: architecture in which the “visible” part – the “front-end” – is totally disconnected from the services and applications that expose services and data. A headless eCommerce, for example, will not propose a front-end – or if it does, it will allow to use it or to use another one, created specifically, or based on an existing front-end framework. A “headless” CMS, for example, will offer tools and functions for content creation, content lifecycle management, contribution management, etc., but will not predict which solutions, technologies or applications will consume this content. This headless “mechanism” requires the use of APIs so that different applications (existing or developed, front-end or back-end) can manage content and services, for some, and the display of this content or services, for others. The APIs form a common ecosystem of services, allowing the interoperability of solutions, and in particular this separation between “front” and “back”.

OBJECTIVES AND BENEFITS

MACH architectures have several objectives, such as taking advantage of all the developments brought by the Cloud on the one hand, and by all the DevOps tools and processes on the other. Thus, the management of the development and deployment lifecycle is industrialized, automated, and of better quality. These architectures allow for immediate or recurring, regular deployment, and thus provide agility in the ability to deliver as often as desired, good integration with an agile methodology and its regular deliveries, and flexibility to deliver – modify – and re-deliver without additional “effort.

The objective of microservice development is to achieve a coherent application breakdown – which can even benefit from a DDD approach (Domain-driven Design) – by delimiting each feature (or coherent group of features) and isolating it in a dedicated microservice. This way, it will be possible to dedicate teams to each microservice, each team being able to decide on a tooling, technologies, and a development process adapted to it (and potentially different from other teams). These teams work easily in parallel, and deliver their services that expose the APIs that allow them to communicate with each other. The microservices approach will allow an excellent appropriation of the functionalities thus developed, and the exposed APIs will be fully mastered – this was one of the major concerns with monoliths and their lists of partial APIs, with levels of granularity that were not always well thought out, and with behaviors that were sometimes uncertain. Finally, the microservices approach has another important virtue, that of allowing a “Component” approach, and above all, a “gradual” transformation of an “old” architecture to a “modern” one, by successively developing microservices and gradually disconnecting an existing functionality or service to use a new dedicated microservice instead. This “composed” architecture approach also allows for a mix of “off-the-shelf” solutions, installed monoliths, and new microservices components.

The future is not only made of screens. At least not only the ones we know today: PCs, tablets, smartphones (in no particular order). Tomorrow’s man-machine interfaces include virtual and augmented reality, connected TV screens, screens in cars, and… no screens, especially in the “smart speakers” that are flourishing in our homes. These new architectures, especially headless, promise the agility and flexibility linked to the development of services and functionalities that are agnostic of the way they will be consumed. Whether I order tomorrow from my car, my TV, or my connected speaker, the services that will offer me products, take my order, and notify me of its evolution will be similar, and developed only once. Only the “front-end” part will be developed for as many “channels/modes of interaction” with the users as necessary. Or even absent, in architectures developing IoT in particular, which can consume services or update information without the necessary “visualization” brick by a user.

CHALLENGES AND RISKS

MACH architectures allow for partial or total replatforming, with teams of developers at the controls, and a promise of agility, flexibility, and modernity for both IT and Business.

However, these architectures also have associated challenges and risks. These architectures are complex to design and implement; they require specialized expertise, both in the architectures to be implemented by the architects and by the development teams, who must master recent and sophisticated concepts, tools and frameworks.

These architectures will often bring together many technologies and frameworks, whether for the development of microservices, API management, headless by design or a variety of different front ends. One of the complexities of these architectures is precisely the ability to coexist with these multiple technologies and the ability to understand the integration and orchestration of the software chain at the design stage and throughout the successive developments on the platform.

The headless part is a thorny issue from a governance point of view: many solutions will suggest developing everything specific on the “front” side, since you can do “what you want” on the front, it will be “enough” to call the right APIs of existing or newly created services. Two problems then arise: the risk of deporting business rules, or even a whole part of the functionality, solely to the front end (in a front end) – in this case, we are at the opposite end of the spectrum from the philosophy of a single, front-end agnostic development. The other problem is the greater complexity of the front-end, which has to manage – in addition to the visible part – the plumbing for managing the API calls of the various services.

Many MACH architectures will include “editor components”, open source frameworks, and specific developments. A “typical” e-commerce architecture, for example, will include : 

• a MACH e-commerce solution from the market, which will provide the “generic” functions of e-commerce in-house e-commerce components (micro-services)
• dedicated to certain functionalities specific to the company’s business a headless CMS solution
• to manage content models, page types and editorial content a front-end solution to manage one (or more) PWA front-ends
• specific developments to implement original and different customer paths based on the chosen solution a third-party service (or component) for “search” (products and editorial content)

In this example, a great complexity lies in the “glue” between all these services, components, applications. API gateway and management, multiplicity of frameworks (even compatibility between different frameworks), horizontal and vertical scalability, SEO, performance… are all challenges of this type of architecture, and are not easily solved.

All these applications, solutions, components, services are, MACH must, in the Cloud. Each one is in its own Cloud (SaaS, PaaS, IaaS, single-tenant, multi-tenant, public cloud, private cloud, there’s something for everyone). There is also a multi-cloud orchestration challenge (architecture, interoperability, performance, governance) that does not seem obvious to address.

Each solution (MACH or not) comes with its own pricing model. The cost of this multiplication of services is often complex to estimate correctly, as the pricing parameters are of course different depending on the nature of each service used.

Finally, and beyond the MACH architecture, the “classic” repositories (MACH or not) continue to provide real benefits – while certainly making the architecture to be implemented more complex:

• a PIM to manage the Product repository
• a DAM to manage the Media repository
• an OMS to manage the inventory and order repositories, and to manage the orchestration of the latter
• a CDP to manage prospect and customer data

Many solutions (“old fashioned” for the most part) that we will have to add to our new MACH architecture.

CONCLUSION AND CLEVER AGE’S OPINION

Clever Age didn’t wait for the advent of the MACH movement to carry out projects with similar characteristics; since 2013, several retailers, with Clever Age’s help, have designed, implemented, maintained and evolved “composed”, rich, headless, API-based e-commerce architectures in the Cloud – with a clear division of services, distinct technologies between front-end and core services, outsourced scalable search, enriched APIs, and automated and regular deployment in a Cloud infrastructure.

For more than 5 years, Clever Age has been publicly promoting an application division between the front-end, the business services isolated in components, and the master data repositories exposed in real-time APIs, all to offer an architectural framework that allows true omnichannelity.

The promises made by the promoters of the MACH movement, grouped together in the MACH Alliance, are real, interesting and value-added. However, it is illusory to think that these architectures can be applied today to any new “digital transformation” project. They require a strong willingness and ability to develop custom-made solutions, large development teams, the implementation of a software factory, the integration of expert architects, an attentive technical governance, a strong mobilization towards agility, and the inclusion in budgets of a significant initial and recurring cost to manage the life of these new architectures in constant evolution.

Mindful of its duty as a pragmatic and independent consultant, Clever Age – for once – could well take up Forrester’s intervention at the “Modern Commerce Day 2021” event: “these architectures represent the future, but it will take at least 5 years for them to become mature”.

With ambitious programs and an unwavering commitment at the highest level to deliver innovative, differentiating, high-performance, flexible, and rapidly scalable services, Clever Age will recommend these promising and justified MACH architectures and give these projects the expertise and value they represent.

But not all replatforming projects, especially e-commerce, will benefit from these new architectures, when they are not compatible with the size of the teams, the level of software expertise, the ambitions of the COMEX, or more prosaically the budgets of the organizations dedicated to the “digital transformation”.