Inside the MACH Debate Complexity AI and Composable Reality

The Gist

Composability is evolving. API-first and headless principles are becoming standard, but the practitioner experience still lags behind in simplicity and integration.
AI has yet to transform DXPs. While AI thrives in customer support use cases, its impact on digital experience platforms remains in early stages — but major changes are coming.
Complexity is just hidden better. AI and composable architecture may simplify user interfaces, but they rely on deep, structured back-end systems to function effectively.

In this episode of CMSWire TV’s Digital Experience Show, I welcome tech analyst and MACH Alliance advisor Mark Demeny for a frank discussion on the realities of composability and AI’s slow maturation in digital experience platforms.

Demeny offers insight into MACH’s core principles, where the market stands now and why the industry still struggles with structured content. From the rise of open ecosystems to the AI-driven future of campaign management, it’s a lively conversation — cheese-stuffed crust analogies and all.

Mark Demeny on the Composable DX Debate and MACH Architecture

Dom Nicastro, CMSWire: Hey everybody, Dom Nicastro, editor in chief of CMSWire, back for another edition of the Digital Experience Show, part of our CMSWire TV series. I'm here today with a CMSWire contributor—that’s the most important title for this guy—but it’s Mark Demeny, tech analyst for the MACH Alliance and a consultant and advisor to many a SaaS company. Kind of like, I should basically just announce you as a CMS DX legend. What’s going on, Mark?

Mark Demeny: Legend’s a big word. I haven’t put out enough books to qualify for that. I think Dean Barker and a few others have. But yeah.

Dom Nicastro, CMSWire: Deane Barker—yep, very vocal out there on LinkedIn. We know where he stands with his Oreo cookies now—we posted that recently. Some great fodder out there. And we’re going to talk a little bit about some fodder in the MACH world. A recent post sparked a lot of debate, a lot of questions, and some healthy ideas going forward for how we shape the DX software landscape and how we use these tools. Are we using too many? What architecture is supporting this?

It’s great to get your thoughts on that, where the MACH Alliance is coming from, and your experience—what you’ve seen. So first, let’s just level-set with what I feel might be at the center of this conversation and was the center of that post I’m referring to. That post was from March, and it was by Mariano Gomide de Faria—hopefully I pronounced that right. He’s the co-CEO of a composable commerce platform company called VTEX. He made a lot of arguments that go kind of against what the MACH Alliance says and promotes. He was a member; now he’s not.

Bottom line—it brought up some great ideas and debate from both sides. So I’m happy to get into that. But Mark, before we go deeper, let’s level-set for our audience. What are we talking about when it comes to monolith-style architecture and platform approach versus that best-of-breed composable approach? In simple terms, what’s that side and what’s that side?

Mark Demeny: Yeah, and I think the first thing we want to say right off the bat is there’s no one right approach for everything. And I think that’s one of the big misunderstandings. Obviously, we’re advocating for a composable approach. In contrast, a composable approach essentially means all of the individual components that you would want are either coming from multiple vendors or from a single vendor where certain capabilities can be turned on and off.

The typical example is commerce, where you'll have product functions, pricing functions, a customer repository, an order repository, and all these sorts of things. In some cases, it makes sense to pull in other vendors. So if you're talking about a product, maybe that’s coming from a product information management system. Maybe certain elements are coming from a digital asset management system. And so the idea is that in a composable approach, you can choose these things from multiple vendors. If you're getting some of those capabilities from a vendor that you want to swap out, you can do that easily.

The flip side of that is a monolith, where all of that capability is coming from a single vendor. And in some cases, a monolith makes sense. There's a reason why Shopify is very popular. There’s a reason why WordPress is very popular—you get most of the capabilities that you need for 80% of your use cases out of the box. I think where composable approaches make sense is in a few different cases. The two that come to mind for me are: one, you're building a differentiated customer experience or need to adapt quickly, and two, you're working in an environment with a lot of distributed systems or legacy data environments.

