What comes after MACH & Composable?

Since the beginning of 2019, I’ve been contemplating where the commerce industry will be in a few years’ time as the challenges that all headless/MACH/composable [insert your favorite trend/buzzword here] vendors encounter are collectively addressed and solved for.?

What will we call this new wave of innovation based on what we know today and where the industry is headed??

This goes all the way back to the post I wrote in early 2020 "Headless Commerce - Cracking the Conundrum".

Below you will find a diagram that highlights the terminology evolution over the past decade. Let’s quickly recap these (skip the next couple of sections if you’re familiar).?

It’s also worth exploring some of the tenets and trends that vendors are working to align themselves with, along with explaining some of the issues they are trying to solve? as the ecommerce ecosystem matures.

What is MACH?

MACH is a set of architectural technology principles coined by commercetools that stands for Microservices, API-first, Cloud-native SaaS and Headless.?

This acronym achieved widespread appeal within the commerce vendor market (here’s a short summary on what MACH architecture is for those that are not familiar).

The important thing to note with MACH is the close association with the @MACH Alliance and the relatively high barrier to entry for vendors and customers alike. The requirements to join the MACH Alliance today firmly set MACH into the Enterprise end of the market.?

The MACH Alliance homepage itself highlights this Enterprise focus as a counter to legacy solutions: “Enterprise suites are no longer the safer choice. The MACH ecosystem is,”??

The requirements to be a part of the MACH alliance,as well as the policing and enforcement of these requirements, helps to eliminate potential confusion in the marketplace. It actually means something to become a MACH-certified member. The MACH Alliance is like the Apple App Store: a walled garden that ensures high-quality members meet the requirements, helping to establish trust with retailers and brands.

What about “Composable Commerce”?

Composable is an evolution of the MACH terminology and moves away from a technical acronym to a term that bridges the gap between technical and non-technical stakeholders. It is a relatively new term taking hold of the market that is more easily understood by business decision-makers. You can check out my summary of Composable Commerce on the Amplience blog.?

The problem with this term is that packaged business capabilities remove the “size-ism” of microservices, leaving room for legacy vendors to claim that they are composable so long as they’ve slapped some APIs onto their now Frankenstein-like product.?

Like ‘cloud-washing’, ‘headless-washing’ and ‘MACH-washing’ that has come before, ‘composable-washing’ from legacy vendors in the market is now prevalent as it gives these companies an easy marketing-led way out. This problem was highlighted recently by Sana Remekie via a handy mindmap. This doesn't help an already confused market!

Composable commerce as we know it today is really close to the future state I’ve been envisioning since 2019, but it doesn’t address some of the key barriers to entry for broad market adoption. We’ll get onto some of these in a moment – the final pieces of the puzzle!

The challenges of MACH

To understand what that future state should be, we must first look at the challenges MACH vendors face today.

• Complex sales processes. Handling multiple vendor relationships and pricing conversations makes the overall Total Cost of Ownership difficult to determine quickly and accurately. There is significant friction and overhead when it comes to engaging with and buying MACH vendor software.
• Saturation of Enterprise accounts. As MACH takes hold within the Enterprise sphere, where will vendors generate new business and drive growth? For that, Enterprise vendors will have to look down market to the already frothy and highly competitive mid-market, which presents its own unique set of challenges and problems. We’re already beginning to see this shift towards the mid-market with commercetools' recent acquisition of Frontastic. I predict we’ll see further consolidation in the coming months and the next few years.
• Higher technical barrier to entry. MACH requires development teams to execute and implement integrations, experiences, and whole solutions from multiple vendor products and services.

This all begs the question – can MACH mature and lower the barriers to entry for the benefit of all, no matter what your organisation's size, technical competency or technology budget? How can MACH and composable architectures fully cross the chasm to mainstream adoption in all verticals??

The answer, of course, is yes – technology is always in a race to the bottom and innovation is commoditized over time. We can already see that with some of what composability has outlined, but I’d argue that it does not go far enough.

