The great DXP vs. DXC debate
Darren Guarnaccia
CPO & CMO | B2B SaaS President | Product Strategy, Management and Marketing | Analyst Relations | Alliances & Ecosystem Development
Understanding the outcomes and differences between legacy DXP and emerging DXC
Recently I’ve noticed a bit of a debate from some of the legacy Digital Experience Platform (DXP) vendors pushing back on the emerging Digital Experience Composition (DXC) category.? The argument that is made is that we don’t need this new category, and we should just stick with DXP. One could dismiss this pushback as just protectionism for those well established in the older category, and looking for ways to block upstarts and new emerging technologies but there’s a point to be made here. As I like to stay, people don’t buy products (or technology), they buy outcomes. So what are the outcomes of DXC, and why are they different from DXP? Let’s unpack that, shall we?
The evolution of the DXP market
Let’s start with why any market disruption happens with Clayton Christensen’s famous disruption chart:?
The DXP market has become bloated over time, adding more and more functionality in the name of sustaining innovation. These systems were largely born in the pre-SaaS era, and have a heritage of on-premise technology, tightly coupled technology and proprietary development requirements. Over time, these things have frustrated users and developers alike. Updates from one version to the next were expensive, the technology was hard to maintain and scale and developers chafed at the limitations and lack of flexibility to take advantage of newer technologies.?
领英推荐
Along came new cloud native, SaaS technologies that were built to be consumption based, and built around APIs and microservices. This new class of technology is often referred to as composable technology because it allowed you to assemble just the pieces you wanted, and could compose your solution to suit your needs. These technologies were much easier to scale, maintain, and give developers the freedom and flexibility they craved. But, like many disruptive technologies, it wasn’t as feature complete as the category they were replacing, and in this case, the tooling and workflows for the business and marketing users of these systems were missing or not nearly as strong. This is where the DXC category fills this important gap.?
The emergence of DXC as a category
DXC, as defined by Gartner, brings together 3 things that are missing in pure composable approaches: API orchestration (to make it easier to integrate all your tools similar to how you did it in DXP), No-code experience assembly (to make it easy for marketers to build experiences like they could in DXP) and front end as a service (to give developers flexibility to choose the development frameworks they want to use, and to make delivering these experiences fast around the world and solve the DXP scalability problem).?
Outcomes of the DXC disruption
These are clearly problems brands need help with, and this is distinctly different from what legacy DXP couldn’t and wouldn’t solve: some of this motivated by technology constraints, and some by business model needs (e.g. vendor lock-in.) The outcome of DXC disruption is improved speed (both in terms of page performance and team output velocity.) Brands need to move faster and faster to keep up with their customers. Legacy DXPs get slower and slower over time, and without DXC, so does composable technology when it gets glue-coded together. In my mind, that’s why we need this new category. DXC is solving an inherently different set of problems, and to conflate this with DXP would muddy the waters for brands. That’s my opinion at least. What do you think?? What’s your take on DXP vs DXC categories for modern digital experience architectures??
MACH-Driven Architect | TOGAF 10 Certified | Commerce Specialist | Enabling Agile, Future-Ready Solutions
2 年In my opinion , term DXC is more to headless and more to DXP you can define it as a spinal cord without head , legs, hands , stomach etc. Spinal Cord - is API orchestration layer , where you will attach different composable. Surgeon - is Vendor or Experts that will fix the faulty, high cost or obsolete composable with new one So building a spinal cord is the main task here, as you can bring best breed of existing tech or platform but currently spinal cord need to be build or enhance or need to be used from few vendors like VUE and few other have it. So what I will say both are not different but I will say DXC is way or concept to build DXP that is more flexible and composable then earlier. Let me know your opinion on this.
Enterprise Architect
2 年Darren Guarnaccia , my interim view (gut feel) is that DXC is for experimentation. In contrast, custom code is for building unique digital products. The characteristics for what experiments should behave like have changed. They now demand more headlessness, composition, personalisation etc. They operate in a world of certain user experience expectations. There has been an evolution from writing custom code for experiments to (with constraints applied) enabling experimentation through a tool. Sure you could use DXC to build and scale a website or app that does something valuable/captures value. WCMs did that as well before DXPs came along. The old “just because you can, doesn’t mean that you should” argument applies. At the moment, I don’t think we should see this as anything more than a case-specific solution with clear limitations of use even if those limitations are on the ragged edge of possibility. I do think DXCs will be part of a multi-experience portfolio, but only a part. To tail off, I really think we should anchor these kinds of discussions with use cases - What problem are we trying to solve and for whom?
Strategic Technology Leader | Omnichannel E-commerce Expert
2 年Interesting read, and nothing there I disagree with, except maybe the DXP vs DXC dichotomy itself. The way I read the market, that’s perhaps jumping a few steps ahead. The questions I see are more in the line of monolith vs MACH/composable, (perhaps DXP vs MACH).This may then be followed by the question of DXC, eg composable with or without DXC. Personally, I’ve had the pleasure of buiulding composable in both ways, and am unreservedly a DXC fan, but the question has value. Do we add a single point of failure to our otherwise loosely coupled composable stack? Is it worth yet another licence to get this flexibility? And fiaally, if I add a layer between content sources and front-end, am I building myself a monolith with the added cost of composability? BTW, you don’t have to convince me of the value proposition, but these are some of the questions I’ve been seeing in the market. ;-)
Head of Global Sales @ Uniform | GTM Strategy | New Business Development | Partner Management | Marketing | Customer Success
2 年Good stuff Darren Guarnaccia!? I see Digital Experience Composition (DXC) as solving similar problems to what Sitecore was solving when I started working there in 2007.? Web content management systems (WCMS) were built to make it easy and fast for marketers to create, edit, and manage digital experiences.? Fast forward to today, composable architectures have once again made it hard for business users to create, edit, and manage digital experiences.? DXC, like a WCMS in 2007, solves this problem.?
Director of Content | Helping startups achieve marketing objectives through comprehensive content strategies and SEO.
2 年I can't agree more. The outcome truly matters to brands, not the technology itself.