If you’re putting something on top of SAP for ERP, and you have a monolith that doesn’t connect to that out of the box, you’re going to have to do a lot of integration work. In a composable approach, that’s often easier because we’re built on an API-first foundation, and the principles there are around openness. So in theory, that integration becomes easier. Those are the two big use cases that come to mind. But that said, if you don’t need those things and one vendor provides everything you need—and their roadmap is aligned to yours—then go for that. Do that.

Dom Nicastro, CMSWire: Yeah, yeah. I think it’s 100% on the organization to make this work—the people that are using the tools. Now the vendor has some culpability, obviously. If there’s not good support, there’s not good support. But reading through the comments from this LinkedIn post I keep referring to, I think a lot of it’s on the practitioners—how they select their tools. Did they have a good, solid implementation game plan? Were they ready, and all those buzzwords.

And let’s dial back one more thing, too, about the MACH Alliance and what it actually stands for. You and I just talk MACH, MACH. Actually, you might be confused because of my Boston accent—you don’t know if I’m saying your name or the alliance name. But we’re talking about M-A-C-H. That MACH is what we’re talking about. What does that stand for and what was the initial concept—why did this organization, the MACH Alliance, get rolled out?

Mark Demeny: So yeah, going through the acronym—MACH stands for Microservices, API-first, Cloud-native, and Headless. Going one level deeper into that: microservices essentially goes back to what we were talking about earlier for composability. It’s this idea that each of those distinct functions within a product should be able to be consumed or swapped out. Over time, that definition has changed a little bit. Some people call that modularity. More people are focusing on the ability to swap things out easily or the ability to choose whether to license elements or not.

Really, this came from those commerce use cases where it’s common to say, “I don’t like the commerce vendor’s pricing engine—I want to put in my own because I have some additional promotional needs or regional needs.” So that modularity was the key to that larger microservices point. That’s where that’s coming from. API-first basically means everything that you’re building.

Understanding the MACH Architecture Acronym

Mark Demeny: You're going to start from the foundation of building the APIs and what it’s doing. And the purpose of that for composability is there's kind of three levels to that. Headless is one of them — and that’s an acronym unto itself. But the idea is that, for the application, you can read the content out so you can deliver content.

Managing, Delivering and Scaling Content

Mark Demeny: Then there’s this next level — you can manage the content. You can update it, edit it, again through APIs. And then there’s this third level of composability, which is: I’m not just delivering content or managing content, I’m managing the application. And that’s actually really one of the keys for MACH — you want to be able to manage all of these applications at scale.

If you're a large organization, you want to be able to spin up new commerce instances that are already connected to the PIM, already connected to your personalization engine or pricing or whatever. If you can do that at scale, there’s a lot of efficiency to be gained. That also applies to system integrators. The more they do this and build these patterns, the more it becomes replicable at scale. And that’s really important as well.

Cloud Native as a Key Principle

Mark Demeny: That kind of leads into the next part of the acronym, which is the “C” — cloud. What we mean by that is usually multi-tenant, cloud-native. You want to be able to spin these things up easily, do that through APIs, and have the vendor managing upgrades, security, and all that.

This also typically means you're able to procure and understand things more easily. You can go to a website, look at documentation, get a trial account. There’s a lot that makes your life easier as an implementer that comes along with a SaaS solution.

Now, again, for on-prem, there are use cases — regulatory reasons, etc. — so we're not saying everything has to be this way. But for most people implementing commercial software, this approach makes a lot more sense.

Headless and API-First

Mark Demeny: The last piece is headless. It's a little redundant to “API-first,” because API-first is a development methodology — you start from that to make sure all functionality is accessible through APIs. But along with that, headless lets you access the underlying data through APIs.

All of this came in contrast to applications from a few years ago. The MACH Alliance is a few years old now, and at the time, not everything was cloud, not everything was headless. A lot of data and models were locked into vendors. That’s where some of today’s tension and discussion about MACH is coming from — because many of these principles are now table stakes. But five years ago, they really weren’t. It’s been interesting to watch the trend evolve.