From a technology and implementation standpoint, the composable approach is maturing with the growth of marketplaces and increasing numbers of integrations, patterns, and accelerators between vendors. This is fantastic, as it drives down implementation complexity, time, and cost.?

Composable is heading in the right direction from an architectural perspective, but what about the issues highlighted above that sit outside of the pure technology sphere? How do we cross the chasm as an industry and attain mainstream adoption?

These challenges are no secret. The MACH Alliance is working to address this through standardization which is one way to go with a smaller community of vendors, but it will certainly be challenging to align every vendor and business model entirely. You can get an overview of this 6-point plan here.

Another way of looking at this is that a much broader approach is needed (from vendors inside and outside the MACH Alliance independently).?

To cross the chasm we have to shift from talking technology and build a better bridge that communicates and delivers business value. Friction and risk has to be removed at every stage of the transformation journey.

Credit: to Karim Harbott for this annotated version above.

The bridge

Open?

To succeed in the mid-market an open approach is essential – Magento got this right a decade ago with their open ecosystem approach. Let’s expand on defining what “open-ness” is as a business strategy.

Decentralized - At this point, there should be no denying that commerce capabilities are commodities; businesses can choose to rent these commodities from any vendor and integrate it into their stack. The commerce platform core has diminished significantly.?

The value these platforms now provide lies in the interoperability between major "chunks" of functionality (orders, customers, products) and the technical and commercial simplicity of being able to procure those from the same vendor. The same can be said of CMS & DXP platforms (content, assets, search, personalisation).

The commerce and content platforms as we know it have been replaced with commerce and experience frameworks or engines, with a myriad of options and choices to make along the way. Commercetools is the first commerce vendor to drop the term “platform”, and it might just be the first of many when everyone else catches on! It's important to note that these frameworks and engines naturally occur within the market and coalesce across multiple vendor solutions – we're seeing this as composability matures through point-to-point vendor integrations.

Transparent - Whilst a concierge-like experience in the enterprise end of the market is somewhat expected, it makes little sense for both retailers, brands and vendors to spend the time, energy and resources engaging in this approach for every last component - it’s simply not worth the vendor’s or customer’s time when the price points do not warrant face-to-face conversations. Being upfront around pricing is essential, and better yet, having a pricing model that is easy to understand and scales with a business is essential to remove friction from the buying process. Being transparent here also helps build trust on all sides.?

The best way to tackle the TCO problem is to deal with it upfront – that’s why Matt and I put together a TCO guide & template to help businesses looking to go MACH get their project costs written down in one document. It would be much easier if every vendor’s pricing was transparent, but that utopia is likely impossible to achieve in reality.

Self-service -?SMBs typically do not engage with lengthy enterprise buying processes and it is not economically viable for vendors. Buying processes at this end of the market are also entirely different, often led by end-users and developers who simply want to test how a solution works and get it up and running fast. Gated trials, limited-time-based trials, or inaccessible products simply won’t cut it for this size of customer. It’s also an approach that is beginning to eat its way into how larger enterprises buy solutions, too. The way customers buy software has fundamentally changed over the past decade. For customers to really move fast, vendors need to get out of their way and eliminate friction at every stage of the evaluation and buying process.?

Altruistic -?Embracing flexibility as a conscious choice for the benefit of the end customer, leading to an ecosystem-centric and open approach. This is not to say that businesses must be entirely altruistic; more that their goals and the path to get there align directly with customer needs. There is a fine line that platforms tread as they grow and they can sometimes lose sight of “a rising tide raises all boats” and begin to compete with their own ecosystem. This should be avoided at all costs or you risk alienating the ecosystem that got you to where you were in the first place and they’ll simply divest and take their business to greener pastures! I wrote about this dichotomy a little while ago here. To put it another way, vendors should be cool with selling their whole solution, or swapping parts of their solution out for other components – they need to put the customer-first and work in their best interests.

