On Building a Composable DXP: Q&A with our VP of Products

To accelerate the pace of digital business, many leading enterprises are looking to composable architectures. For content-driven digital experiences, this means building a composable digital experience platform (DXP) that will drive agility, speed, and resilience. Indeed, Gartner recommends that enterprise application leaders decompose their legacy monoliths, utilize more task-oriented packaged business capabilities (PBCs), and quickly "future proof" their stack and move to a "composable DXP to deliver composable user experiences."¹

To help explain what all this means, we recently hosted a webinar on the subject and you can watch the recording on Youtube here: Building Composable Digital Experiences. During the webinar, we received some excellent questions, so I sat down with Russ Danner, our VP of Products, to get answers to a few of them.  

Is any CMS with a plugin framework composable?

Any composable DXP can be considered pluggable, but not all platforms with a plugin system can be considered composable. 

The key differentiation is in the details.

• Construction: Are the platform and its plugins constructed in a composable way? Specifically, is the platform divisible and loosely-coupled? Is it constructed by replaceable components (repository,  content management, asset management, workflow, search, rendering, etc?) Do the system components and their plugins adhere to composable principles: are they discoverable, autonomous, orchestration ready, and so on? Or are they simply extensions to an otherwise monolithic stack? 
  
  
• Plugged-in vs. Composed: Many CMS platforms with plugin systems treat plugins as islands that, at best, can communicate with the core platform (but not other plugins.) I would label these as capable of “plugged-in” solutions rather than composed solutions.

What’s the difference? At the heart of composability is the idea that a business user can assemble a solution based on PBCs. This implies that the plugins (PBCs) can communicate and collaborate through loosely-coupled means such as events — and critically, that “wiring them together” is a no-code, non-technical activity. Further, because they can be wired together, it is possible to assemble non-trivial, sophisticated solutions not pre-defined by the plugin's creators. 
 
And then there's SDLC and CI/CD to consider. We’re all familiar with the software development lifecycle (SDLC) and continuous integration and delivery (CI/CD). Software development requires design, development, testing, deployment, and so on.

Delivering solutions via plugins also requires testing and deployment. However, critically — and I think, as it should be, few require any level of design and development. Further, the testing and deployment of plugin-based solutions are typically different from that associated with development efforts. 

Delivering composable solutions is different from delivering software solutions and also different from delivering plugin-based solutions. Composable solutions should be significant in size and scale, and sophisticated in features and capabilities. That is to say, unlike plugins, they will have an SDLC where S stands for “solution” rather than “software.” 

Can you compose a significant and sophisticated solution via your plugin system, and does your system support an SDLC? I think that is a good litmus test for determining whether a plugin system is composable or not. Hint: I don't consider Wordpress and Drupal to be composable.

Let's also consider the ecosystem: Who can provide packaged capabilities? Suppose the platform is closed for external vendors to provide their capabilities. In that case, even if the system is constructed in a very composable way, it’s not likely to provide all of the promised benefits. 

Finally there's the subject of standards: At some point, I think we’ll see this enter into the criteria.

Will there be standards in the future?  

There will very likely be attempts to create them at a minimum. Distributed objects and CORBA, SOA and ESBs, Portals (and portlet specifications) are a few similar examples. Standards benefit PBC vendors, and consumers and platform providers are eager to have their approach become the reference implementation. That’s a normal part of the technology maturity lifecycle, and it wouldn’t surprise me to see that develop for composable technologies in the future.

Are there any disadvantages to composable DXP solutions?

We have a great blog about this on our website. I’ll just try to hit some highlights.  

The main disadvantage is complexity.  If every capability is supplied by a different vendor then you have technical complexity in terms of technology mix and integrations, and you have vendor complexities in terms of support, contracts, and subscriptions. 

As a headless CMS around which to build a composable DXP, CrafterCMS combats this by supplying several pre-integrated PBCs out of the box, and a visual experience builder to compose digital experiences. 

As an API first platform, we also provide complete flexibility for mixing and matching PBCs. For example, you can use CrafterCMS simply as a headless CMS in another composable platform like Uniform.  You can use CrafterCMS’s built-in PBCs like search, profile, and deployment, in the same fashion. You can use our composition platform, Crafter Studio, with PBCs from our Marketplace as well as from other vendors PBCs. And you can extend our PBCs, or replace our PBCs.

Here’s an analogy: Many people like to go to Walmart for their groceries and their household needs. It’s one-stop shopping — but they only like this convenience because they have the option to get any individual item from a different vendor.  Particular about your meat? No problem. We’ll make a special stop at the local butcher.

There’s a lot of value in having the flexibility to choose but the convenience to do so only when you need to.

--

Note 1. Gartner Report, "Adopt a Composable DXP Strategy to Future-Proof Your Tech Stack", Refreshed 29 June 2022, Published 16 December 2020, Written by  Irina Guseva, Yefim Natis, Mike Lowndes, Gene Phifer, John Field.