Digital Experience Platforms (DXP) vendors are learning that their platforms cannot be all things to all people. The days of monolithic super-systems appear to be ending as vendors struggle to rapidly integrate a flood of new innovations with the quality that customers demand. Many of these mega-suites are inundated with technical debt that challenges both vendors and customers. Moreover, from a vendor perspective, extending their core stack with peripheral functionality distracts them from what they do best.
There has been a lot of recent talk about composable DXP's. These platforms focus on working well with third-party software e.g. marketing automation, customer relationship management (CRM), electronic document and records management (EDRMS), and enterprise resource planning (ERP). A composable system allows these components to be easily connected together to satisfy the requirements of each customer. Composable components can be deployed independently and handle incoming requests in totality (they are loosely coupled).
Modern-day systems almost exclusively connect systems via custom code that calls a remote API. Information is pushed or pulled by the client as needed. The transaction may be direct or pass through a purpose-built integration to extend the features of the connected system.
A composable DXP allows customers to choose their own technologies so they get exactly what they want and are supported by expert teams.
Composable DXP vendors appear to be taking one of two paths:
- Buy third-party technologies and integrate them into the core stack. This appears to be where Sitecore is headed with recent acquisitions of MooSend (email automation), Boxever (marketing orchestration), and Four51 (B2B eCommerce) or;
- Create advanced tooling, like orchestration and workflow, to support integration with third-party APIs. This enables the creation of complex real-time transactions between systems with little or no custom code
Both paths allow the vendor to focus on their core product while passing the support of satellite systems to experts in those technologies.
The key differentiator of a composable DXP is how it connects and transacts data between components. Integration techniques are not always in the spirit of composable DXPs.
Blind Syncing
This brute force technique replicates data in both systems. Typically the sync is triggered by a scheduler in one system and any data that has been modified since the last sync is cloned to the other. There are significant issues with syncing:
- Nothing happens quickly
- It creates unknown data states in both systems. Users cannot be sure if they are looking at bad data about to be overwritten with good data, or good data about to be overwritten by bad data
- When updating, the remote data cannot be pre-tested before being overwritten
- Syncing maps one data element to another so cannot easily replicate an unknown number of elements in one system to a single element in the other
- It does not accommodate complex, granular, converted, or related objects
- Only modified data is synced so:
- Updating an irrelevant element causes an entire record to be synced unnecessarily
- Any schema changes or mass updates in one system will change the modified date causing every record to be updated unnecessarily
- The replication of data inflates both systems. This can impact performance and be expensive
Blind syncing is not ideal for a composable DXP as data requests are not answered in a timely manner. A more sophisticated approach should be adopted to improve data quality and responsiveness.
Single Source of Truth
A single source of truth substantially improves the quality of data as it only exists in the master system. If the slave system needs data it gets it in real time. For updates, data can be retrieved from the master, inspected, then updated in the master if it meets the update criteria. Users always see up-to-the-second data however implementing a single source of truth can be more complex.
- Custom code in the slave system is usually required at the points where the master data is accessed
- Propagation delays can degrade system performance
- Data volumes can be impacted if the master system has API constraints
Creating a single source of truth is on the right track but the platform needs to make it easier to process real-time requests without writing custom code.
Orchestration and Workflow
A well-designed composable DXP has a layered architecture that supports:
- orchestration
- workflow to process complex transactions
- data mapping and transforms
- alternative data sources
This functionality is akin to the services provided by the likes of Boomi, Informatica, Jitterbit, and MuleSoft but it is built into the DXP platform. Data can be pushed, pulled, and processed in real time between internal data sources (content, analytics, insights) or external systems (e.g CRM, EDRMS, ERP, email marketing automation system). Because a single source of truth is favored data availability is instant and the quality is high. Consider an example of a customer journey that involves several systems.
- A website visitor adds items to their shopping basket
- They view several products and accrue some browsing behavior
- They complete the purchase
- The purchase and browsing details are added to the CRM
- A salesperson wants to sell an abandoned product so adjusts a value in their CRM record
- The website is re-personalized to promote the abandoned product
- The visitor's CRM record is mapped to an email automation system
- Automation sends an email that offers the product at a discounted price
- The recipient clicks on the email link to visit the website and accepts the offer
- The products purchased and browsing details are, once again, added to the CRM
The easiest way to implement this is by using workflow and orchestration in a composable DXP platform.
What is Missing
It's not perfect! There are times when, for performance reasons or API volume constraints, data must be synced to a peripheral system (or vice versa). This creates data uncertainty but is often unavoidable.
Another challenge relates to the transaction event. It's easy to initialize a push or pull transaction from the DXP platform but how do we initiate it from the peripheral system without creating functionality in that system. We can't! All we can do is create an API to expose the DXP workflow and orchestration. This will allow developers to create functionality in an external system to initiate transactions with the DXP.
Conclusion
DXP vendors should not reinvent the wheel by creating and integrating their own version of a specialist software stack. Their dollar is better spent on architecting their core product to better transact with external systems in real time. For example, in the marketing automation space, DXP vendors should avoid building their own email automation component when great products like Pardot, Marketo, Eloqua, and Salesforce Marketing Cloud already exist. They better serve customers (and themselves) by providing powerful integration tools to support the real-time transaction of data between the systems.
FuseIT specializes in integrating Sitecore, Salesforce, and OpenText Content Manager. Contact us if you need help transacting data between your systems.
Comments
0 comments
Please sign in to leave a comment.
Related articles