Explaining the blueprint for Digital Experience Platforms

Enable omnichannel digital customer journeys by stacking digital and customer platforms leveraging event-driven and decoupling architecture.

24 min readApr 15, 2022

This article discusses how a layered digital architecture can help organizations enable digital capabilities faster without being impeded by its legacy infrastructure and platforms.

Part II: Explaining the blueprint for Digital Experience Platforms

In the previous digital era, the differentiating experiences were deemed to be confined to customer-facing channels only. However, the new digital transformation (DT) considered both (customer and agent facing) user interfaces to include differentiating experiences. The customer experience (CX) practices equally apply to both types of user interfaces across all channels.

Architectural guidance for build vs buy has always been to buy off-the-shelf application packages for commodity software and custom-build for differentiating experiences. In DT this guidance has added a few more dimensions to ensure that platforms support omnichannel experience, leverage cloud, build modular, API-enabled services, event-driven design, reactive microservice architecture, etc.

Portability is an important architectural concern especially around the brand’s Intellectual Property (IP). At present, there are three large cloud service providers including Microsoft, Amazon, and Google, and many others are joining. In addition, large organizations maintain their data centers (aka on-prem). Consideration can be given to a multi-cloud approach while developing portable software by carefully selecting non-propriety cloud services to avoid vendor lock-in. Technologies like OpenShift, Kubernetes, and dockers can enable a multi-cloud strategy. It further reduces the risk of business continuity if an organization needs to activate a cloud exit strategy from a vendor.
In omnichannel, customers will likely engage with a brand in more than one channel. As technology evolves digital channels are growing beyond web and mobile. The brand must ensure that they provide a consistent and connected customer experience across all channels. Customers will likely start an interaction in one channel and complete it in another channel. This creates new complexities to manage customer journeys, i.e., customers may start in one channel (e.g., mobile and save shopping cart) and resume in another channel (e.g., web to checkout and pay). Often, customers may take three or even four channels to complete a single transaction.
Customer expectation is changing well beyond omnichannel experience. Today, customers expect that brands know their customers and they have relevant information to personalize the experience. Hence, developing the right customer insights (i.e., actionable insights) that can drive a very personalized and emotional customer journey is paramount in the future digital world.

Key architectural components of digital experience platforms are the following:

**Figure:** Digital Experience Platforms

Layer 1: Digital Core

Digital User Interface (UI) Platforms

Web or Mobile user interfaces consist of both off-the-shelf and custom-built applications. Often the agent or employee-facing experiences are provided by off-the-shelf software. Many industries do develop differentiating experiences for their sales and distribution channels, e.g., telecom operators provide B2B portals to their distribution channels and MVNO resellers, insurance companies provide portals to their advisor network, and suppliers provide punch-out portals, etc. These portals make a huge difference to an overall customer’s omnichannel experience, as well as brand advocacy by channel partners.

Brands invest more resources in building their customer-facing experiences. They are the key brand differentiators. Many user interfaces leverage client-side Single Page Application (SPA) pattern and Reactive framework, e.g., Google’s Angular, ReactJS (used by Facebook, Instagram, Netflix, Spotify, WhatsApp), etc. React Native framework can create native mobile apps for Android and iOS using React. These frameworks work well with modern UX Design Systems (see below) and enable product team building user interfaces to work closely with User experience teams, something that was an issue in the past practices.

As the organization moves towards Event-driven architecture, it will require additional react components, e.g., node.js for service-side implementation, redux framework for state management, etc. Node.js can be useful in chat apps, real-time dashboards, registration pages, etc.

React-based UX bodes well with the customer journey model to create independently deployable components for macro or micro journey applications with independent DevOps pipelines.

Brand’s public sites or other microsites can be developed in off-the-shelf Content Management Software like Acquia, Adobe, OpenText, Oracle, etc.

Open Digital APIs Platforms

Open APIs enable the brand to make its services publicly available through an API. The brand provides a registration process to onboard consumers to their open API. Many brands provide developer portals for the larger community to use their Open APIs, like Facebook, Twitter, Google, etc.

The Open APIs will employ good security authentication and authorization protocols. It should have a simple and logical resource structure and support high availability and performance in a public environment. External developer communities can use these APIs to develop their open applications which will help the brand popularize its digital services.

