DXCP - Digital Experience Composition Platform

0:00 - Intro

00:00:41 - Why do you think it's important to discuss DXCP in relation to composable?

00:03:08 - Can you enable disabled features in DXCP?

00:03:24 - Are you able to customize things in the DXP?

00:06:10 - DXCP in comparison to DXP

00:06:56 - The Idea of DXCP

00:08:02 - It makes a lot more sense to use SDK than integrating the search API to a DXCP

00:08:58 - Is there anything that's good from using any DXCP?

00:11:35 - DXCP as an architectural opinion

00:13:21 - DXCP as a guardrail and it's deeper issue

00:13:44 - The KEY Issue with DXCP

00:14:30 - Where architecture comes into play

Hi, my name is Karl. Welcome back to the Goodfrontend Show. Today we're gonna be talking about DXP, DXCP, API Orchestration, and BFF. Why do you think it's important to discuss DXCP in relation to composable?

DXCP, which stands for Digital Experience Composition Platform, I think, is a new category that was coined by Gartner, and uh, it is something that is for sure confusing to a lot of people. If I count the amount of questions I had about this DXCP thing, even before it got coined, I'd probably make at least a hundred pounds because it's just so confusing and, uh, depending on which context you're coming from, it just doesn't make any sense.

How is DXCP different from DXP? It's important to understand DXP first before we start moving into the ideas that, uh, came about as part of composable. DXP, which stands for Digital Experience Platform, is uh, things like maybe more tangible examples are like Adobe Experience Manager or Bloomreach, or SiteCore or EpiServer. Now, if people are familiar with these platforms, the idea is that this is like a unified platform that allows you to control the digital experience in one place.

So, for example a DXP would have the ability for you to, manage content via a CMS. It has the ability for you to personalize that content. It has the ability for you to analyze the data that is happening in your digital experience, and it has the ability for you to experiment and conduct multi variant testing. And it also has the capability perhaps to integrate a social media platforms and your commerce data or product data from a product information management system or from a commerce API.

So that's DXP. The idea is you provide this one single unified tool to your marketer for them to craft the digital experience if you like.

Can you, uh, enable disabled features there that, uh, let's say, cuz you said like one solution, right? So what if like, you don't need some of those solutions. Are you able to customize, uh, things in the DXP?

The idea of DXP is that it's not customizable solution. The idea is everything is out of the box, things just work.

So is this where DXCP come in because it's more like the, would you say customizable or composable in that sense as opposed to DXP having just the one solution?

Yes. Is the simple answer. Um, composable in general comes in because monolithic architecture, you know, this one size solution if you like, is not very flexible. So the idea of composable is that you break all these different aspects of your application and you integrate it yourself to create a best of breed solution. So for example, some DXP might be good at content management system, but they might not necessarily be good at personalization. And so what you want to do is, oh, I only want to use the content management system, but I want to use this emerging product to be able to do personalization. However, that doesn't necessarily work with the vendor, right? And so the organization who is consuming this DXP loses out. So then the idea when you come to composable is that you can put together your own best-of-breed APIs to create your digital experience if you like.

So for example, you can choose a headless CMS to provide the content and then you combine that with a personalization engine to be able to do personalization. And then maybe you use the same engine to do multi-variant testing or use another tool and then you connect also a customer data platform to handle your segmentation and so on. So the idea of a composable is that you compose all of these APIs in one place. And if I understand correctly, DXCP is meant to almost like bring the traditional DXP, but it enables you to bring in your own CMS, bring in your own personalization engine, bring in your own commerce data provider, and you do it in the single unified platform.

So that's the idea of bringing all these tools together is what you call DXCP as opposed to DXP having only one solution all in one product. DXCP is like having all several products with different solutions in one composed solution. I think that's what it is, if I understand correctly. But it's still quite confusing. <laugh>, of course, even I get confused because I don't necessarily believe, if you like, I don't necessarily believe that it does what it says it does.

Is it because it's not different from API orchestration or BFF, it's almost the same.

Yeah, exactly. I think the idea of DXCP is a bit like API orchestration and BFFs, but you just write less code to orchestrate. The problem I have with the concept as DXCP is that it almost like it forces you to do your orchestration through this platform, but it might not necessarily be the right thing to do. So let me give you a specific example. For example, if you are using a Search API and this search API provides an SDK and this Search API already solves the problem of regional caching. So it creates, which some search APIs do this. They create a distributed search network and they already solve the problem of caching and they provide you an SDK for you to be able to do it. It makes a lot more sense to use their SDK over integrating the search API to a DXCP.

