Recently the MACH Alliance welcomed its 100th member and both the Alliance and its members have seen incredible traction in the last few years.
It continues to amaze me how fast ‘composable’ has gone from a whisper in the corridors of the cool developer kids to what is quickly becoming a default architecture for digital experiences created for and by enterprises.
To understand how composable architectures arrived in the marbled halls of enterprises, we have to look back around 10 years where it all started with the decoupling of the front-end and back-end.
Back then, it is fair to say that the web was in trouble. The architecture didn’t scale well, security concerns were rampant, it wasn’t performant enough, and it was all starting to lead to walled gardens such as App Stores and company pages on social platforms.
At the time my co-founder of Netlify and I were toying around with different ideas of building something to try and address this when we started looking deeper at the concepts behind standalone frontends.
I’ll admit that at first the notion of not having the backend render the presentation layer or UI for every visitor seemed like a technical curiosity at most, but I soon started realizing the potential impact of this decoupling could be tremendous.
First off, it would allow for removing the dependency on a single origin server for the websites themselves. Instead, you could have multiple points of origin, and you could distribute the front-end leading to higher scalability, better security and faster load times.
Secondly, it could give developers superpowers. Instead of having to send off frontends for implementation into monolithic backend systems, you could instead just pull data IN from those systems. That would mean no more squeezing frontends into templates that didn’t fit, and no more waiting around for implementations. Just push the code live and you’re done.
Lastly and perhaps most impactful, it could pave the way for a composable architecture. Not having a monolith dictate the digital experiences and touchpoints would leave one free to compose best-in-class components into nimble solutions that could be upgraded interchangeably and continuously. This would greatly enable omnichannel solutions as digital touchpoints multiplied and could create a whole new digital experience economy.
This approach promised to be a fundamentally better way to build digital experiences, and we embarked on creating the first front-end cloud in the market.
Of course, back then you really couldn’t build digital experiences of much significance as the ecosystem of services needed simply didn’t exist yet. An example of a lacking element was enterprise-focused e-commerce as that existed as monolithic offerings only.
However, the market quickly started evolving tremendously. In fact you’d be hard-pressed to find a single CMS or e-commerce solution that has come to market in the last few years that isn’t natively headless, and today the notion of decoupling the front-end has become the default.
This saturation of the category also meant that in the last few years, we’ve started seeing enough services to cater to building out complex digital experience platforms in a composable manner.
That in turn meant that the large analyst firms feeding enterprises insights into tech trends started leaning in, and composable architectures started becoming crystalized from a business point of view.
“DXPs… are built by enterprises, not bought from vendors”, wrote senior analyst from Forrester, Joe Cicman, in 2022, referring to the notion that enterprises would now piece together their platforms from best-in-class providers rather than just buy a huge monolith from a single provider.
“The Future of Business is Composable” wrote Gartner. The reasoning is that “building blocks of composable business enable organizations to pivot quickly, provide resilience, and make development faster, easier and more effective”.
But if the analysts provided the “Why” of using composable components in your digital architecture, the enterprises were still to some extent left wondering “How?”.
What should a “composable” component actually look like and how should it operate? The trademark of a burgeoning category that in essence is deeply technical and has a broad reach is that it necessarily contains a certain amount of murkiness to start with. The path hasn’t been beaten, and guardrails are something that is typically built out gradually.
Clarity was needed to help enterprises along, which was the reason for the birth of the MACH Alliance.
There was a clear focus from the outset. To cut through more or less substantiated vendor claims, and provide real clarity for anyone looking to adopt composable components for digital experiences.
This led to a rigorous process to certify the companies providing the needed cloud-native, API-First, multi-tenant SaaS offerings, and the enablers and service companies to implement them.
Today, thousands of hours are spent every month by an army of dedicated volunteers and a core MACH Alliance staff to bring the best education, events and certification processes to help enterprises start embracing composable architectures and there are now MACH Alliance ambassadors working at many of the most prominent companies in the world helping to spread best practices to an ever-growing audience.
And it’s the success of this movement that leads us to this next step of composable implementations and the next step of the MACH Alliance.
Composable and MACH are no longer just employed for single projects and stand-alone solutions. With scale more enterprises find themselves needing to integrate larger solutions with ever more components and to find ways to work together with existing technologies.
To solve for that we need to turn our gaze towards interoperability.
After onboarding almost 5 million developers and businesses I’ve had countless stakeholders share why they want to go composable and headless. Amongst the top reasons are always faster time to market, greater flexibility and better conversion rates.
However choosing the right components like a CMS or commerce solution, doesn’t in itself deliver on those promises.
If they don’t interact well, and if operations are kept as usual, with the same way of siloed groups manually running infrastructures in a traditional waterfall structure - then even the best headless APIs on the planet can’t give you a fast time to market, nor a performant digital touchpoint.
If a company wants to stay agile enough to be able to implement new solutions and upgrade them gradually instead of lifting and shifting monoliths, then it needs to reconsider how it operates those digital experiences and to what standards those solutions will interact.
This is why I’m so incredibly excited to be involved in the second phase of the MACH Alliance - The Interoperability Standards.
The Interoperability Task Force was launched with several key technologists at member companies and a mandate for 2023/2024 to produce assets that will help buyers understand the landscape.
This year the task force will release a number of assets on a regular basis, covering audiences ranging from architects to business stakeholders.
We’ll cover areas including:
- How organizations can manage change in this digital transformation:- Who should be involved in a re-architecture using MACH principles?
- How does this architecture unlock business goals?- What a composable workflow actually looks like (including high-level current common practices such as “infrastructure as code”)
- How parts of the system interact:- What composition/orchestration layers are needed to be successful? How does this all fit together?- At a lower level, how are individual components expected to interact with one another? How do they work in tandem to unlock end-to-end scenarios?- How are legacy components integrated into a modern, composable architecture?
How can architects be sure that individual components follow MACH principles? How can they avoid monoliths?
Assets will include:
- Podcasts
- Whitepapers (such as “How to evaluate and integrate composable technologies”) and
- Reference architectures, including a “code first” model in GitHub so organizations can create their own as needed for internal planning or building RFPs.
We’re excited to bring about a focus on this next set of best practices to help ensure successful MACH projects as they continue to scale inside in size and complexity!
Author:
.png)