Open APIs can also be used in Business-to-Business scenarios to provide the brand’s key services to partners. Partners can then integrate these services within their customer journeys to sell or support business transactions. The brand can also expose its Open APIs to aggregators in their industry segments like Expedia for travel or Finicity for finance. Other industries like finance can support open banking, the Telcom industry supports MVNOs for subscriber provisioning, etc.

Open APIs often need to be metered to report their usage. In some cases, the brand may monetize some of its services to charge pay-per-use.
Developer’s Portal: A good Open APIs will provide a decent developer’s portal with easy-to-understand documentation. The portal will be public (internet) facing and it will require similar content authoring & approval process as any other public site for the brand. It should support features like self-registration and profile management, API catalog browsing, allow testing of APIs, creation/management of user applications (that will use Open API), issue security tokens for consumer applications, monitor API usage, and provide discussion forums.

User Experience (UX) Platforms

Experience or Touchpoint APIs are created to support digital experience and they act as the back end for the front ends. The idea is to keep business logic away from User interfaces and encapsulate it in an API layer closer to the touchpoint (or where experience is delivered). User interfaces can work more closely with UX Design systems to leverage reusable components and follow its guidelines, without necessarily worrying about business logic and data.

Experience APIs are an essential toolkit for user interfaces that leverages client-side single-page application (SPA) pattern and reactive frameworks. They can drastically improve performance for micro journey applications by providing data aggregations and simplifying integrations to back-office platforms. Both web and mobile user interfaces can leverage common experience APIs to significantly reduce duplication of work and promote reuse.
UX Design System: The use of the design system has significantly expanded to create a cohesive user experience, well beyond the traditional brand style guide. It includes design principles, style guides, reusable components, guidelines on UX patterns, or when to use the components, a resource portal for UX developers, etc.

Shopify’s design system includes six experience values, Figma started its design system with three design principles. Adobe’s style guide includes color, typography, illustration, data visualizations, etc. Google’s material design system provides UX components and guidelines on how to use the components. Spotify, adobe, IBM’s carbon, Ant Design, and others have similar design component libraries.

Most companies can start lean by picking one of the design system platforms and augmenting it to build the brand’s design system. The design system can be managed by a small central team and can leverage a large developer’s community within the product teams to develop its reusable components. More mature companies can create open-source for their design system to tap into a larger community. They can aspire to run their Design system as a digital platform (as a service model).

Visual Design System can help develop early prototypes that can be used for user testing and customer feedback before building more detailed UX designs for it. It allows UX teams to mock up a wireframe layout with an easy-to-use intuitive interface. It provides collaboration features to share the wireframes with other teams and to give a live presentation to customers to gather feedback. Sketch, Axure, etc. are great visual design tools. Some platforms allow automatic generation of sketches to UI Component libraries.

Style Guides is a browsable catalog of components and relevant documentation. It provides the purpose of components, associated demo, code-snippets, version, or status of components, etc. It also includes the brand’s color palette, typography styles, logo images, icon graphics, etc.

User Interface Component library includes react-components, CSS style sheets, etc. It may include a hierarchy of style sheets, android/iOS components, and web react-components. Generators can automatically push react components into Style Guides browsable catalogs for developers to view through DSM Portal.

Package Manager to support packing of UI component and style libraries, versions, dependencies, and releases. It will publish them to an artifact repository. NPM is a commonly used package manager for react. Packages can be stored on a common artifact repository, e.g., Artifactory.

**Figure:** User Experience (UX) Design Systems

Journey Management & Personalization Platforms

Journey Management (JM) platform enables the brand to support consistent and connected experiences across all channels. During an interaction, it will keep track of customer steps in real-time and orchestrate journeys. It provides four key capabilities:

1. Customer journey mapping and visualization provide an ability for business users to visually create customer journey maps, associated journey steps, milestones, and associated actions.

2. Integrates with sub-systems to receive data to track journey progress and activate an action during key moments or milestones.

3. Orchestration of customer journeys when customers interact with a brand on their digital or other channels.

4. Provide customer journey analytics to allow business users to monitor and track the progress of an end-to-end journey.

**Figure:** Journey Management Capabilities

Personalization Management (PM) platform provides real-time listeners aided with artificial intelligence to support the personalization features, e.g. Amazon Personalize, Google Recommendation AI.