The Role of the MACH Alliance

Dom Nicastro: Yeah, and one commenter actually said in that post from the CEO that “table stakes” was a compliment — because this kind of thinking has become part of the culture, embedded into how many organizations approach digital architecture now.

Just to clarify where the Alliance comes from — I’m thinking it’s comparable to something like the Association for Patient Advocacy. It’s not offering services per se; it’s more like an alliance advocating for a certain approach, right? Through webinars, conferences, education, awareness. That’s the role? Or is there more to it?

Shifting from Architecture to Implementation and Education

Mark Demeny: Yeah, no, you're absolutely right. And to underscore that point — in the early days, because the Alliance was very much in contrast to existing approaches and focused on new architectures, everything we talked about was very architecture-focused. Since then, it's become much more about the principles of MACH implementation.

Some of those things relate to what vendors should do, but a lot relate to what implementers should do — how they should think about their organization, about education. More and more of what the MACH Alliance does today is exactly that: education and advocacy. We’ve built out a function called “Ride MACH.” You can log in, access free educational material, learn how to run proofs of concept, and how to think about agile processes within your organization.

Learning Opportunities

Webinar

Sep

CMS Briefing: A Live Look at What’s Next in AI-Driven Platforms

Learn how leading organizations are using AI‑driven tools to publish faster, personalize smarter and stay secure.

Webinar

Sep

Call Spoofing Trends Financial Institutions Can't Afford to Ignore

Don't let robocalls sabotage your customer relationships. Learn how to secure your voice channel.

Webinar

On demand

Ready or Not: How Data-First Organizations Are Unlocking Agentforce Potential

Learn how to cut through the noise, activate Agentforce and build a Salesforce AI strategy that actually delivers.

Watch Now

Webinar

On demand

CX Reality Check: What Your Customers Are Really Thinking

Watch Now

Webinar

On demand

Content Leaders Collective: What a Good CCMS Actually Looks Like

Discover how content leaders transform clunky systems into growth engines — and why your competitors are ahead.

Watch Now

Webinar

On demand

From Hype to High-Impact CX Strategies That Actually Scale

Turn buzzworthy AI and outsourcing trends into measurable CX wins with fresh 2025 data.

Watch Now

Webinar

Sep

CMS Briefing: A Live Look at What’s Next in AI-Driven Platforms

Learn how leading organizations are using AI‑driven tools to publish faster, personalize smarter and stay secure.

Webinar

Sep

Call Spoofing Trends Financial Institutions Can't Afford to Ignore

Don't let robocalls sabotage your customer relationships. Learn how to secure your voice channel.

Webinar

On demand

Ready or Not: How Data-First Organizations Are Unlocking Agentforce Potential

Learn how to cut through the noise, activate Agentforce and build a Salesforce AI strategy that actually delivers.

Watch Now

From Technical Purity to Practical Guidance

Mark Demeny: That shift has really been one of our organization’s big pivots. But I don’t know that everyone outside the MACH Alliance fully understands how much we’ve evolved — from architectural purity to broader, philosophical guidance. And that actually ties into the VTEX CEO’s argument. In many ways, we’re in violent agreement with him. We’re now much more focused on outcomes and supporting buyers in their journeys.

Inside Jokes and AI Transcription Fails

Dom Nicastro: Gonna pause for a second. I took a gamble and left the dog upstairs. He’s been quiet all day... and now he’s barking. This is the benefit of recording, Mark. Hang on.

Mark Demeny: No problem. We can just cut it off.

Mark Demeny: That is pretty funny. We're also noticing — as we do a lot of AI transcription — that MACH Alliance gets transcribed as “mock” with a ‘K.’ And with your Boston accent, sometimes “Mark” and “MACH” get confused. The funniest one I heard recently? Someone said “MACH Alliance” and it got transcribed as “Macallan” — like the Scotch.

