Like it or not data drift is a fact most telecoms have to live with, as a matter of fact any enterprise serving customers in near real time is bound to suffer from a certain degree of data drift between its system gradually increasing over time. Missed requests, internal system failures, un-handled exceptions and data corruptions slowly chip away the enterprise’s reliability and resilience. Without a reference point to align all the systems with it is quite hard to re-align the systems and restore consistency.
In telecom classically the CRM was being used as the reference point, being the customer care facing system it was easy to validate it against the customer’s expectations and more importantly it had good “Managerial Visibility*”. However there are many drawbacks associated with using CRM as the data repository, For starters the CRM’s data model is convoluted with the customers data and products split across multiple tables with CRM database being optimised for fast data row based CURD operations it is not the most efficient when it comes to large data operations or random inquiries. Such operations would definitely impact the data base performance “full table scans” and CRM’s performance would suffer. which brings us to our second point the CRM solution is often what makes or breaks the customer’s experience, in most situations you can not afford to mess with its performance in order to achieve data alignment.
Acknowledging that need several solutions were introduced to provide a reliable reference point that can be used for the periodical realignment for instance IBM’s Master Data Management solution which is mainly used in banking and Oracle’s Unified Inventory Management which is designed specifically for telecom. When a repository is added to the stack it serves as a reference point which all the systems can be aligned with, even if it does not reflect the customer required/expected state. The rule is systems’ alignment has higher priority than customer’s expectations. This repository is used for both offline purposes such as alignment projects as well as online purposes such as reading customer current status to determine the logic flow.
Take this situation for instance, The customer requests and upgrade from one bundle to another, the request succeeds on Network but fails on Billing. From the customer’s perspective the request is fulfilled however revenue leakage happens because his billing account isn’t updated with the deal he should be on. Furthermore the customer satisfaction would be soon be lost because his subsequent orders will all fail due to the inconsistency issue that was created. It is actually better to realign the customer’s account by restoring him to his old bundle rather than retain his momentary satisfaction and allow him to enjoy the service while he can.
While designing new operations it is best practice to include the data repository in a resilient manner that reflects the final system status, usually upon receiving the success call backs from all the backends in order for it to serve as an E2E indicator of the process and allow operations to spot the inconsistencies. Placing it earlier in the flow may result in it contributing to the confusion of failed process since it’ll not provide any indication to the activities that took place after it. Needless to say whenever an inquiry is needed it should be made to the data repository system rather than relying on the existing data in the calling system or any other system for that matter.
To sum up without a resilient data repository a system’s stake will become unstable over timer as the data drift increases and the stack layers go out of sync, having a data repository and applying design best practices to always update it guarantees that there is a singular world view for all the impacted systems with any errors either being automatically fixed or at least highlighted for operations.