Personalization features are implemented at two levels, either a one-off personalized interaction in a touchpoint or an end-to-end journey across all channels personalized for each user. Common use cases include product recommendations, content recommendations, personalized offers, optional features, guided experiences, personalized in-context emails, targeted messaging in digital channels, personalized menus/navigations, resume last activity, etc.

Personalization criterions allows to develop audiences. Audiences are list of users (B2B) or account (B2C) that matches specific criteria. Customer segmentation can provide criteria for personalization to be delivered at three levels. E.g., Segmentation based on regional/product/location/etc., segmentation based on persona/behavior/affinity/etc., segmentation based on individual’s situations based on their goals/existing products/life moments/etc. Personalization criterion should be shared through common data layer to ensure all participating platforms can make independent decisions without creating circular calls between platforms.

Personalization will need to be optimized for digital channels. Too many dynamic calls to deliver personalization features can negatively impact user experience. Hence, personalization features will often need caching to ensure desired performance in digital channels. Reactive framework based on event-based design can support many personalization features without hindering user experience. Events can be used to send signals to personalization engine that can respond back reactively. In many use cases, customer segmentation and audience will allow caching personalization options for digital channels, for instance, contents can be readily available based on region or location.

The modern digital experience needs two differentiating personalization compared to traditional experiences. Firstly, personalization should be customer-led. It should focus on customer value rather than what the brand wants to sell. Secondly, it should empower customers with personalization choices rather than controlling their options and avoid overloading them with irritating messages. These messages are often counter-productive.

Personalization should include User Preference Management which enables customers to choose how many personalization features they prefer, e.g., frequency, channel, method of communication (emails, SMS), interest, privacy, etc. For example, if a customer chooses to toggle off any guided selling personalization feature, then this choice of the customer must be respected. This is a critical element of customer trust.

**Figure:** Examples of personalization features

Interaction Management (IM) platform is responsible for delivering digital assistance (to journey application) during a live interaction with customers. It can support many use cases like next best experience, cross-channel marketing, or personalization. It works with the rest of the ecosystem including journey management, personalization engines, digital intelligence, and campaign management to provide real-time assistance to customers through customer journey applications.

It functions in two modes. It can support journey applications to execute actions or certain personalization features defined in a particular customer journey, or it can dynamically inject them during a customer interaction session.

IM platforms often provide Decisioning Engine (DE) capability. It can create a flow to integrate with many subsystems to receive information and run it through a decision tree. Once it solves the decision it will send the action or decision back to the journey application. For personalization features supported through a decisioning engine, it can also leverage personalization engines or real-time scoring AIs and provide final personalization action back to a journey application. Traditionally, IM platforms were also calculating propensity scores or customers’ intent. In modern architecture, these calculations are best handled in AI or machine learning platforms. They may expose APIs to integrate with the IM platform.
Content & Digital Assets Management (DAM) platform is responsible for maintaining marketing content, images, videos, etc. The content metadata should include tags for customer journeys, personas, sentiments, and other useful elements. Customer intelligence gathered in a digital intelligence platform can help connect the customer to relevant content. An AI-driven content intelligence should provide curated personalized content for matching personas, journeys, campaign events, or other relevant subjects.

Dynamic contents: To support personalization and reusability, contents can be maintained dynamically instead of static contents. Structured content templates should be maintained with metadata. Templates can have atomized contents like building blocks. Within a template, a block of content can be dynamically replaced based on the customer’s persona or other criteria to provide more personalized content.
Digital Intelligence (DI) platform will retain customer personas, actionable insights, and other relevant intelligence. It will allow users to create deeper profiles (or persona) of customers. It then helps to easily select audiences for segment targets and tailor a more personalized experience based on demographic or other persona qualities.

DI platform will gather customer intelligence from various data sources to develop a persona for “each” customer. For instance, it can toggle customer indicators based on demographics, segmentation, behavior scores, CX measures, sentiment score, affinity, product intelligence, recommendations, social analytics, spatial analytics, and other scores from machine learning (ML) models. For example, it can update the churn propensity indicator from “propensity to churn score”.

The platform will also gather actionable insights from the artificial intelligence (AI) platform based on prior information gathered during customer interactions, customer transactions, and 3rd party data. AI platforms use a variety of machine learning models like predictive, prescriptive, and diagnostic to generate actionable insights. These then can be mapped to a particular “action” during a journey.