The MACH Criticism Debate: Integration Chaos or Implementation Reality?

Dom Nicastro: All right, let’s get into the meat of the discussion — what happened on LinkedIn recently and what’s going to happen going forward. The post from the VTEX CEO drew almost 100 comments. One major critique was integration chaos: a complex web of APIs, data inconsistencies, skyrocketing costs, managing multiple vendors, licenses, support contracts. Operational overload. Fragmented tools. Security risks.

When I looked at those criticisms, my reaction was: welcome to the real world. Everybody deals with these things. I wasn’t sure why he was pinning this all on the MACH Alliance. That felt like inside baseball. Let’s talk about the actual issues raised and get your take.

Composable or Not, Complexity Exists

Mark Demeny: Yeah, I mean, to your point — those are things everybody has to deal with. Whether you're implementing a single vendor or a composable approach, you still have to think about security and integration complexity. So those issues exist regardless of architecture.

There are aspects that relate to what we do as an organization, aspects that relate to vendors, and aspects that relate to implementers. From our role, we try to ensure that vendors are being open and accessible. But we also provide advocacy and guidance to help people understand how to manage this complexity — because it is complex.

The Last 20%: Build vs. Buy Tradeoffs

Mark Demeny: One of the realities of the current world is that nobody likes to be told things are hard. But they are. So part of our role is to say: here’s what you need from vendors to make this easier — but here’s also what you need to understand as an implementer to make these systems work together.

For example, our interoperability task force — which I’m part of — has published white papers laying out architectural patterns to follow. The flip side? If you go with a single vendor, you may not be able to reach the last 20% of your needs. There’s an old metaphor: the vendor gets you 80% of the way across the ocean, but then says, “Now you swim the rest.” You better be a great swimmer — and that’s the build vs. buy question in a nutshell.

Composable Complexity: Acknowledging the Real-World Challenge

Mark Demeny: Perhaps some of the issue is organizations not understanding the complexity. And to your point, that complexity exists regardless of whether it’s composable or not — you just have to think these things through if you’re implementing complex solutions. So in a weird way, we’re in violent agreement with him — these are things that need to be dealt with.

I think the bigger question is whether a composable approach is the best way to deal with that complexity. Ironically, VTEX — whether they are still a member or not — implemented those same architectural principles in order to make implementation easier. So some of this backlash may come from partners or vendors misrepresenting composable as a magic bullet, which is something the MACH Alliance does not advocate.

Being Transparent About Complexity

Mark Demeny: We try to be very clear: here is the complexity, here’s what you should do organizationally and technically to manage it. I think that's the big distinction. We’re not selling oversimplified visions — we’re trying to provide realistic paths forward.

The API Challenge and Vendor Sprawl

Dom Nicastro: One of the other critiques was about managing a . If you go API-first, what are the real-world challenges? And with multiple vendors, how can DX leaders prepare for the inevitable complexity?

Mark Demeny: First off, you need to sign up for a level of complexity that makes sense. Einstein had this principle: everything should be as simple as possible — but no simpler. There’s a corollary I like: everything should be as complex as needed — but no more complex than that.

Choosing the Right Level of Composability

Mark Demeny: Even in composable, you can choose a small or large vendor footprint. If one vendor’s commerce platform also gives you good-enough personalization, order, and customer repositories — use it. You don’t need to pull in three more vendors for the sake of composability.

It’s only when you have a truly differentiated and complex need that you start expanding. And at that point, yes — integration becomes a challenge. That’s when you have to be deliberate.

Three Approaches to Integration

Mark Demeny: There are typically three approaches for managing multiple APIs and systems:

1. Frontend Binding (Not Recommended). Developers pull all data to the front end and manage it with JavaScript. This quickly becomes unmanageable and we advise against it.
2. Backend Orchestration Layer. Vendors like Conscia, Okta, and Uniform provide orchestration tools that connect APIs behind the scenes and reduce overhead.
3. Build Your Own Integration Layer. This backend-for-frontend approach gives you full control and enables things like caching, data shaping, and performance optimization.

