Is your organisation ready for MACH? 7 questions and answers
28 January 2022
MACH is nothing like a classic (on-premise or IaaS) platform in terms of organisational requirements. Before exploring the options of working with MACH or actually starting to work with it, every organisation should start by asking themselves various questions.
Microservices, API-first, Cloud-native SaaS and Headless (MACH) is a concept that is a lot in the spotlight currently. Following the first blog: ‘How valuable is MACH for your organisation?’, in this blog iO Technology Director Friso Geerlings describes seven points to prepare your organisation for a MACH architecture.
#1 Do I have a – somewhat – Agile organisation?
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.’
#2 Do my front-end developers have knowledge about software development and technology?
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.’
#3 Can we meet the integration challenge?
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.’
How about a bigger digital presence?
Gone are the days when a website was enough for a proper, digital presence. Our experts happily assist in bringing about a digital ecosystem - optimised and on-brand - fit to serve your business goals.
#4 How do I ensure a secure login process?
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.
#5 How do I ensure a good MACH test set?
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.
- Microservices, API-first, Cloud-native SaaS and Headless have secured their place in the business world. These concepts have existed in their own right for some time and are already fairly well known, but the umbrella term MACH is new. Will it soon be mentioned in the same breath as Cloud and SaaS? And when will it be worth investing in it? Find out in this white paper.Read more
How valuable is MACH for your organisation?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, an umbrella concept is now attached 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? IO Technology Director 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.Read more
Composable architecture: how agile can one go?The composable approach to architecture is known for its flexibility, scalability and the freedom it offers. However, many organisations have to deal with legacy, are tied to long-term contracts with software providers or simply don’t have the right people and in-house processes. So how do you switch from a traditional IT architecture to a composable one? This article gives you a realistic insight into this transition.Read more
Flexibility and a shorter time-to-market with container technologyToday, structural IT decisions often require substantial investments, but they are also more important than ever when it comes to achieving your business objectives. The right vendor choice is not only important in terms of set-up and implementation, it is also essential to remain future-proof. Scalability and flexibility are necessary for the continuity of your business and structural IT decisions you make are the basis of this. There are two modern ways to achieve this: with serverless and with container technology. Serverless requires less infrastructure and networking knowledge, whereas container technology is less vendor-dependent. In this blog, we will explain how container technology can offer a solution.Read more
Challenging business logic problems? 6 reasons why Azure is the right cloud platformFlexible scalability, the right toolbox for business logic, the availability of specialists, data-driven work and appealing pricing. These are some of the reasons why companies are increasingly turning to public cloud integration platforms to build their business and integration layer – better known as iPaaS (Integration Platform as a Service). Like Microsoft’s Azure Integration Services (AIS), for instance. Technology Director Friso Geerlings zooms in on the power and practicality of Azure, especially for business integration and processes.Read more
Composable architecture provides business agilityComposable architectures are gaining traction and credibility as the most efficient way to respond to future user expectations. Unlike a suite approach, where a single vendor supplies all the software components you need, composable architectures focus on composing small, loosely coupled components and using existing best-of-breed technology that can be integrated to form innovative solutions and work together to supply the optimal customer experience across different channels.Read more
Forget Headless: Operational Excellence is Next-Gen E-CommerceIn uncertain times it’s too easy to retreat to a hold position, but that’s rarely a winning strategy. Today businesses and organisations are looking for easy wins and scalable digital solutions. What can we offer that is up to the job of weathering the unpredictable storms of changing consumer needs and economic and social upheavals? Our Software Architect Bavo Janss has taken a walk down memory lane, and assessed the current state of affairs, and is here to tell you that Operational Excellence and composable commerce is the answer to all of the big questions we are facing today. Read on to find out how we can prepare to face the future.Read more
Headless systemsA headless platform offers a lot of new possibilities for companies. It fits into a digital landscape that connects your customers with your business processes. But what exactly does it mean? And can your company handle the complexity of headless systems? In this white paper we will separate the facts from the fiction and guide you through your first steps in the headless world.Read more
#6 How do I get an overview of all costs?
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.
#7 How do I manage the business and technical aspects of a MACH architecture?
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.’
Read the full story about MACH in this whitepaper.
The 7 answers in a nutshell
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.’
Friso GeerlingsTechnology Director iO Eindhoven
At iO, Friso spends his day taking on only the most complex tech challenges for various high-profile (financial services) clients. All while getting the most out of iO’s tech teams and building connections between developers, users and systems. He regularly publishes articles of his own to further strengthen these bonds.