Familiar Hammers in the DX Space: Different Perspectives, Different Tools

"If you have a hammer, everything looks like a nail" is a well-known metaphor that describes a cognitive bias towards using the tool or approach that is most familiar to us. This phenomenon holds true when it comes to practitioners in the digital experience space.

The DX Challenge: A Fragmented Technology Ecosystem

The problem that many of us in the DX space are trying to solve is finding the optimal approach to building modern, omnichannel experiences with a fragmented technology ecosystem. Enterprise brands have multiple content repositories, legacy systems, all-in-one DXPs, commerce platforms, CRM, ERP, PIM, home-grown systems, microservices, etc, that need to be exposed to a multitude of customer touch points.

Depending on your personal experience, your affinities, or even your personal goals, you may arrive at one of the following solutions to this challenge:

The CMS Practitioner’s Hammer: A Single Pane of Glass

If you’re a content practitioner with extensive experience in the CMS domain, the content management system often becomes the central hub for digital experiences. From this perspective, the CMS serves as the primary platform where all data, content, and media from various systems are integrated and unified. The vision is to provide content editors with a "single pane of glass"—a unified interface that consolidates information from multiple sources, allowing for seamless content creation, management, and distribution across different channels.

The Knowledge Graph Expert’s Hammer: Building a Semantic Layer

If you’re a knowledge graph expert, you may view the fragmented technology ecosystem through the lens of data relationships. In this approach, the problem is best addressed by constructing a semantic layer that serves as a connective tissue across multiple data sources. The semantic layer standardizes the vocabulary used across systems, ensuring that disparate data formats and terminologies align. This makes it possible to create meaningful relationships between entities, even when the data originates from different systems.

The DXP Enthusiast’s Hammer: The All-in-One Platform

If you have a DXP background, you may say that there is no need to look elsewhere because we have all the integrations you need to a variety of applications such as a PIM, commerce engine, etc., and we empower marketers with a perfect set of tools such as a site builder, personalization engine, even a CDP in some cases, to deliver amazing experiences on both web and mobile.

The SI’s Hammer: Custom Integration

If you’re a Systems Integrator (SI), you approach the fragmented technology landscape as an integration challenge. The solution often involves deploying ETL tools to extract, transform, and load data, ensuring seamless communication between various systems. Alternatively, you might leverage an integration platform as a service (iPaaS) for this purpose. When building a digital experience, a custom backend for frontend (BFF) architecture might be necessary. This BFF layer then acts as an intermediary, optimizing data delivery and tailoring backend services to specific frontend needs.

The Composable Hammer: Accelerators for Integration

If you’re aligned with the composable architecture approach, accelerators become a key option. These pre-packaged, pre-integrated, and pre-composed vendor solutions are designed to address specific use cases with efficiency and speed. Accelerators simplify integration by bundling the necessary components, reducing the complexity of connecting multiple systems like PIMs, CRMs, commerce platforms, and more.

The Content or Data Federation Vendor’s Hammer: The Unified Repository

If you’re a content or data federation vendor, your approach centers on creating a unified operational repository. The goal is to aggregate data from multiple disparate systems into a single, accessible repository. This centralized source allows data to be easily consumed by various applications through standardized APIs, simplifying integration and reducing data silos. However, building this unified repository typically involves significant ETL (Extract, Transform, Load) processes to ensure that data is properly moved, transformed, and loaded into the repository.

The Search Advocate’s Hammer: Just Index Everything

Let’s not forget search—this is actually the one solution very near and dear to me as I spent almost a decade building search solutions. This was, in fact, even the backdrop for our journey to Conscia. For those who are search believers, why wouldn’t you just index everything and access it using search APIs from every application?

Many Solutions, Many Hammers: Different Approaches for Different Contexts

There are aspects of each of the above solutions that are quite attractive depending on your specific use case, technology ecosystem, your team’s background, your aspirations as a DX practitioner, and even your affiliations within the DX space. I don’t think any of the above solutions is inherently wrong. The key is to start with the problem and work yourself back to a solution rather than the other way around.

When we built Conscia, did exactly that. We thought about the current state of enterprises and their technology ecosystems, considered all of the existing approaches and found patterns and tools that could be assembled into a unique solution.

We built our solution based on the following premise:

As enterprises continue to adopt a growing number of technologies, data silos will remain a persistent challenge, becoming even more complex as the pace of innovation accelerates.

Here are the principles we adopted:

When the data that needs to be exposed to the frontend lives in an API-enabled repository such as a headless CMS or a commerce engine, you don’t want to move it to another system. Instead, you want to access it from where it lives with real-time API orchestration. This allows you to treat the source system as more than just a dumb data repository. After all, systems such as your commerce engine hold business logic, not just data.

Unless,

The data needs to be enriched in some way with metadata, AI, relationships that have to be built offline, classification and taxonomies, etc.

When the data that needs to be exposed to the frontend lives in a legacy backend that does not offer APIs, you must sync that data into an API-first data layer in order to access that data in real-time. In this scenario, if the legacy system has business logic that needs to be exposed to the frontend, you must migrate that logic to another system or add it to the experience orchestration layer.

We call this the orchestration layer in your tech stack. You can build it yourself, or you can look at incorporating a DX Orchestration solution like Conscia in your stack that offers just the right mix of capabilities offered by the variety of approaches discussed above. If you’re interested in accelerating your development, reducing your TCO, de-risking your implementation, and future-proofing your investments, let's have a conversation!