One, it takes a lot less work. Two, it's more efficient, and three is more performant. Four, the experience is just much, much better. And fifthly, they already solved everything, so it's cheaper for the customer. Mm-hmm. <affirmative>. So I'm not entirely sure where DXCP fits in in that regard because it's not helpful. And a lot of these APIs are already thinking in that manner, whereby they're already thinking about the end-to-end experience and they're providing customers SDKs for them to be able to integrate their products directly to the storefront in a way that is efficient and good. Mm-hmm.

<affirmative>, if that's the case, if we already have all these SDKs and APIs already good by themselves, is there anything that's good from using any DXCP?

And that's also the question that I have, to be honest. It seems like, I don't wanna be harsh, but it's like solving a problem that existed two years ago, which a lot of the vendors knew they had and they solved it through SDKs. I tried to dig in a little bit on this, why do you need that DXCP? And I read a few blogs as to why people are creating the solution. And one of the things that struck me is flexibility. So, uh, one provider of the DXCP described it like this whereby the composition of the APIs is so rigid, whereby it's not flexible. And I thought to myself, man, I've done at least five composable projects and I've never had this issue of rigid composability. So to me, that's more a problem of the people within the integration as opposed to the concept and architecture of composability.

So DXCP does not resonate to me as a solution to a problem because I don't think I've ever experienced a problem in the first place. So, to answer your question, is there any point? I don't know. I don't think so. <laugh>, I mean, I personally wouldn't use it, but, uh, I could be wrong. There could be something, and maybe I just need to learn more about it. I did my best to sit on a demo to listen to what this thing does, but I honestly don't get the point. The only time that I understood what it's about was when I started talking to another developer who worked for another company, and I tried to listen on how they integrated the headless CMS. And I can totally see why a DXCP would be helpful to them because it would make the integration more flexible. But in my opinion, that architecture is wrong in the first place. The reason why it's not flexible was because the architecture was wrong. It was designed to be a point-to-point integration. Which doesn't make any sense, you know? And perhaps that's why I don't really understand what solution is this because I've never really encountered the problem they're trying to solve.

Is that where the difference boils down to the integration part? Say like, with the headless CMS, isn't there already an API specification on how to integrate this? SDK is provided and then you go to DXCP, it's also different. How is it implemented differently?

I think you're right, DXCP is like an architectural opinion. It's an architectural opinion that sort of provides railings on how to integrate a headless CMS. Maybe it just means that the chances of you doing it wrong are lesser with DXCP. But like I said, it's like a problem. It's like solving a problem that was present two years ago that is no longer present now. <affirmative>, and definitely will be less and less so as the years go by because the CMS itself and the other APIs themselves will create SDKs as they learn more about customer problems to prevent those things from happening. I'm always so surprised how creative developers can be. I completely understand from the vendor's perspective, you think that it wouldn't go wrong.

Uh, how have you seen that video meme whereby you have those toys that kids play with, the ones with different shapes like stars and squares, and you're supposed to match the shape to the corresponding slot? You would expect people to put the square shape in the square slot and the star shape in the star slot, right? But what some people do is they try to fit the star shape into the square slot just because it fits. I think that's what's happening with a lot of headless CMS integrations sometimes. People are just doing it wrong and DXCP is like creating guardrails for those mistakes. But to me, that doesn't make any sense. The real issue is a lack of competency among the people who are integrating the APIs, rather than a problem with the headless CMS or the architecture surrounding it.

And I suppose it limits the creativity of the developer who's doing the integration.

Exactly! The key issue with DXCP is that it takes composable back to the old world of DXP, where you can only do things one way. And that's the problem, isn't it? On one end of the scale, you have a very constrained architecture, and on the other end, in the composable world, you have a very flexible architecture. But what you really want is something in the middle. The problem is you can't have it all. That's where architecture comes into play. You need to carefully consider integrations instead of just sticking everything everywhere. And that's the main problem with composable projects today. They are simply being integrated incorrectly. In my opinion, all people need to do is read the documentation and have the right team. We can't underestimate the importance of people. Ultimately, the people implementing the composable project are key to its success.