The MACH Alliance has invoked trademark protection to warn off Adobe and Salesforce among other vendors from claiming their products are 'MACH-based', it emerged at this week's MACH TWO conference in Amsterdam. The industry body was established three years ago to promote adoption of a composable approach to IT, centered on the four principles represented in its name — Microservices, API-first, Cloud-based SaaS and Headless, in contrast to the monolithic stacks of conventional enterprise applications. But it has stringent criteria for MACH compliance that many vendors do not adhere to. Speaking to media at the conference, Kelly Goetsch, chair of the Alliance and also Chief Strategy Officer of founding member Commercetools, commented:
Anybody having an API these days is claiming to be composable, which is the whole problem with these things, when you don't have a trademark and you don't have standards. We have a trademark, we have standards for enforcing the trademark. By the way, Adobe and Salesforce have both claimed to be MACH-based. So it is definitely not lost on them, what we are doing here. [And] I will go on record as challenging those claims.
Reflecting on the progress made since the MACH Alliance launched three years ago and its first annual conference last year, Goetsch said that the market has evolved past the point of needing to explain what MACH is. MACH is increasingly specified in RFPs and it's now more a case of providing guidance on how to implement it, he said. But many vendors are offering headless or API-ready options without being truly MACH, and so guidance is also needed in distinguishing the real from the fake. He elaborated:
I need someone to help me understand what's a good proper MACH architecture, and what pretends to be something that is not. I will only figure that one out when it's too late, and I'm knee-deep into something that is now not to be changed, or very hard to change.
Over half of applications are rejected
Therefore one of the key roles of the MACH Alliance — an industry body set up and largely funded by a cross-section of vendors and tech consultancies mostly drawn from the composable commerce and content sectors — is to certify vendors and their technology offerings as MACH compliant. He added:
We have a trademark on MACH and MACH Certified and we have been enforcing that trademark. Because we've seen what happens with things like cloud. When cloud became a thing, everybody started using the term to the point where there's a term created for that, which is called cloudwashing ...
We're the only industry body to get together to keep the term pure and actually meaning something and we're quite proud of that. And it's caused a lot of problems, a lot. But it has been well worth it. The easy thing to do is give in and just make it, anybody wants to join can join and let's all hold hands and everything's fine. But there is MACH and there is not MACH and we are very properly enforcing that.
Over half of applications for MACH certification are rejected, revealed Casper Rasmussen, President of the MACH Alliance and also Group SVP of Technology at tech consultancy and founding member Valtech. Many of the 53% who fail then reapply a second or third time. The organization works with applicants to help them understand the requirements and what they need to do to be accepted, he added. While membership is growing, it won't dilute its standards for the sake of expansion, but it does plan to make its criteria more transparent. He said:
As long as we maintain quality over quantity, there will be no dilution of the mark. And transparency plays a big role ... As long as there is complete visibility and transparency into what it is and what it's not, then I don't believe there will be any dilution or any questions.
Until that transparency is established, there will inevitably be some back-and-forth with applicants and even internally. Goetsch revealed that there are often intense internal discussions whether an applicant truly fulfils the MACH requirements. Coming to a final decision sometimes "requires a lot of background checks," he added.
Soft factors beyond the technology
Some of the lack of clarity around the requirements comes down to additional learnings as the organization expands its reach into new product categories and industry sectors. But it's also because compliance goes beyond the core technology factors into other aspects of how a vendor approaches implementations. For example, Jasmin Guthmann, Vice-President of the MACH Alliance and CMO of founding member Contentstack, said that being committed to interconnection with other vendors is a key attribute. She explained:
If you are only concerned about yourself — and that is so hard to measure to the criteria of that conversation that we had before, which is why we're having some intense debate on some of the candidates in the pipeline right now — if you're unwilling to be open, and to be an integrated part of this ecosystem, this is not the right ecosystem for you. But we need to find a way to make that very transparent. And that is very hard.
Other soft issues that are taken into consideration are the ease of trying out the solution as a prospective customer, or how the vendor handles procurement and customer support, which in a composable environment often means partnering with an ecosystem rather than going it alone. Guthmann explains:
We're trying to find a way to make it easier to buy five things and have them coexist and connecting. Not just that, but you don't want to be passed around from one vendor to the other if you're the customer ...
If you want to be a member, that needs to be a 'no', if you're not willing to be part of a collective approach to solving customers' problems.
Asked about customers wanting to operate a hybrid environment, Goetsch did concede that it's better to move towards composability, even if full MACH compliance isn't possible. But he warned that true composability depends on microservices that are built with that environment in mind. He said:
APIs are better than no APIs. But there's a fundamental difference when you start with an API and then you write code behind the scenes as a microservice, because then each API is independently consumable. It was built from the ground up to be consumable by developers.
When you add APIs to something that is pre-built, inevitably, you can't capture all the data and functionality. Inevitably, the APIs reflect the underlying code structure, which may or may not be the easiest to call. So it's always best to start with APIs to design, then do the coding behind the scenes as microservices. But again, I'm a pragmatic guy, I would take a monolith with APIs as a good stepping stone.
Having witnessed many years of cloudwashing and a phenomenon that I termed SoSaaS — Same old Software, as a Service — I can only laud the uncompromising approach taken by the MACH Alliance and the firm stance they have taken to prevent incumbent vendors such as Adobe and Salesforce from muddying the waters about true composability. But at the same time, I think the organization needs to do a better job of defining its criteria and making them transparent, so it's good to know it aims to move in that direction. Meanwhile, I have a few thoughts of my own on clarifying the definition, which I'll come to in a later piece in this series of reports from MACH TWO.