Many of the elements I have outlined in this section align with a Product-Led Growth (PLG) strategy – you can find out more about PLG here. PLG aims to eliminate friction in your evaluation and buying process through your product. This is really hard to do well.

Open vs Open Source - BigCommerce wrote extensively about their own definition of “Open SaaS” in 2021 and you can grab their Open SaaS ebook here. Their Open-SaaS concept married SaaS and open-source concepts.?

Open encompasses open-source philosophies but also acknowledges that SaaS vendors typically have relatively closed cores that are extendable in specific ways to ensure that flexibility and speed can be maintained.

Low-code

MACH and composability are fantastic for their flexibility and turn-key SaaS solutions are great for their implementation speed. What if you could have the best of both worlds? How do you achieve that turn-key speed whilst still maintaining the ability to pop out into an IDE and write some custom code for your exact requirements when the SaaS UI reaches its limits? How do you do that in a way that doesn’t put control squarely in the hands of developers but ensures a business' needs are met – i.e. my business users can go in and make use of this custom code or solution?

You need a way to oscillate between these different modes depending on the situation and there is no term today that really nails or describes this well. The closest we have is “Low-code” but this can have different meanings and is generally poorly understood. Some of the confusion is captured in the comments on my post here on the topic. For some, low-code simply means writing a little less code, whereas for others it means a business user is able to drag and drop some simple logic in a UI together.

Agile

This is, of course, a nod to the Agile CMS but Agile, Agile methodology, and best practices can be applied more broadly across organizations, architecture, vendor solutions and best practices employed. How businesses can leverage some Agile best practices are touched on in the “Agile Teams and Workflows” whitepaper – huge shout out to Mike Badamo for his great insights and contributions in this piece.

Developing feature capabilities and supporting new architectures is not enough. Vendors must fully support the business & digital transformation required to realize the full growth potential of these new solutions. To do that, they have to become truly customer-centric, fully understanding customer pains and delivering by rapidly improving product, people and process.

Headless

Embracing modern best practices, with a nod to Headless, Jamstack, MACH, and Composable as terms. After all, this is an evolutionary process and not some radical departure at this point.?

With that said, API-first and Cloud-native should be assumed and a pure Microservices-based architecture is perhaps a more theoretical and/or technical point. Whilst linked to business value, that is not always the case, hence the rise of composability and packaged business capabilities that have since blurred the waters! What they do share in common, however, is a headless approach.?

Headless is the consistent thread and is fast becoming the de facto way in which modern experiences are built and delivered for all organizations today, whether you are aware of it or not!?

This Headless thread that permeates through MACH and composability terminology is probably why there is so much confusion in the market as there are different interpretations to the extent of what headless actually means – is it just replacing your frontend, or is it some much larger backend and frontend replacement? When the market talks headless, they could mean either.

The mainstream market is risk-averse and looks for incremental business value; they’re replacing their frontends but not really changing the way their teams are structured or how they fundamentally operate today. On the other end of the spectrum, we have visionary retailers and brands undertaking much larger digital transformation projects that fully embrace change and MACH principles. This is not only from an architectural approach by dividing up multiple vertical slices of functionality, but also a mirroring in how their teams are structured. This type of transformation requires a fundamental shift in their day-to-day operating model. This topic needs a dedicated post to explore in more detail. The agile teams and workflows whitepaper mentioned above would be a good starting point in any case.

Introducing HALO

As I mentioned above, technology is a race to the bottom, meaning the tools, solutions, and benefits that enterprises enjoy will become available to the wider market over time. Barriers to entry and costs are certain to fall. You may also notice the heading descriptive traits.

I’d like to propose that HALO is the label that we can ascribe to the next wave of solutions that are at various stages of maturity in the market today. These solutions just don’t have a cohesive term or label to call home that can span technologist and business stakeholders in the SMB market and help distinguish them quickly from their peers. How does a customer know how easy it is to buy and work with you without looking at your pricing page and engaging with your team and experiencing it for themselves?

