The MACH Monolith
tim-2020-small

Tim Benniks

Twitter
8 min read

For years, the headless concept has been going through the nerd vine at boardrooms, pushing execs to take action. And now that everybody is jumping on the bandwagon, there are some interesting developments: traditional monoliths are using new messaging with the words “composable” and “headless” in it, and headless systems are integrating more monolithic-like features. Meanwhile, brands that need to make sure their architecture is scalable, secure, and future-proof have no idea what to do and make decisions out of sheer FOMO. Combined, these three things have created the beast I like to call the “MACH Monolith”.

MACH and its approach to building digital architecture is the way to go and it can be an amazing journey. However, be careful to apply the MACH principles correctly. In this article, I’ll outline what that means.

I think we can agree on one thing: web development is complex. There is a reason it has the word “development” in it. For the longest time, software vendors have aimed to simplify the job by creating suites of software that cover all manner of features a business would need. From front-end accelerators to rich content editing features.

This approach worked pretty well: one platform to deal with all digital business challenges. One place to point the finger if things went wrong.

However, there are drawbacks to this approach. Businesses have to buy into how the suite is developed as a product. You get vendor lock-in, and you are dependent on how its roadmap is defined. To speak in developer terms: “this truly sucks”. It holds back innovation and makes developers break out of the system by building custom stuff, rendering the architecture flawed when updates need to happen to the underlying monolith.

A paradigm shift

I’m explaining all this as I want to highlight our mindset in web development. Even though everything is headless and API-first, we are still operating in the “suite” paradigm. Even the technical people who tried to break out of the monolith approach in the past couple of years still have this mindset. Paradigm shifts take time, and we are currently in the middle of one.

In the modern composable world, where architectures are created by composing with best-of-breed tools, we need to realize that there is not a single piece of software that can take the sting out of how hard this is to do. There are no full-chain covering pieces of software in the SaaS world. This is a bitter pill to swallow as this is what we were used to with suites.

The suite approach still influences our mindset, and people often tend to grasp back to this type of approach, even when designing a modern composed architecture. This is reflected across disciplines, and this is where the “MACH monolith” is born. The MACH monolith is an in-between version of the old suite approach and the new composable way of working. Let’s talk about how the MACH monolith came into existence…

Headless first products implement monolith-like features.

The market doesn’t seem ready to embrace API-first design and composable architectures fully. Mainly because only tech people liked the headless space. APIs are tech people’s native language. Architectures are created with a tech hat on, and because of that, the experience is unfriendly to practitioners like content editors and marketers. Headless systems are built by and for technical people. API-first products are ahead of their time as there is no glue to connect all composing elements, so all stakeholders benefit. There is a way, but let’s talk about that later.

Headless systems have to become more friendly to practitioners or lose market share.

The result:

  • 1. Integration fields into the CMS into other headless systems to unify the editing experience and offer a singular API for developers (think: Search, DAM, PIM, Commerce, CRM, personalization).

  • 2. Preview functionality tightly coupling the front-end to the preview SDK of the CMS.

  • 3. Page composition abilities inside the CMS data model adding contextualized data for compositions into the clean data model of the content items in the CMS.

  • 4. Adding routing and sitemap-related content mapping in the CMS, so practitioners have a better overview of the system.

All these “features” put the CMS in the center of the universe of digital architecture. Some questions come to mind: what if you have multiple cms systems? What if you want to switch your commerce engine, but it has been tightly coupled to the CMS? What if you're going to change CMS? What if you need to add another channel like a TV app, and the data models with desktop presentational context make no sense?

The answers to these questions result in mountains of pain for developers or going through a greenfield re-platform of the system every few years. Things get too interconnected, and concerns are not separated. Throw the old architecture in the trash and start anew. This gets very expensive very soon.

Surprisingly, the original, highly innovative API-first companies are now acquiring other semi-headless products to add to their portfolio. This is to stay relevant in a slightly lagging market as the paradigm shift hasn’t been completed yet. Software vendors need to serve the mid-market tier of businesses with an accelerated time to market and ease of use, or website-in-a-box systems like WordPress or Shopify will outperform them.

Suites are implementing hybrid headless and pretend composability

This gives us a nice bridge to what traditional suite vendors are doing to stay relevant:

Suite products are implementing a form of hybrid headless. This means that you can use their system in a headless API-first way, but you need to stick to their way of working. You need specialized knowledge of the system to work with it. This goes against the API-first proposition of having total developer freedom. However, you can now say you have an API and are therefore headless.

Suite vendors are splitting up the suite or start buying additional service providers and selling these as composable pieces to their platform. This is not real composability as you don’t have the freedom to choose your best-of-breed tool. You can only select from the vendor’s pool of services. These services are generally tightly coupled to the suite's core and, therefore, hard to deal with. Being interconnected and indivisible is at the heart of monolithic software, not composable software.

I like to call this approach “compostable” architecture.

What is the MACH Monolith?

There are a couple of patterns we see over and over.

The MACH Monolith

When the separation of concerns is not respected, an indivisible and interconnected bundle of best-of-breed tools is created. Due to this complicated scenario, it is tough to discern what is connected to what, and you have created your very own vendor lock-in. Things work one way, and only the original build team understands how things work. The onboarding of new team members becomes complicated, and frustration amongst developers will set in.

Contextual composition data is often stored in the CMS, and it gets mixed in with the clean data model you started with. For example: adding a checkbox that makes a particular item “featured” so it shows more prominent on the page. This is a design decision for the item in a specific context. What if that context changes when the item is shown in a different place on the website? Composing pages with specific user contexts should not happen in a CMS. It causes dirty data that has to be dealt with over time. The composition of pages in the context of a user should occur in the front-end or a composition platform.

Another approach could be that systems are not fully interconnected together. That’s a great start, but where does this connection now tend to happen? In the front end. This means that the front-end application contains all the knowledge of the link to all the systems that compose your website. This is a considerable risk for maintenance, security, and it’s not particularly future-proof. In a perfect world, a front-end should be “stupid” and “stateless” to be iterated upon quickly.

Other than these technical complications, there are also business problems. What if the architecture does not behave the way it should? It has become complicated to figure out where it went wrong. To whom do you point the finger if you find the issue? According to your technical documentation, the best-of-breed tool, your team who made architecture decisions or the agency that built the setup? A business with a failing architecture that can’t point the liability finger will eventually re-platform and start the process from scratch. The composable monolith is much worse than the traditional suite, with only one vendor.

The solution

What we need is an opinion-less platform that helps the orchestration of best-of-breed tools. This platform should be friendly to both developers and practitioners. It should have a great SDK that is entirely tech agnostic, and it should have no-code tools for practitioners to work in a way where they do not notice they are composting pages with different headless sources.

Even though the paradigm has not entirely shifted towards proper composable architectures, this platform already exists. It is called Uniform, and I’m proud to run their developer relations team. Uniform will solve many issues developers, architects, and practitioners will face in the coming years. Why not take a look now before you fall into the composable monolith trap?

https://uniform.dev

Posted on 3/28/2022 in
ComposableDXPHeadless CMSHeadless CommerceMACH

Download the 451 Research report on Uniform

Startup Uniform looks to fill in the gaps with its composable DXP