?? MACH is not the problem. Execution is. ??
Sana Remekie
CEO Conscia, Thought Leader in Composable Architecture, Omnichannel Personalization, Top 10 Influential Women in Tech, Public Speaker
I just read this article, and while it raises some valid frustrations, I think it fundamentally misrepresents the premise of MACH and composability.
You all know by now that I try to see things from different angles and being an engineer forces me to break things down logically - at times, even to my own detriment (this doesn't always work when you're selling!) I have written fairly controversial posts that have made some MACH enthusiasts quite uncomfortable and have even received 'coaching' on what I should or should not say.
Regardless, I'll speak my mind, whether you agree with me or not.
Let’s break this down.
MACH is a set of guiding principles, not a prescriptive solution. If MACH implementations are going off the rails, it’s not because MACH is broken—it’s because of bad execution. You can absolutely make MACH work, but that requires architectural discipline and clear governance over what gets composed and how.
1?? Argument: “There should be no middle layer.” That’s not how enterprise architecture works. Show me an enterprise architecture—built on monolithic, MACH, or hybrid technologies—that doesn’t have a middle layer. You won’t find one. I mean even Salesforce tries its best to sell Mulesoft to every enterprise it can.?
The middle layer exists to orchestrate, unify, abstract out and contextualize capabilities from different systems. It needs to be flexible, unopinionated, and zero-code so that you don’t tie yourself too tightly to any one vendor. The alternative? Hardcoding integrations, turning your “composable” stack into the exact fragile mess you were trying to avoid.
2?? Argument: There is an implication in the article that MACH is about 'composable extremism' i.e going composable is an all or nothing initiative.
Nobody is saying you need to go fully composable. MACH isn’t a binary choice—it’s a spectrum. Some brands will adopt full composability, others will take a hybrid approach. In fact, our customer is a finalist for the MACH Impact Awards for a project where the entire backend is a monolithic Commerce Platform + monolithic CRM + monolithic Marketing Cloud + monolithic Service Cloud—and guess what? It works beautifully because we orchestrate it properly.
Even monolithic architectures have multiple modules/platforms connected to each other.? A typical enterprise architecture has both MACH and non-MACH technologies - so you really can’t get away from the complexity unless you’re just selling to small business/mid-market customers who are fine with something like a Shopify that is pre-integrated with a bunch of technologies out of the box.
3?? Argument: MACH is failing because it doesn’t provide an OOTB fully connected software ecosystem.
Pre-connected software ecosystems contradict the very essence of MACH. If you “pre-connect” everything, you’re forcing an opinionated tech stack and killing the flexibility MACH is supposed to provide. What happens when you need to replace one component? Good luck. Instead of being composable, your architecture becomes rigid, brittle, and impossible to evolve. We need to think beyond composability—we need to be compostable. Systems should be replaceable without burning everything down.
4?? Argument: MACH Architectures require data replication.
Again, nowhere in the MACH principles do you find anything about having to replicate data across multiple systems.? This is an execution problem.? If you can do real-time API orchestration and do it in a performant way (shameless plug: Conscia), there is absolutely no need to do this.? An orchestration layer is in MACH’s reference architecture.
Finally, we need to stop telling the clients that an ‘accelerator’ is going to solve all of the MACH complexities - we’re setting the wrong expectations when we do that.? In the last few months alone, I have seen multiple projects fail because of the over promise of accelerators.
?? The takeaway? MACH isn’t the problem. How it’s being executed is. Instead of blaming the principles, let’s focus on fixing the implementation.
What do you think? Is MACH being unfairly blamed for bad execution? Let’s discuss.
Consultant Technical Business Analyst
7 小时前Following your own principle, Sana, (of breaking things down logically), I would go a step further and say that execution isn't the problem, either; it is the consequence. Entrenchment is the problem. Entrenchment and the desire for solutions that can be plucked, fully-formed, from thin air without effort. That mindset all but guarantees sloppy execution.
Growth, Eco-system & Internationalization Executive | Entrepreneur
1 天前Sana Remekie wise words!
+architectural competence! Bad solution + good execution, still = bad result
Founder, CE0 @ Dotfusion ?? Digital Modernization ?? B-Corp ??? Co-Host "Connect The Dots" Tech Talk Show.
2 天前Good points - Noting that MACH is a flexible spectrum, not a rigid mandate, and that thoughtful orchestration—not dogmatic implementation—is key to successful enterprise technology integration. Actually those words are suggestive - orchestrate vs impliment. Has a nice flow to it...
Getting tangible over the intangibles across Ontario/Canada's innovation ecosystem.
2 天前?? “Systems should be replaceable without burning everything down.” This feels very synergistic with the right to repair movement. Dichotomies are a trap, well put Sana!