In combination with MACH & Composable, HALO is the final puzzle piece to completing the bridge to greater adoption beyond the enterprise space.

HALO stands for:

Headless – A nod to the best practices that came before and the evolutionary – potentially symbiotic – approach to MACH & Composable.

Agile – Proactively taking Agile methodologies, architecture, and best practices onboard to deliver business value

Low-code – Resolving the development bottlenecks and barriers to entry of MACH/Composable by putting business users in control. This is paired with providing an effective "escape hatch" to the IDE where there are simple patterns to create UI extensions, integrations and custom business logic when you inevitably reach the limitations of the vendors you have implemented. This approach ensures you the freedom and flexibility to rapidly meet business needs without coding everything from scratch.

Open – Resolving the pricing and packaging issues and becoming community/ecosystem centric, self-service, and decentralized – no platform or quasi-platforms here!

A word on HALO analogies

For acronyms and labels to really take off, they have to be catchy and emotive. Marketing and messaging teams can probably have a lot of fun with this.

Where MACH aligned well with the analogy to speed, HALO aligns well with the symbolism of reaching that holy grail of speed, features, and flexibility that I referenced way back in my “Headless commerce: cracking the conundrum” (towards the end of the article). Looking back, I would add evaluation and purchase time to sit alongside implementation and iteration within the speed dimension. Agility would also sit somewhere between features and speed. What good are a bunch of features if you can’t use them quickly and effectively?

We likely don’t need an architecture diagram for HALO as it’s largely not grounded in technology principles, but rather business strategies and value. But if you were to draw one – pictures speak a thousand words after all – it would most likely be by placing the vendor solutions in a ring around either the customer experience or by placing the experience and commerce orchestration at the very center that holds everything together.

HALO and the ring of FIRE

I do love a good analogy after all… HALO is not an entirely new set of concepts, but builds on similar themes from commercetools MACH and Gartner’s Composable Commerce terminology (Mike Lowndes,?Sandy Shen). HALO also builds on FIRE, written by Emily over at Forrester. If you’re not familiar with FIRE you can check out Emily’s blog post “The Future Of Commerce Technology Is On FIRE — And It’s A Good Thing”, it’s well worth a read!

Where do we go from here?

I think it’s fair to say that this piece might not present any radically new ideas or concepts; perhaps it’s even just a rehashing of Emily’s post or PLG mentioned above. In any case, my intention is to draw the industry's focus towards solving what it will take to cross the chasm and reach mainstream adoption. Many MACH vendors, such as Algolia, already embrace MACH, Composable and HALO principles with great success. They’re supercharging their growth and that of their broad customer base.?

Forgive the perhaps clickbaity title as MACH, Composable, and HALO actually coexist. They are not mutually exclusive but help describe different ways in which vendors solve retailer and brand pains. To continue the bridge analogy, they are all planks that help get us to that future state.

Some other vendors that I think exhibit HALO principles today include Uniform, GraphCMS (check out Build Your DXP), Swell and Snipcart. What other vendors do you think fit the HALO profile? I can certainly see this list growing over time.

Maybe HALO will take off and this post resonates with the industry, and in doing so it becomes a badge vendors can display with pride to demonstrate just how customer-centric and easy to work with they really are.?

On the other hand, maybe it won’t – having another acronym might be simply too much for the market to bear. Regardless, the principles outlined above are already a big part of several vendors’ go-to-market strategies and will play a huge role in reaching mainstream adoption.

The thoughts and opinions expressed in this article are my own and may not reflect that of Amplience or the MACH Alliance. With that said we, Amplience, are already building towards many of the concepts outlined in this article - stay tuned! It certainly still feels like the industry as a whole is just getting warmed up for the disruption that is in motion.

P.S. This article has been sitting as a draft Google doc for over two years, just ask Rory Dennis or Thom Armstrong. ?? It's been bugging me sitting there so I thought it made sense to tidy it up and publish it; the timing for this article just feels.. better!