Why Caching and Data Freshness Matter

Mark Demeny: A custom backend can cache rarely changing data (like product descriptions) while refreshing more dynamic information (like inventory or pricing) as needed. This minimizes load on underlying systems and helps frontends run faster. But again, this means you need a solid understanding of your business needs and data sources.

When Composability Makes Sense — And When It Doesn’t

Mark Demeny: If your business doesn’t deal with multiple regions, pricing tiers, inventory volatility, or specialized workflows — maybe a composable system is overkill. But if you do, it gives you granular control over the stack, and that flexibility becomes crucial.

Composable Extremism: Going Too Far?

Dom Nicastro: Mark, have you heard the term “composable extremism” lately? What does that mean to you?

Mark Demeny: I haven’t heard it directly, but I think I get the idea. You can absolutely overdo it. Some system integrators push composable without the organization fully understanding what that means. And that’s one of the big issues.

Composability Without Context

Mark Demeny: Some buyers say, “We need a headless CMS,” and the partner responds with a list — but they never discuss the pros and cons of going headless or composable. That happens a lot. People want to be seen adopting the shiny new thing.

So extremism can be two things: pushing complexity too far, or pushing composability in situations where it doesn’t make sense.

AI in DX: Real Promise or Overhyped?

Dom Nicastro, CMSWire: Yeah, it's probably a little bit of both for sure. But the thing is, Mark, we can solve all of this — all of these challenges — with artificial intelligence. Now, can't we? Because that is the silver bullet here that we haven't discussed yet.

I'd like you to kind of correct me, because I've been saying — we cover at CMSWire two very distinct, not totally distinct but related, areas. One is the contact center world — customer service and support — and the other is digital experience: DXPs, CDPs. And I’ve been saying that I’m seeing more innovation and practical outcomes with AI in the contact center arena. It’s helping with agent experience. But I’m not seeing, at least not as much, the same success stories in the DXP and digital experience world. Tell me what you're seeing.

Contact Center vs. DXP: Where AI Delivers Now

Mark Demeny: Yeah, I would agree with that. To your point, we're seeing a lot of innovation in call centers and chatbots — especially for customer support use cases. A big reason is that a lot of that data was already well structured, and the experiences they replaced weren’t great. So even with a chatbot that sometimes hallucinates, the experience can still be better.

And let’s be honest — those areas are cost centers. If AI can deliver the same or better experience *and* save money, it's an easy win. That’s why so much investment is going into that space.

Marketing AI Is a Harder Sell

Mark Demeny: We haven’t seen the same level of success with AI in content management. There are a few reasons. CMS was originally built for marketers creating landing pages — not huge datasets or knowledge bases. So the business case is harder, and value is tougher to prove.

The Struggle to Sell Structured Content

Mark Demeny: This goes back a long way. When I was at Sitecore — many years ago — we were assembling pages from discrete content elements. The pitch then was: “Update it once, use it everywhere.” That became more powerful when mobile came along. Then Headless pushed it further with multi-channel reuse. Now AI is pushing it again — but vendors still struggle to explain the value of structured content to marketers.

Marketers often just want to build a page. They ask: “Why am I bothering to break this into structured fields when I’m just publishing a landing page?” That mindset persists.

AI’s Role in Making Structured Content Valuable

Mark Demeny: Each evolution — mobile, Headless, now AI — has added value to structured content. And we’re finally starting to see that. But most current AI tools are still human-initiated. Someone asks AI to rewrite something or translate it. Those use cases are helpful, but a bit... “cute.” I love that description someone used.

AI is still assisting — not managing. The real shift will come when AI can *manage* content at scale. That’s where we’re going.

Managing Complexity with AI: The Real Opportunity

Mark Demeny: CMSs still treat every variation as a discrete object. One language, one version. A second audience? Another version. A third channel? Another copy. That’s why content operations become so unwieldy.

