From a monolithic software to a modern MACH architecture
In part one, we explained what MACH is and why businesses could benefit from a MACH architecture.
In this follow-up article, we will show you which companies MACH is best suited to, the transformation from a monolithic software architecture to a MACH architecture might look like, and which companies have already successfully converted to MACH architecture.
When does MACH make sense?
For companies that are just starting to digitise their sales channels, have a simple business model with one or two own brands, little technical know-how, and want to try e-commerce for the first time, a centralised out-of-the-box solution is probably the better solution.
More digitally mature businesses that: have complex digital channel requirements and business models; have a high level of technical maturity; and have a need for modern and flexible applications would benefit by switching to a MACH architecture.
Below is a comparison of monolith and MACH architectures based on Amplience:
From a monolithic software architecture to a MACH architecture
Ultimately, the transformation from a monolithic software architecture to a MACH architecture always depends on the individual case.
Step 1
Start with headless
It has been proven to be useful to first convert the front-end to headless before turning to subsequent areas. Many commerce frameworks such as commercetools or SAP Commerce offer a variety of APIs that can be used and implemented by the front-end and thus enable a quick start.
If a suitable CMS system is not yet available, forward planning is also useful here and it should be checked whether further components such as a digital engagement platform or a customer data platform are to be built in the future. Do you also want best-of-breed? or does it make sense to choose a CMS that perhaps comes from the same company and is easily integrated into a customer data platform or digital experience platform?
Step 2
Exchange frequently changing data via APIs
If the front-end has been converted to headless, it is important to check which other applications should or must be connected via APIs. It is advisable to first concentrate on frequently changing data such as price or inventory data in the ERP system and to look at less frequently changed data such as product images or titles afterwards.
In general, you should always define the business impact of each application and switch the system with the highest impact to API-based communication first.
Step 3
Cloud development and building microservices
New microservices should be developed and made available on a cloud architecture in order to make them easier to use by other areas. The conversion of commerce back-end services to modern and flexible mircoservices makes sense in the case of rapidly changing customer requirements or in that of the overlapping use of services, such as a loyalty system that is used via several channels, e.g. POS, online shops and apps.
The use of APIs and potentially new microservices on a cloud architecture results in many advantages for the company and ultimately also for the customer experience.
Firstly, you have the independent development of the front-end and the downstream services, which can be worked on simultaneously by several teams. Secondly, you also benefit from the simplification of those services and the simplified scalability of new services.
All together, this leads to faster responsiveness to market demands and also faster roll-outs of new functions.
What does MACH architecture mean for your project?
Project management is more complex
- Integration of different systems also means bringing together different stakeholders on the client and the service provider side.
- This mean that they must also be available during the course of the project.
- Scoping requires a high degree of accuracy, all systems and related processes and data flows must be taken into account.
Coordination between the development teams must be appropriate
- Separate development teams are possible and in fact necessary, but technical dependencies must be clearly defined and taken into account e.g. connection of front-end and back-end via interfaces.
Definition of the required information and data flows
- Data flows and origins must be clearly defined. This sounds simple and logical, but is often complex when it comes to evolved systems. Redundant data storage and isolated solutions are a no-go when developing a headless architecture.
Companies that have switched to MACH architecture
Amazon, now the largest e-commerce platform in the world, started as a humble bookstore. A two-tier all-in-one platform was a perfect fit for this, then, small company. However, as Amazon began to grow, it faced a pressing problem with the scalability of the system. Typical bottlenecks such as lengthy implementations, large difficult-to-manage databases, problems adding new features, and fluctuating website traffic delayed the company’s growth.
Zalando reached its capacity in 2010. The company had already transformed itself from a modest shop to a globally popular fashion brand. Its current e-commerce system could no longer handle the load. Switching to microservices gave Zalando the opportunity to speed up the integration of new innovations and conduct A/B tests to achieve the best possible conversion.
REWE scales its online grocery marketplace with flexible MACH architecture. In 2020 the company used MACH to double its number of click-and-collect services in just a few weeks, launch a cross-sector fulfilment platform, and ultimately provide convenient access to groceries across Germany at a very critical time.
Netflix was one of the first companies to realise that a monolithic architecture is not an optimal solution for a complex application, as the components in a monolithic application are tightly interconnected and a single failure can lead to several days of downtime. In the VOD business, this is a dealbreaker for users and the risk was too high to bear.
Conclusion
An analysis of the internal (customers) and external (employees) needs is usually required to define and then implement an appropriate architecture.
This is where our many years of SQLI experience comes in. We know the challenges businesses face and will work collaboratively to develop the infrastructure to optimise traditionally fragmented processes.
But, there's not a one-size-fits-all. Each business is different and we'll Each business is different and we look undertake an extensive evaluation to assess readiness, risks, benefits, and importantly ROI — and what this means for your business.
Ready for more?
Our team will be happy to conduct a MACH feasibility check on your business.
Get in touch