Is your organisation ready for MACH? 7 questions and answers

Openness and interoperability are typical of the MACH architecture; applications built up in manageable components instead of monoliths. Replacing, improving and deleting services and new releases are relatively easy and do not require the landscape to be completely reformed. The ‘composable’ MACH architecture provides a great deal of flexibility and allows for a much higher rate of change, and the Agile philosophy ties in with this perfectly.

‘Starting to use MACH does not necessarily require your entire company to be Agile-designed in advance; but the department or business unit where you are going to start using MACH must be. Start by appointing a good and experienced Product Owner, preferably someone who can combine the interests and strengths of individuals and teams from the business, and, where MACH is concerned, is informed of the technical requirements. Establish a self-organising team around the Product Owner for optimum control of the technical release pipeline’, says Geerlings.

Geerlings continues: ‘Controlling the technical release pipeline is of main importance because you will want to profit from the high speed of change from the start. The initial team objectives involve being in control of the release process and Continuous Deployment (CD). If this does not yet run smoothly, you might consider carrying out more releases. There is a reason why the saying ‘If it hurts, do it more often’ is heard so often in relation to release processes and CD. Agile is a precondition for the proper design of this process.’

More reasons for the importance of organising Agile are the dynamic and cyclical processes. Geerlings: ‘Setting up MACH constantly involves the relationship between choosing services and designing the complete architecture. At iO, we noticed this clearly in a project in which we designed a MACH architecture. We initially decided on Contentful as headless CMS, and during the process found that Storyblok was a better option because it has better preview capabilities; which was one of the requirements. Examples like these truly emphasise the importance of the preparation process.’

MACH services offer APIs that are unlocked in a front-end: the headless component of the architecture. Geerlings: ‘Front-enders with a design or multimedia design background usually have trouble managing this. It is quite different from a classical platform, where the work has a stronger focus on visualisation. Technical basic skills and software development qualities are of much greater importance for front-end developers working with MACH services. The front-end(s) are built on top of a set of MACH services and connected using APIs, which requires knowledge of frameworks such as Vue, React and plenty of experience with JavaScript.’

Geerlings continues: ‘A MACH landscape can be composed entirely according to individual requirements, the front-ends can be unique and integration involves customised work. It can be compared to an ecosystem built from your own unique business needs. The success of products and services depends on end users, which makes UX and User Testing more important than ever. After all, the objective is to succeed with a unique experience and optimum conversion. The motto is to test concepts and prototypes among end users in good time and use their insights to improve the designs.’

MACH involves more technical challenges than a classic platform because it requires an overview of the entire landscape, greater integration and more individual choices. The development of technical knowledge is by far the greatest challenge for companies in their transition to a MACH architecture. So what does this mean?

‘Complexity increases along with the size of the landscape. If the MACH landscape is still small and consists of two to three services, initially it is fairly easy to link them point-to-point. The expansion of the landscape often results in the need to introduce an integration and access layer, such as an API Gateway. This layer is used to control data transfer and (API) logic, something that will be of huge importance if external services of partners are linked to your MACH landscape,’ according to Geerlings.

Geerlings continues: ‘This requires knowledge of common technologies such as REST, APIs, JSON, JWT and OpenID Connect, and in addition some knowledge of message queueing, AWS or Azure Serverless, Webhooks and GraphQL may be required for more complex set-ups. The API Gateway is another example. Designing and developing an API strategy, including API design, API versioning and accompanying developer experience are typical and important integration skills to have on board in a large MACH landscape. Plug and play is not MACH’s forte because they are intended for use by developers. Compared to a classic platform, it requires more development work and less configuration, something that is usually enthusiastically welcomed by development teams.’

‘Companies that embark upon a complex project like this often involve digital partners such as iO to bring in knowledge and give the project a good kickstart. In addition, a digital partner brings in knowledge about complex and specialist aspects and develops and integrates them. Following an extensive knowledge transfer, these partner resources are commonly scaled down once a strong basis allows companies to continue independently,’ says Geerlings.