This information will also be leveraged by Journey Management to orchestrate customer journeys and activate relevant actions based on matching customer personas, their indicator or tags, and actionable insights. For instance, a churn indicator with a score of “8” can activate an action on a journey to offer a bundled discount to a customer. This information is also useful for Interaction Management to dynamically inject personalization features like an automated recommendation, next best actions, etc.

**Figure:** Sample customer persona card with actionable insights

Artificial Intelligence (AI) platform is an enabling technology that can analyze and process large data through machine learning and data science. Machine learning relies on computers accessing data that they can learn and use for themselves. It uses complex algorithms to learn and gradually improve its accuracy. AI creates a unique customer experience during key journey moments, and it can provide support for personalization, next best experiences, chatbot responses, etc.
Campaign Management (CM) platform provides capabilities to create cross-channel campaign events. It includes several stages of CM, e.g., planning, executing, tracking, analyzing, and optimizing a campaign. Campaigns can be targeted to a specific channel and audience. It can maintain goals and budgets for each campaign. It allows to select content targeted towards goals and audience, and desired call to action, e.g., redeem a voucher or leave a review. Campaign analytics tracks each campaign and can provide metrics like bounce rate, conversation rate, email opens, click-through rate, etc. Campaign events can also display marketing or other messages on the digital web or mobile channels through interaction managers.
Notification Management (NM) platform provides capabilities to record all communication sent to and received from customers. This includes messaging on digital channels (web, mobile, others), email, SMS, paper mail, etc. Customers should be able to search and review all past/present notifications through the brand’s self-service portals. NM platform is also responsible for sending and receiving outbound/inbound messages based on customer preferences and prioritization for a method of communications.

**Figure:** Journey Management & Personalization Architecture

No single platform can provide all the above capabilities or cover all personalization uses cases or serve as a single decision engine, despite lofty claims to the contrary. Many independent solutions will come together to provide overall platform capabilities.

Qualtrics platform has many digital experience management capabilities including market research, brand tracking, and perception, pricing comparison, CX measurement, segmentation, journey management, orchestration, etc. Segment, Pointillist also provides similar capabilities. Adobe and SAS platforms provide journey capabilities for marketing automation. Miro provides a journey mapping collaboration platform. Many platforms that provide journey management capabilities generally support it within marketing campaigns. They may not support other journey stages, like onboarding customers. This is primarily because onboarding is complex and involves many different product lines and channels, and its use cases vary in different industry segments. Amazon Personalize or Google AI can provide cloud-based engines to support customer engagement, recommendations, etc.

Other Digital Platforms

Conversational Management platforms are driven by artificial intelligence that allows people to interact with computers or devices in a way that mimics human conversation. A brand can leverage them to provide conversational user interfaces through their website or mobile app.

Alexa, Google Home, and Siri are examples of virtual assistants that are available on mobile phones or other smart devices. Chatbots help customers conduct chats on websites. An automated virtual assistant handles incoming calls on the customer service phone.

Amazon Lex and Google DialogFlow are platforms for chatbot and conversational AI. Amazon Alexa and Google Assistant are platforms to integrate with smart assistants.
Social Management platform
Digital Store & Payment Gateway

Connected Devices Platforms

A typical connected Internet of Things (IoT) smart device architecture includes a wireless smart device, intelligent gateway, routers, cloud computing, edge processing, over-the-air activation, customer service web portals or mobile apps, and open APIs.

**Figure:** A typical connected Internet of Things (IoT) smart device architecture

Sensors & Actuators: Connected devices either monitor (i.e., sensors) or control (i.e., actuators). They monitor/control a device or a process, e.g., a smart bulb, or water leakage detector. Sensors are capturing data on the status of a device or a process. The device may be measuring temperature, humidity, fluid level, monitoring the manufacturing process for quality, etc. The device will send sensor data to edge computing for processing.

Actuator control or move a mechanical system on a device. Actuators can be activated by operators using a control that originate in the mobile app or through a smart app. The control instructions are passed to smart devices through Internet gateways and edge IT. The control application processes that instruction and send controls to the actuator in the connected device which executes those commands.

