A Technologist’s Perspective on the MACH Alliance

This article presents my personal perspectives on the MACH Alliance, which I see as an organization that pools resources from multiple software vendors to market their offerings by focusing on specific aspects of composable solution architecture.

Currently, I have the freedom of not representing any vendor, and honestly no axe to grind or anything to promote, so I am free to speak my mind. Even when I have a job working for a vendor, I always consider my role to be that of customer advocate, which I must somehow balance against the needs of my employer. In the end, my integrity, which is lifelong, depends on my honesty, where any job is only temporary. I am honestly disturbed by the lack of clarity and honesty from software vendors.

TL; DR:

Marketing organizations are irrelevant, even suspect, to technologists selecting software vendors.

Organizations and enterprise solution architects should evaluate companies and products based on critical factors such as customer base, personal relationships, vendor stability and prospects, SLA and support offerings, product capabilities, internal architecture and implementation, and underlying components rather than on a limited set of criteria including membership in exclusive clubs.

Companies and individuals invested in old patterns fear change, especially significant paradigm shifts. At its emergence, the MACH Alliance may have provided some value for promoting composable architecture, and vendors in this space should be thankful for that. But I think that most technologists and likely many software buyers have now passed the “Peak of Inflated Expectations” around composable architecture and seem to be in the “Trough of Disillusionment” (hopefully approaching the “Slope of Enlightenment”). Members of the MACH Alliance still seem to think that they can sell the “Silver Bullet”. Let’s focus on the “Plateau of Productivity”, which means delivering on the promises of composable, which are still quite valid.

The MACH Initialism

Let’s start with the name itself: MACH, a term that implies speed. I can’t think of any way that the MACH Alliance has assisted customers in accelerating the implementation of anything, including well-reasoned buying decisions. If anything, maybe MACH suggests that it accelerates sales for their members?

Microservices: This is just an implementation pattern. Who cares whether an application uses microservices internally, especially considering the downsides of this approach? In composable solutions, applications function as black boxes. The internals should be irrelevant to the user; what’s important is that they expose services at the granularity required to implement custom solutions and to allow scaling of significant functional components. If an application meets those objectives, how does its internal architecture matter to the buyer? In fact, exposing low-level services may just add complexity and may actually harm performance. If the application is stable, does what I need, and performs well, I shouldn’t have to care whether it’s written in Ruby on Rails, Tcl/Tk, COBOL, or even assembly, right? At least, that’s what composable vendors promote. To be honest, I certainly would care about the underlying technologies for reasons outlined below. Implementation patterns are less relevant unless I need to take ownership of the code, and I would never want to maintain a microservice architecture, especially within an organization that does not sell that product.

API-First: Again, how is this relevant? What is important is that the application exposes the services that I need and allows scaling of those individual services. I question whether this is actually possible with many, or possibly any, of the microservices underlying products from members of the MACH Alliance, who, by the way, do not all follow microservice architecture.

Cloud: While this is relevant, anything can run in the “cloud”, which can include PaaS and even IaaS. The real focus is on SaaS, but even this may not be the optimal limitation. Organizations use composable components to build critical solutions. If one of those vendors fails, how is it to the customer’s advantage that their application is limited to SaaS? For me, it would be critical to have access to the source code in case of vendor failure, plus the ability to run that software in a private cloud. I realize that this objective may not be realistic but consider this statement from ChatGPT in the context of almost every SaaS vendor having entered the market only recently: “Many software startups face high failure rates. Research shows that around 90% of startups fail, with 21.5% failing in the first year, 30% in the second year, 50% by the fifth year, and 70% by the tenth year.” You probably want a non-SaaS fallback option. Additionally, some major verticals and even point applications across all verticals cannot use SaaS for legal, compliance, risk management, and other reasons.

Headless: This is probably the most nonsensical letter in the MACH initialism. If an application exposes services, other than the fact that I might be paying for the head technology, which may set internal feature expectations, or I cannot get expected value without using specific head technology, how does it matter whether an application provides tools for implementing front-end solutions if I don’t use those features? Currently, there seems to be a backlash against headless technologies and composable architecture in general, which often increases complexity and potential failure points without achieving expected value such as reducing vendor lock-in due to tight coupling between components of the solution. There really is no reasonable way to avoid implementing monolithic solutions; the issue is how to abstract the coupling to allow adding, removing, and replacing the underlying applications. Market demand and the challenges of implementing composable solutions is forcing headless CMS vendors to provide head technologies to simplify implementation. Will the MACH Alliance eject these vendors? I think not.

