The telecommunications industry is one of those industries which is an ever moving target. As technology to communicate evolves, so does the requirements upon the applications that were built to support them.
Emersion is a innovative company that strives to constantly adapt to change, and their architecture that is in place is designed to do exactly that.
But what happens when the functions and algorithms, functions and logic change far enough that existing systems designed to, for example, rate calls – no longer work as efficiently as they did before because they are being made to work in different ways? Everything slows down and scale can become a problem.
This isn’t entirely what happened in this scenario, as it was more as rating become simpler the additional logic in place to deal with antquated rating scenarios was simply unnecessary.
Having deep experience in Telecommunications rating for well over a decade, Asmorphic was weill positioned to analyse the rating infrastructure and make big structural changes in how the process worked, without sacrificing any functionality. This resulted in at least double the speed improvement in complex rating scenarios, but also meant simpler rating, which did not require the overhead of the rating scenarios of ‘yester-year’ – were able to be processed more quickly heading closer to real time outcomes.
The Issue
- Bottlenecked Due to Flexibility: Rating of calls, events and data sessions was becoming delayed because all records were being funnelled through a very complex set of functions to deal with a massive amount of flexibility that was simply unused.
Ensuring Exception Management: One of the unknowns was making sure that by bringing some of the simpler rating logic forward in the processing lifecycle – would there be an impact on the ability to manage exceptions, for example where Emersion’s customers had not properly configured their rate cards?
Visibility: All the monitoring and tracking systems had their focus primarily on the later part of the rating exercise. Would it now be less possible to monitor and track the backlog of usage records for the Operations team to manage?
Functionality Retention: The change was going to require some drastic changes to the usage allocation and rating framework. Emersion prides itself on the sheer amount of flexibility it has for rating. Would this be at risk?
Our Goals
- Speed: Most importantly was speed – as the business grows and more usage requirements come into play – Emersion must keep up with rating at all times. This isn’t just because Emersion does not want to fall behind and end up with backlog, there is literally regulations that require end users to be informed of their usage as soon as it exceeds certain limits.
Functionality: No functionality can be lost during the transformation. There are multiple ways users are provided usage ‘allocations’, there are Bolt-Ons, Features and complex rating scenarios that should not have functionality removed.
Full Reconciliation: One of Emersions key value-additions is the ability to know where any usage or service and equipment record goes. If you were to review other billing and rating systems, you will find its very easy for usage records to fall through the cracks. It was an imperative that this philosophy was maintained and that every usage record could be accounted for, whether it was correctly rated, or whether it was quarantined for any reason.
Scale: The solution had to scale. The rating procedure had previously been limited to its ability to work in a multi-threaded capacity. It had kept up to this point, but given the regular growth of the customer base, this would soon become an untenable solution. The aim here is to allow the rating system to turn into a rating fleet. This would be achieved by reviewing both the system scale but also the process scale and breaking the rating system into separate steps.
Our Solution
- Framework Only Approach: Asmorphic sought to only work on the core framework that holds the rating system together. Much like other projects Asmorphic takes on board, if it is possible to only adapt a slice of the infrastructure, and leave other important assets untouched in their production ready state, we will. In this case, the entire ‘Rating’ component – the logic that manages the call and event rating, the included value, the Bolt-ons etc. was left completely untouched.
- Workload Shift: Asmorphic identified there was essentially two types of usage, ‘simple’ and ‘complex’. Simple being your run of the mill ‘$x per y seconds billed in z seconds’ and complex which introduces ‘included value’, ‘stepped rating’ and all sorts of other very useful, but not heavily used methods of innovative rating solutions.
The ‘simple’ rating would be moved to an early part of the rating process, where it is discovering who is responsible for the usage records. Rating of these records could happen at the same time using heavily cached rating information, ensuring lightning performance.
Anything that fell outside this scope or was quarantined due to rating issues, would be dealt with further down the pipeline.
Performance Testing: Once the architectural changes were made and run through Asmorphic’s strict QA procedures, further benchmarking was performed to observe the improvement. There was at least a 200% improvement using the same resources from before the changes were made. By introducing additional nodes further significant improvesment were able to be observed and demonstrated to the Emersion architecture team.
Forced Failure Testing: To make sure all exceptions were being managed, part of our solution (or more post development demonstrations) – was to purposely create inconsistent data scenarios throughout the rating configurations, the usage records, the service configuration, basically anywhere where there is a chance of usage failure.
This process gave Emersion the comfort that their existing procedures, and their existing staff would not have to experience large amounts of change to adapt to the new implementations. Saving on training and education by not upsetting the apple cart saves money!Data Reconciliation: Part of the QA process was also to demonstrate, mostly manually, that the usage records that were brought into the platfrom from several carriers were able to be reconciled both from a usage count perspective, but also from a cost of goods input and output view.