There are three classes of devices¹, 1) Smallest devices with 8-bit System-on-Chip controller like Arduine, 2) Atheros and ARM chips like used in small home routers, 3) Full 32-bit/64-bit platforms like Raspberry Pi or the BeagleBone, which may run a full Linux OS or another suitable Operating System, such as Android.
Connectivity & Topology: Topology depends on the devices and what services they provide. Direct connectivity using TCP/UDP protocol through Wi-Fi or cellular network. Other topologies include Bluetooth, Near Field Communication (NFC), Mesh radio networks (Zigbee, DigiMesh), etc.
Edge Computing: Edge or fog computing is to process and store information as close to a connected device as possible. Edge computing occurs on gateways, local servers, or other edge nodes. Processing in edge compute reduces network latency when sending or receiving data from connected devices. This will improve device performance and efficiency. Lessor network data means it can also conserve the battery life of the device.
Customer Portals & Mobile Apps: Provide self-service web portals and mobile applications to register and control connected devices.

Smart Assistants: Integrate with Smart assistants like Amazon Alexa and Google Assistant.

Platform Capabilities: Provide controlling applications, reporting, analytics, monitoring, etc.

Layer 2: Integration Core

Two concepts have evolved during the last decade enabling new patterns to support digital:

SOA vs Microservices:

Most organizations are abandoning the old Service Oriented Architecture (SOA) pattern in favor of a Microservice pattern with domain-driven, event-driven architecture patterns. This has significantly changed the outlook of how we developed SOA-style web services in the past and how newer microservices are designed, built, and deployed today.

Technically microservice is a sub-pattern of SOA. In practice, SOA represents the monolith culture with centrally maintained control and a façade of orchestrated services from fine-grained to coarse grain. SOA also added Business Process Management (BPM) in the mix to manage business processes or business rules which further complicated implementations. These approaches resulted in cascading dependencies in developing SOA-style services making it more difficult to enhance and scale.
On the other hand, Microservices are all about modularizing and decoupling capabilities. It’s an anti-monolith culture. Instead of creating one large service, it promotes smaller entities through ideas of domain-driven design and bounded context. The broad definition of microservice architecture is an architectural style that functionally decomposes an application into a set of services. Each service has a focused and cohesive set of responsibilities, e.g., shopping cart, checkout, order, payment, shipment, etc.

Microservice architecture is a great tool for strangling a legacy application by chugging focused domains out of legacy, systematically, over a period. This pattern is known as the strangler fig pattern.
SOA was optimized to avoid duplication whereas microservice prefers decoupling over duplication. Instead of orchestration, it promotes aggregate domains where selective data from microservices can be duplicated to create an aggregate domain using an event-driven pattern, e.g., order + payment + shipment can create the aggregate_order domain. This is referred to as Command Query Responsibility Segregation (CQRS). This technique can significantly improve the digital experience over a traditional SOA orchestration façade (even with caching). For instance, it is a typical performance issue with many traditional web or mobile apps today that they must call dozens of services to display dashboards or landing pages. Instead, they can call a singular aggregate API (instead of making dozen orchestrated service calls) to improve response times.

SOA provided several patterns to deal with aggregation, e.g., scatter-gather pattern, chain pattern, branch pattern, proxy pattern, etc. Each one of them is useful in its circumstances. Microservice on the other hand promotes the Sega pattern over an orchestration.
Another limitation of SOA was that, too often, the backend details of the System of Record (SoR) were exposed by SOA-style web service using data model and implementation modalities of backend application. These are referred to as service-based contracts (or server-side contracts). As the number of web services increased in an organization, their reusability reduced, and digital/journey teams created more and more orchestrated services to go around rigid data structures and backend applications rules. On the other hand, consumer-driven contracts are based on a closer relationship between the API and the API consumers. This creates stronger collaboration between API providers and consumers to build value-driven API by considering how and where the consumer will use it. For use cases where a legacy or backend application exposes its service, this microservice-style API based on a consumer-driven contract is more productive for customer experience journeys and digital in general.

These differences, limitations, and benefits of each should be well understood by a Digital Architect before leveraging them in their digital layer.

2. Orchestration vs Choreography

Service orchestration represents a single centralized executable business process (the orchestrator) that coordinates the interaction among different services. The orchestrator is responsible for invoking and combining the services.