‘The main challenge in relation to MACH is integration. Although the services – which feature the powerful and carefully designed data models and logic you design – in themselves provide good functionality, things can really go wrong during integration. These crucial aspects definitely require the right knowledge, whether in-house or through a digital partner.’

While a classic platform features an integrated, central login, this must be set up for a MACH architecture. In some cases, a MACH landscape is limited to one, two, or maybe three linked services. If so, security and login are usually adequately dealt with in the individual services. While double login and rights administration is carried out quite easily, things will change as the landscape increases or starts using an integration layer. In this case, roles, access rights and credentials are divided over various microservices; dealing with end-to-end security is another issue.

‘You will be entering the area of Identity and Access Management (I&AM) and Single Sign-On (SSO). As the landscape increases, I would recommend removing I&AM and SSO from the services and ranging them under an Identity and Access Management platform, such as AWS Cognito. This allows a well-designed SSO and role-based access control and demonstrate their function. This set-up has many advantages, in particular if these MACH services are used in a certified or regulated market landscape, such as ISO 27001, PCI-DSS or in the care domain’, Geerlings explains.

The MACH architecture is easily tested and suitable for automated test streets, which are also of great importance for frequent releases. Services can be tested one by one because MACH services are made accessible via APIs. This makes the entire landscape far less of a black box than a classic platform.

‘A separate Quality Assurance (QA) environment is commonly set up for extensive testing, which requires a good, automated and reliable test set. The MACH architecture provides this. ‘Release often’ is a strategy that perfectly suits MACH, but only if the test set is in order’, according to Geerlings.

Having test data provisioning organised is important but not always obvious: ‘The availability of good and realistic test data and including these data in the (test) MACH service may be an issue. The automated loading of test data really should be a criterion for the choice of a vendor. You might consider investing in the automatic anonymisation of data from your production environment for testing in the long term’, according to Geerlings.

A monthly fee applies for each MACH service. Geerlings: ‘This may sound very surveyable and attractive. The implementation of a classic platform involves considerable up-front licence fees, while MACH services provide the freedom to opt for ‘fit-for-use’.’

Geerlings has something to say in relation to this: ‘It is important to have a good understanding of a service’s pricing model before making a choice. If your ambition is to scale to large numbers of ‘low value’ users, the costs for services with pricing models that settle per end user may sky-rocket, in which case it might be better to pay for actual use, such as the number of API calls or bundles of API calls. In addition, the development of the MACH ecosystem involves the need for SSO. This is usually where the enterprise version of the MACH services comes in to support this: SSO is not commonly included in economy starter tiers, and enterprise versions are rather pricey.’

‘A MACH landscape is usually as expensive as a classic platform. Starting on a limited scale – with few services or few users – provides an advantage, making the start-up costs considerably more attractive compared to a monolithic platform. It is recommended to build the business case for a MACH landscape around aspects other than the supposed cost advantage. Investigate issues from perspectives such as business agility, the option to create a unique experience or the improved incorporation of complex value chains. MACH truly provides added value in these areas if this is relevant for your business’, Geerlings emphasises.

Geerlings: ‘A MACH architecture requires dual monitoring and the design of two cockpits: business operational and technical operational. Making your entire performance surveyable in detail allows for easy pinpointing of any issues; consider a combination of Application Performance Monitoring (APM), Analytics and BI. This naturally involves tools ready for MACH.’

As demonstrated, a MACH architecture involves so much more than just starting to use an online SaaS platform. Geerlings concludes: ‘Experienced integration and front-end specialists – either already employed in the company or involved as a partner – are vital. The technical issues that come with MACH are quite complex, in particular if the landscape is developing into an ecosystem. I would recommend starting with a limited experiment and continue by making conscious choices after scaling up to more than two or three services. This may sound obvious, but it is not necessarily simple. And although MACH allows the easy reconsideration of choices for each component, it’s ultimately more difficult to replace the landscape ‘cement’. Test in good time, monitor wisely, secure and integrate with expertise.’