Building a Digital Enablement Layer
Most Digital Service Providers (DSPs) aim to provide digital capabilities to customers but struggle to transform with legacy O/BSS systems. According to McKinsey research, 70% of digital transformation projects don’t reach their stated goals.
However, these roadblocks must not deter DSPs from achieving their digital goals. DSPs with robust digital capabilities boast a profit margin of 43%, compared to their counterparts whose margins hover around 21%. To capitalize on this opportunity, a horizontal digital enablement layer is an optimal approach. This hides the back-end complexities and paves the way for a smooth transition/IT transformation without significantly affecting the business’ digital needs.
Fig: Implementing “Horizontal Digital Enablement Layer”
This article elaborates on four key focus areas that DSPs should consider for building an efficient digital enablement layer. These focus areas with the given recommendations would enable DSPs to avoid pitfalls and achieve digital capabilities successfully.
1) Decouple customer-centric engagement layer from the current O/BSS
Customer-centric back-end features need to be decoupled from the existing O/BSS to create a layered microservices architecture. This is important because a decoupled and layered architecture creates a separation of concerns and sets clear boundaries for responsibilities, which makes it easier to isolate impact areas.
- Build the core API functionality – To do this, standardize the access to existing data and services, normalize data between separate domains and re-use API logic for different channels.
- Ensure separation of concerns by creating clear boundaries – Need to confirm that one functionality resides in only one microservice and not multiple.
- Create layering with complexity spread evenly – Creating something top or bottom-heavy will result in complexity. E.g., business logic should be handled in the microservices layer and not in the presentation layer. In cases where required and possible, implement a headless architecture, with clear demarcation of UI and logic.
- Have an optimal number of layers – Creating a multi-layer architecture is required but certain layers can be avoided if they don’t add value. E.g., directly expose OSS services, if there’s no BSS involvement/translation required while utilizing COTS/out-of-the-box capabilities of back-end tools.
Decoupling front-end from back-end will make changes purely on the UI faster & cheaper. This can result in a 25% reduction in effort and lead time.
2) Bridge the gap between domains with an aggregation layer to create and orchestrate cross-domain events
The key reason for introducing APIs is to increase speed and flexibility by decoupling channels from the back-end. However, to support true digital capabilities, more than just decoupling is needed.
- Use domain-driven design – Techniques like “event storming” create appropriate domain models that form the basis of the architecture for microservices and the boundaries between them. “Change data capture” techniques are the key to make this work with existing/legacy systems and enable the incremental transformation.
- Ensure smart combinations – If the back-end landscape is scattered – e.g., stovepipes per product, combine smartly to hide the complexity. Use smart combinations based on datasets. E.g., combine product data and usage data to advise on bundling, downgrades or renewal of the contract with better conditions and price.
- Orchestrate front-end events to back-end systems – Manage complete status and orders while orchestrating corresponding events in the back-ends. E.g., an incoming event on the Web care can have a corresponding event in the fixed BSS, mobile BSS, or both.
3) Ensure visual consistency in omnichannel experience
Independent channel interactions must coordinate to create one cohesive & consistent customer experience. Customers engage with DSPs across various channels, including the web, mobile, kiosks, online chat, and by visiting storefronts. Visual inconsistencies across channels might signal different functionality, flows, or offerings.
- Design for a seamless handoff with great visual consistency – Standardize the UI and UX building blocks for multiple front-end channels using technologies such as “FrontX.” Incorporate work baskets in the process for better handoffs.
- Use multi-brand digital style guide – Use a similar style guide on all different channels. This ensures familiarity, where users can take advantage of any knowledge acquired in previous interactions.
- Make use of smart digital helpers – Leverage concepts like smart recommendations by intelligent chatbots, next best action prediction based on Big Data analysis, and Artificial Intelligence (e.g., recognize current customer emotion based on chatbot input to increase customer engagement).
4) Create centralized mono repository to drive reusability of micro elements
Existing O/BSS architecture prohibits reusability. The provided APIs lack front-end focus and business logic. The business logic is something that can be centralized so that many front-ends can use this, while the back-ends can remain focused on their core business and process.
Implementing a mono repository in the right method significantly increases re-use potential and innovation time.
Fig: Sample representation of Mono Repository Architecture
- Store micro applications as a reusable snippet of code in a single repository – A single repository will clearly indicate dependencies for regression testing and focuses on those aspects that are really affected. This reduces cycle times significantly.
- Make APIs more findable and standardized to increase re-use potential- Maintain detailed documentation of APIs, its functionalities, and implementation choices – written in an easily understandable format. Create additional discovery-specific services to improve the findability of the API product.
- Handle API creation/evolution in a much smoother way with automation in CI/CD and testing – Keeping consistent API versioning, automated code quality checks, validating coding standards, automated UI & browser testing, and automated security checks are essential to smoothen the deployments. E.g., making “test & security” checks as part of the CI/CD pipeline improves quality and reduces testing effort, thereby decreasing time-to-market.
Benefits achieved by a leading DSP In Europe by implementing the digital enablement layer elaborated in this article
- Improved NPS by 3X while ensuring operational excellence.
- Increased re-use potential and innovation time. Implementing mono repository in the right approach provided 50% re-use potential for the development of the 2nd portal and onwards. With multiple brands/segments/user groups, re-use potential increased up to 70%.
- Boosted annual channel portal revenue by 50% and reduced time to market by 35%.
By Derrek Schutman
Solution Architect, Prodapt Consulting
Derrek Schutman has broad experience in Telecommunications and has designed End-to-End solutions for various product lines and segments. His inputs are most valuable in implementing design patterns, API layering & demarcation and proposing a phased approach for larger transformation programs. He has led various End-to-End implementations as Enterprise – and Solution Architect, focussing on the strategic goals balanced with short-term value.
Derrek is an enterprise architect – consulting at Prodapt, a two-decade-old consulting & managed services provider singularly focused on the Technology, Media, & Telecommunications (TMT) industry that helps clients transform their IT, products, operations, and networks to meet their strategic objectives. Prodapt’s business consultants enable DSPs on their transformation journey at several layers, including cloud, customer experience, business outcome focused initiatives, CapEx, and OpEx optimization programs.