The relationship between all the participating services is described by a single endpoint (i.e., the composite service). The orchestration includes the management of transactions between individual services. Orchestration employs a centralized approach for service composition. This pattern is a tightly coupled architecture.
Choreography pattern means that one service doesn’t talk to another service to instruct an action. Instead, each service is observing its environment independently and acts on events autonomously.

Services are interconnected through an event hub and consumers subscribe to the event channel. When an event occurs, it is published on the event channel. Each service subscribes to it and performs its activity. This makes it easy to add new services to the mix by simply creating an event. This pattern denotes a decoupled architecture.

**Figure:** Orchestration vs choreography

Both patterns have pros and cons.

The key benefit of choreography (sega pattern) is the decoupled architecture that leverages event-driven design to remove impediments created by a centralized monolith logic and dependencies. Often orchestration uses a business process management (BPM) type of orchestration process, making it difficult for digital to be detached from the core. The event-driven design provides the flexibility to have more distributed control by removing hard dependencies. Each service can be independently built and deployed without impeding others.

Another big benefit of event-driven is that failure of downstream service doesn’t break the entire process. Rather, downstream services can receive an event to finish the task once they recover from failure. This reduces customer impacts on service level agreements (SLA) due to service failures.

There are cons to this approach as complexity is shifted, and often it’s difficult to visualize an end-to-end flow to diagnose and fix errors. This problem is addressed by a service mesh pattern that uses correlation ids to link all inter-related calls and it provides a visual service map of an entire sega.
The benefit of service orchestration is that it provides one fronting service that central control flows for downstream processing but it’s less flexible than choreography. Unlike event-driven, failure in a single service can cause the failure of the entire orchestrated process.

Often business logic is extracted into the BPM type of orchestration process making it more rigid and monolith. It also created increased dependencies with point-to-point integration between orchestrator and downstream services. This makes it difficult to independently build and deploy these services.

Integration Platforms

API Platform: It’s an evolving domain as technologies are continuously evolving. Enterprise Service Bus (ESB) is legacy, and it is contained to use only for maintaining existing web services. Two patterns currently exist in many organizations. API Gateway is a centralized control plane while service mesh breaks these functions into microservices. When they are used together the API gateway can act as a mediator in a service mesh architecture. Here API gateway is used for north-south traffic (external traffic) and service mesh is used for east-west traffic (internal traffic).
A service mesh pattern has been gaining popularity due to its widespread adoption of cloud-native applications. It represents a microservice pattern. It simplifies service-to-service communications needed for microservice architecture. Microservices are deployed in containers like Kubernetes or Nomad. It provides a sidecar proxy that runs alongside each pod (instance) and communicates with each other to route the traffic. A client-side service discovery function is embedded into the sidecar to discover service locations. Sidecar proxy also communicates with cross-cutting functions like logging, security, authentication, authorization, alerts, metrics, and service maps. Some service mesh tools are Istio (backed by Google, IBM, and Lyft), Linkerd, AWS App Mesh, Consul Connect, etc.

**Figure:** API Gateway and Service Mesh working together

Platform APIs: It includes a combination of older and newer APIs. It may have existing legacy SOAP-based Web Services through Enterprise Service Bus (ESB), or new JSON-based APIs through API Gateways. These services provide integration to all platforms including customer, intelligence, and legacy platforms.
Event Hub: It’s the backbone of event-driven architecture. An event-driven architecture consists of the following components:

Events are delivered in near real-time so consumers can respond immediately to events as they occur. An Event is a piece of information that may apply to one or more receiving domains at a given time. It represents changes to the system state. An Event will propose a problem, opportunity, threshold, or a deviation or change to its consumer. An Event is self-contained, unique, and time relevant. The resulting action of an event could trigger a business process, invoke a service, etc.

Event Producers are services that create and push events from providing platform. They are decoupled from consumers — a producer doesn’t know which consumers are listening.

Event Channels are mediums where an event lies before consumption. These are maintained by Event platforms like Confluent Kafka, Amazon SNS/SQS/ kinesis, Azure Event Hub, etc.

Event Consumers are services that consume incoming events.

**Figure:** Event Hub & Event-Driven Architecture

Event hub supports two models for event-driven architecture:

