Achieving the Composable DXP
Today’s most successful businesses deliver great and compelling customer experiences in both the physical and digital worlds. Target has long enabled you to shop online, but they now offer a delightful blend of the physical and digital worlds for customers who want to pick up their orders on the same day. After you place your order online, Target sends you a message when your order is ready. You drive to the store. When you arrive at the store, they are waiting with your order, which they bring immediately to your car. While many retail businesses are struggling, Target is thriving.
Over the past 2 decades, businesses have invested in digital channels. The worldwide COVID-19 pandemic has limited access in the physical world, resulting in radically accelerated investment in the digital one. This is especially true with respect to making commerce an integrated part of customer journeys and breaking down the silos between offline and online customer experiences.
To accomplish this, an essential enabling tool is a Digital Experience Platform (DXP). Gartner, Inc. describes a DXP as:
“A digital experience platform (DXP) is an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.”
Traditionally businesses have taken one of two approaches to building a DXP: adopt a suite or build-your-own.
Adopting a suite has been the dominant choice for many enterprises. The category of DXP was created by the dominant web content management system (CMS) vendors, starting around 2010. DXP evolved from these CMS vendors’ efforts to expand their platforms to include personalization, analytics, and marketing automation.
Vendors chose different strategies to add these capabilities, but most accomplished it through R&D efforts or acquisition. The result was that vendors were able to sell a solution to meet all of the customer’s digital experience needs, packaged in a single, integrated product.
Organizations that adopted suites have found that:
- System complexity is greater than expected— Complexity translates directly into increased costs. The more complex a system is, the more resources are needed to cover development, maintenance, operations, and support.
- Niche skillset required to build and maintain the system— Finding qualified resources is hard, and those limited resources demand a premium. Dependency on a system integrator (SI) can create another form of vendor lock-in. System complexity translates into a steep learning curve for organizations interested in building their own teams.
- “Best-of-need” functionality is not always sufficient - This is an especially great risk for more mature organizations. When an organization must go outside of the suite’s limited capabilities to meet their needs, the organization ends up having to deal with the limitations of both the suite and build-your-own approaches.
- Technology changes faster than the suite can evolve - Modern web technology develops at break-neck speeds. It is very difficult for suite vendors, whose products are complex and based on technology from the early 2010s, to keep up. As a result, customers depending on the suite to provide capabilities are not able to take advantage of the latest innovations.
- Architectural limitations may prevent requirements from being met - The technology architecture of many suites is simply unable to meet modern performance and scalability requirements. These suites were designed at a time when websites were much simpler and customer expectations were very different.
Some organizations determined that the bespoke (or build-your-own) approach was more appropriate for them. These organizations settled to buy a few core capabilities (e.g. CMS, analytics, CRM), and then leveraged their own engineering teams to build the remaining pieces. Typically, the custom development effort focused on integration, building custom personalization, and creating custom UIs that allowed business users to interact with the systems.
Many modern and successful SaaS companies use this approach, as in many cases their website is top-funnel for their SaaS product.
Organizations that built bespoke DXPs have found that:
- Significant ongoing involvement from engineering is required - A level of cooperation and coordination is needed between technology and business teams that many organizations are not designed to handle. Ownership is hard to pin down or is distributed in a way that complicates decision making. This results in frustration in both teams and slows their ability to execute.
- Growing feature backlogs constrain business growth - Increasing demand for digital marketing hasn’t been matched by increased engineering budgets. This means that feature requirements get added to an increasingly long backlog of work. For businesses trying to transform to a digital-first approach, this presents a considerable obstacle.
In short, organizations must be able to deliver fast digital experiences quickly, and in a rapidly changing and unpredictable economic environment. Both suite and bespoke DXP implementations struggle to meet these demands. Something else is needed.
As opposed to the suite and bespoke DXP solutions, the Composable DXP is modular by nature. Best-of-breed technologies are easily connected through smart, cloud-based APIs that provide the capabilities to create engaging, contextual, and relevant digital experiences.
This modularity offers concrete benefits. Gartner, Inc. predicts that by 2023 organizations that have adopted an intelligent composable approach will implement new features 80% faster than their competitors who have adopted a suite or a bespoke approach.
Faster time-to-market gives organizations the ability to do more in less time. Since it takes less time to deliver new features, more features can be delivered in the same timeframe, enabling organizations to experiment with new ideas with less risk. The time that was previously spent on upgrades, re-platforming, and other expensive activities that provide little-to-no business value can be redirected.
A composable DXP divides architecture and functionality into what Gartner, Inc. calls PBCs: packaged business capabilities. A PBC represents a capability — or related set of capabilities — that is:
- Independently deployable
A composable DXP consists of PBCs from a variety of categories:
- Front-end — libraries (e.g. Vue, React) and static site generators (e.g. Nuxt, Next.js)
- Content — content management systems (e.g. Contentful, Contentstack, Sanity)
- Commerce — commerce engines (e.g. BigCommerce, CommerceTools)
- Search — search engine connectivity (e.g. Algolia)
- Analytics — site visitor activity collection and reporting (e.g. Google Analytics)
- Personalization — content personalization (e.g. Uniform)
- Customer data — collection of data and reporting on customers (e.g. Salesforce, HubSpot)
- Content delivery — a system that delivers sites to visitors’ browsers (e.g. Akamai, AWS, Cloudflare, Netlify, Vercel)
Each of these categories could contain individual PBCs that could be derived and extracted, depending on the needs of the business.
While the promise of the composable DXP is attractive, it is important to realize that while integration has become much easier over the past several years, it is still required, even if it is not obvious early on.
For example, building a site with Contentful (content), React (front-end), Next.js (front-end), and Netlify (content delivery) can be accomplished with a few clicks. Each of these systems is self-contained. One feeds very nicely and cleanly into the next.
But what happens when you start to take advantage of this approach and start adding more capabilities? Adding personalization may create a connection between content, the front-end, and the personalization system. Adding analytics may add its own connection to the content, the front-end, and personalization systems. This requires integration.
Even though these systems are designed to work together, oftentimes “work together” means that developers can easily connect these systems. The value of this reduced complexity is significant, but it is important to remember that there is a difference between connected and integrated. Connected means data can move between systems. Integrated means multiple systems work together as one. With this approach, connectivity is free, but integration is not.
Additionally, something more than integration is needed: a system that can coordinate the communication between systems. The integration enables one system to work with another system as if they were a single system. Orchestration takes this concept and applies it across multiple systems.
You might already have a website, and now you want to incorporate commerce. Your stack consists of a number of systems: CMS, CDN, front-end, static site generator, personalization, analytics, etc. Adding commerce to the mix is more than just adding a view of the product catalog and a shopping cart. You need to be able to incorporate personalized content into the product catalog and check-out process. You need to capture analytics during the shopping process. Orchestration is needed across these systems.
Uniform is the orchestration layer for the composable DXP.
For this year’s MACHathon, we built a blazing fast personalized commerce site complete with analytics, and we built it in 5 days.
Uniform is a MACH Alliance member. We participated in the 2021 MACHathon. This was a 5-day hackathon challenge to build a solution on the theme of “getting unstuck”:
“Due to COVID-19’s grip on the world, most of us have experienced what it means to be stuck at home. While that experience is new to many, it has always been the routine for those with health challenges and disabilities — with or without COVID-19. For our MACHathon, show up with your ideas on how to help people get virtually un-stuck.”
Our 5-person MACHathon team bent the brief a little and built a solution that demonstrates the benefits of a composable DXP enabled using Uniform, helping businesses to become digitally unstuck.
We used the following technologies:
demonstrating the digital experience, showing how these technologies come together to form a composable DXP.
Learn more about what we did in the MACHathon here.