Pros and Cons of a Composable DXP
A Composable DXP offers several distinct benefits, but like all things, has a few converse challenges. This does not mean the challenges disqualify a Composable DXP such as Sitecore SaaS from your list of options, but rather before making the jump… its critical to evaluate the pros and cons of a Composable DXP.
- 1 What is an Composable DXP
- 2 Composable DXP Pros
- 3 Composable DXP Cons
- 4 Conclusion
What is an Composable DXP
So without a long dissertation, what is a Composable DXP?
In its most basic sense, a Composable DXP provides a base platform with modules/extensions you can add to meet your needs… with the primary goal of creating a full marketing suite composed of “best of breed” applications vs. relying on a single platform attempting to do everything well.
Where possible, the typical integration of these modules/extensions is service based akin to a SOA (Service Oriented Architecture). Using service endpoints eases integration pains such as managing custom modules and configurations across a huge suite of products.
This differs from the current Sitecore “one platform to rule them all approach” as you can integrate best of breed applications on top of the base platform with a Composable DXP model. This is the “compose” part of “Composable” and best illustrated by the following diagram where the various “pieces” are added onto the base Sitecore platform.
Composable DXP Pros
The following are 4 strong benefits of a Composable DXP. Its critical to keep in mind that all because there is a full suite of products that “could” be added in a Composable DXP, doesn’t mean that you “should”… its all up to your requirements.
Lower Up Front Cost
Having a small base platform represents a lower base cost. This comes with less infrastructure requirements (Ex. less roles in XM vs. XP for Sitecore requiring additional App Services or VMs and backend databases). Additionally, less complexity may reduce the initial burden on developers (ex. no need to manage the configuration or certificates for xConnect or other services if the base platform is XM/intended for core content management).
With a composable architecture, you are not forced to use components you don’t need. Look at the example of users who leverage the full power of xConnect in an XP model… its on the low side. With a Composable DXP, you choose what to add to your base. Want centralized customer data to use across your systems? Choose CDP (formerly Boxever)! Want email management? Choose Sitecore Send (formerly Moosend)! In essence, you can choose what you need, and leave what you don’t.
Best of Breed Integrations vs. One Platform to Rule Them All
A single platform can’t be good at everything, and this is where adding “best of breed” applications in a composable manner is a huge advantage of this new approach. Instead of “one platform to rule them all” integrate a point solution that specializes in commerce, search, personalization, digital asset management, etc.
Base Platform is Less Complex
Less of trying to be everything makes the base platform less complex and easier to use. It may also have less bugs, as there is less “stuff” for the base platform to compile and execute. Once you have exhausted all the capabilities of the base platform, you can then extend with a “best of breed” application as stated above. Users may discover that naturally extending the base platform will not require as much effort as originally expected.
Composable DXP Cons
With all things, there are some considerations and trade offs. A Composable DXP has distinct cons that need to be evaluated before you make the jump into this new architecture. Here are 4 that come to top of mind.
Higher Integration Costs/Implicit Costs
Moving away from “one platform to rule them all” means higher integration costs. Specifically, what will the “best of breed” application(s) you are integrating cost and because each application is different, do you require distinct development teams that specialize in how to integrate and manage the application?
Additionally, for administrative users, the governance of differing user interfaces increases implicit costs (think of the difference between the Sitecore CMS interface and the Four51 OrderCloud interface).
Failure of Individual Parts or Networking Latency Between Layers
When you decouple a platform into a base with extensions via separate applications, you have increased risk of individual application failures and network latency between the layers of a Composable DXP. This makes it very difficult to know where an error is occurring in an overall platform as there may not be aggregated logging across the applications and constant network latency analytics to isolate where the bottlenecks are in the composed platform.
If you have already adopted a DevOps approach where each Sitecore role is a distinct repo, moving to a Composable DXP will be less tedious but still a large increase in complexity. This complexity comes from differing applications and even separate development stacks/frameworks (.NET, Node.js, Next.js, etc.) that may require distinct pipelines or even separate development teams to manage.
Its conceivable that a single organization or system integrator does not have the experience required to manage the full stack… or manage it well, so your DevOps will need to account for all the separate teams, repos, testing, and supporting governance for these distinct pieces.
With separate, almost distinct applications, your governance complexity is sure to increase. From tracking licenses, development methods, and teams that specialize in specific parts of the platform… there is a lot to keep under management. This is where a strong governance plan with a governance committee comprised of key stakeholders and product owners comes into play.
You can use the governance template in the “Sitecore Governance: How To and a Template Too” article as a starting point and create sections with policies and standards for each “best of breed” application.
A Composable DXP can offer a lot of great benefits… if executed properly. Carefully consider the pros and cons against your business requirements before making the jump. If you make the jump, its better to “slow down to go faster” by making sure you use every part of the base platform and any applications you add to the stack before adding more.
Don’t let the allure of trying to “collect all the pieces” outweigh your actual needs, as you will end up with a “frankencore” platform that is unwieldy and difficult to manage.