Pub/sub (Publish/Subscribe): When an event is published, it sends the event to each subscriber. It keeps track of subscribers. After an event is received by the subscriber it is marked completed and then it cannot be replaced by the subscriber.
Event streaming: Events are written to a log. Events are strictly ordered (within a partition), and durable. Consumers don’t subscribe to a stream, instead, it read from part of the stream. The consumer is responsible for advancing its position in the stream, which means consumers can join the event stream at any time, and it can replay events.

Decoupled Data Platforms

Decoupled Data Platforms: The objective of decoupled data domains is to provide data closer to the consumer. For instance, for organizations building their digital ecosystem in the cloud this approach can provide core data in the Cloud closer to digital systems. It’s also useful to detach core legacy data (from mainframes or other monolith sources) to more modern data architecture to enable digital transactions.

Decoupled Data Architecture: It follows Command Query Responsibility Segregation (CQRS) pattern to provide a read-only view of data. Changed data is pumped out of the data provider platform. The provider platform could be a legacy platform, customer platform, or digital platform. The data can be from the system of record (e.g., bills, orders, fulfillments), System of Engagement (e.g., customer interaction), or System of Insights (e.g., churn propensity score). Data is pumped out of the Provider platform as “private events” using Change Data Capture (CDC) service. These events are received by decoupled domains where they get processed and saved in domain databases. Data may also get reorganized for digital consumption. It also pushes a public event out for systems that need a local copy of relevant data.

Security Platforms

Customer Identity & Access Management (CIAM): It provides capabilities to support the customer user experience in various client journeys, e.g., digital registration and login across all interaction channels and devices. It leverages the Enterprise Identity Management technology platform. It enables progressive profiling, consent management, KYC, and other critical functions by providing a single identity for customers and their digital users.
Security Platform: It will provide capabilities for single sign-on, session management, authentication and authorization services, multi-factor authentication, user directory service, and API access management. Most of these capabilities are available in commodity platforms like Okta, Ping, etc.

Layer 3: Traditional Core

Customer & Intelligence Platforms

Many capabilities of legacy platforms can be transferred to Customer Platforms. These platforms can provide critical capabilities to enable omnichannel digital experiences. It can synchronize its data with legacy core leveraging event-driven and decoupling data patterns (mentioned earlier).

Customer Relationship Management (CRM) provides many of these capabilities. It can provide a Real-time 360-degree view of the customer across the entire customer lifecycle. Customer Management (CM) can manage customer hierarchies, contacts, addresses, accounts, and portfolio information. It can maintain customer interactions, to-do, notes, and other associated information.
Product Management (PM) manages all product offers across the line of businesses, product features, eligibilities, price, and other complex business rules. It will also provide capabilities like browsing eligible products, quotation management, etc.
Order Management (OM) provides headless ordering services that can be leveraged by digital channels. It manages all orders for all products across LOBs and hides complex manual workflows of the legacy core. Once the order is taken it integrates with a legacy to fulfill the orders. It manages statuses through various stages of the order life cycle (e.g., initiated, submitted, suspended, completed, etc.) and tracks all fulfillment activities. OM also supports the critical digital capability to resume ordering if the customer didn’t complete the order during the last interaction.
Service & Case Management (SM) support customer service requests or customer complaints, e.g., address changes, product failures, warranties, billing issues, etc.
Usage Management (UM) differs in various industries. Many industries may have specialized usage management solutions. For instance, Loyalty provides rewards management to draw from loyalty rewards. The insurance industry provides claims management. The financial industry provides money transfers, deposits, withdrawals, etc.
Agent & Partner Relationship Management (PRM) supports maintaining agent onboarding, channel management, end to end partner management.
Business Metrics provides analytics and business intelligence. [Read more on Business Metrics]

**Figure:** Customer & Intelligence Platforms

Part III: Enabling a Digital Platform-as-a-Service

Most of the capabilities of the digital platform will remain the same as explained earlier. Following incremental capabilities are required to establish a digital platform-as-a-service:

Provide registration process to onboard customers.
Maintain service level agreement (SLA) and report on QoS and service performances and outages.
Provide a call center and helpdesk to support customer requests and complaints.
Provide detailed billing based on metered usage.
Support multi-tenancy.

**Figure:** Digital Platform as a Service

Footnotes

WSO2 IoT reference architecture

The views expressed are my own and do not represent any organization. I aim to have respectful discussions that further positive change as we navigate unprecedented technological transformation. Change is constant, so my perspective may evolve over time through learning, testing, and adapting to new information.