What we need — and what we’re starting to see — is AI that treats this not as 500 separate content items, but as a single campaign idea with variations. It manages versions for each audience (gamers, soccer moms, bankers) and in each language (maybe even Tagalog), while also addressing accessibility or channel-specific versions.

Can AI Orchestrate Campaigns Instead of Just Pages?

Mark Demeny: Instead of asking, “Where’s the French version of this landing page?” the question becomes: “How’s our summer campaign performing across channels and languages?” AI can take a campaign seed and generate all those variants, measure results, and even self-validate with another AI — like asking, “Is the Tagalog translation any good?”

That’s the transformation that’s coming. CMS won’t be about pages anymore. It’ll be about ideas, campaigns, strategies — and AI managing the execution.

AI as the Stuffed Crust Pizza of CMS?

Dom Nicastro, CMSWire: Yeah, it just seems like it's a space that's ripe for a game-changing AI implementation. It doesn't seem like it's happened quite yet, but with what you're saying — some of these innovations coming out shortly — hopefully that’ll be the case. It's like the stuffed crust pizza, Mark. You can tinker with your sauce, add some oregano or whatever, but when you put the cheese in the crust? That’s game-changing. We need that in the DXP space.

Mark Demeny: Yes, yes — that's how we'll sell it. AI is the stuffed crust pizza of CMS.

Dom Nicastro, CMSWire: Shoutout to the CEO of VTEX for kicking off this spirited debate. It’s a much-needed conversation, and I appreciate you bringing it all home. Anything else you wanted to get out into the world?

The Future of Composability

Dom Nicastro, CMSWire: One more question, Mark. It’s been a great conversation. What’s your outlook on the future of composability — where’s it headed in the rest of 2025 and beyond?

Mark Demeny: Composability is definitely here to stay. The underlying principles — headless and API-first — are being adopted across the board. Even suite vendors are breaking up their stacks for more flexibility.

At the heart of this shift are the MACH principles — being open and connected. Historically, vendors relied on lock-in. You’d input your data, use their platform, and you were stuck. But at the enterprise level, lock-in limits value. If your data isn’t portable across channels and systems, you’re boxed in.

From Data Portability to Experience Simplicity

Mark Demeny: One of the challenges now is experience complexity. We talked about the need to juggle multiple tools — your commerce system, your PIM, your CMS. The back-end may be composable, but the practitioner experience still feels fragmented. That’s where I expect more innovation.

We may see a more unified UI for practitioners — a layer that looks less composable on the surface, but remains fully composable under the hood.

AI Will Abstract Complexity, Not Eliminate It

Mark Demeny: People say AI will “hide” complexity — structured content, taxonomies, metadata — but that’s not exactly true. AI abstracts complexity. It still needs to understand context. If someone says “Woods,” are they talking about a forest? Tiger Woods? Golf clubs?

There has to be a way to store and surface that meaning. Whether that context lives in LLMs or in structured schemas, it’s essential. The easier it seems on the surface, the more complex it is underneath — and composability is what keeps all of it working together behind the scenes.

Closing Thoughts

Dom Nicastro, CMSWire: I just published content today, Mark — and I’m still having trouble figuring out the CMS we use after 10 years. It’s not easy.

Mark Demeny: Yeah, that's a whole other one-hour discussion.

Dom Nicastro, CMSWire: Mark Demeny is a CMSWire contributor and one of the most sought-after voices in this space. We appreciate you joining us on the Digital Experience Show, CMSWire TV. By the time this airs, we will have already caught up in person at the MACH Alliance Conference in Chicago — so I’ll just say it was nice seeing you there, Mark.

Mark Demeny: Yes, it was nice seeing you in Chicago as well. We'll share a deep-dish pizza — or a stuffed crust, depending on what's delicious.

Dom Nicastro, CMSWire: Yes, it was delicious. Thank you again for joining us — and stick around after the credits!