While they are relevant considerations, these are clearly the wrong factors by which to evaluate composable applications.

Membership

Another issue is who gets to be a member of the MACH Alliance. Any technologist knows that professional analysts often have no idea about the reality of implementing and using the products that they supposedly evaluate. How can an even smaller organization run by vendor members have greater objectivity, especially when the organization is funded by those vendors that it contains? How deep of a technical review does the MACH Alliance perform on each vendor, and at what repetition period? Is there no potential for bias in member selection? As a technologist, I don’t even want to consider these issues, let alone read marketing statements countering my implicit bias against such an alliance regarding these topics.

Missed Opportunity

Initially, when I thought that it would have some technical value, I had high hopes for the MACH Alliance. There is still a chance, but given current direction, it appears that the MACH Alliance will never capitalize on certain opportunities to operate in the best interests of the customer, such as by providing guidance in vendor selection and implementation, and especially defining interoperability standards based on domain-driven design, even for least common denominator functionality in what are essentially commodity applications.

While the MACH Alliance seems to present its members as knowledge leaders, with a few exceptions that often disagree privately or even publicly with various tenets of the MACH Alliance, I do not find much knowledge leadership coming from the MACH Alliance. What I find is a lot of marketing materials that have no value and may even be misleading. Why am I unable to find any content about best practices in composable implementations?

There is still a chance for the MACH Alliance, which has no real competitors, to capitalize on these opportunities. Otherwise, it risks fading into irrelevance, which is where it already sits for me.

MACH Alliance Member Feedback

Let’s be honest: the MACH Alliance is an exclusive, pay-to-play marketing club. We all know the downsides of such a structure – it cannot possibly operate in the customer’s best interests. In fact, I would suspect any vendor that focusses highly on its membership. If you’re investing in the MACH Alliance, whatever time and money you allocate towards this marketing effort actually detracts from your investment in useful technology.

I constantly solicit opinions from everyone in the digital marketing industry with whom I interact. While these individuals may not express their opinions publicly, whether in executive, managerial, sales, marketing, implementation, or other roles, the feedback about the MACH Alliance is largely the same: the MACH Alliance has little or no value, especially for implementation. And yet, every vendor works to join the MACH Alliance for fear of exclusion from this club, of not having the logo on their site, of not being able to check the “MACH” checkbox on RFPs.

In fact, some of the feedback that I receive is quite negative. One vendor that had recently joined the alliance expressed that they felt that they had just contributed their membership dues to the marketing budget of one of the founding members of the MACH Alliance.

Internals

I wrote that I would get to this, but now I realize that it’s not actually specific to the MACH Alliance. While we might want to believe that the internals of an application are irrelevant, they can be important.

When working with a vendor, for example to obtain technical support for a solution, it helps if all parties speak the same language, whether JavaScript, C#, or otherwise. And nobody today should be implementing anything based on legacy technologies.

In any software product including SaaS, in addition to the application itself, every underlying product from another vendor, every library from npm or elsewhere, any custom code, and any other dependency introduces a risk factor and potential failure point.

Additionally, if an organization must take over software provided by a failed vendor, that organization will need the relevant skillsets to maintain and administer those products in their internal development environments and private cloud.

For these and other reasons, the internals of SaaS applications can be quite relevant to buyers.

Conclusion

Obviously, I could go on and on. Of course, there is some value in the MACH Alliance and MACH architecture (if such a thing even exists), but it always pays for software engineers to be skeptical of anything that even touches on marketing.

• https://www.dhirubhai.net/posts/kellygoetsch_death-in-the-afternoon-cocktail-how-the-activity-7193217986407665665-uRij (relevant perspectives from Brian Walker that partially inspired this article)
• https://deliverystack.net/2024/05/06/what-makes-composable-projects-successful/
• https://deliverystack.net/2024/04/27/best-practices-in-composable-enterprise-solution-implementation/