The video below, starring Martin Pittard, the Principal IT Architect at Vocus Group, provides a number of important OSS/BSS Transformation call-outs that we’ll dive into in this article.
Vocus has embarked on a journey to significantly overhaul its OSS/BSS stack and has heavily leveraged TM Forum’s Open API suite to do so. One of the primary objectives of the overhaul was to provide Vocus with business agility via its IT and digital assets.
As Martin indicates, all transformation journeys start with the customer, but there are a few other really interesting call-outs to make in relation to this slide below:
- The journey started with 6 legacy networks and 8 legacy BSS stacks. This is a common situation facing many telcos. Legacy / clutter has developed over the years. It results in what I refer to as The Chessboard Analogy, which precludes business agility. Without a significant transformation, this clutter constrains you to incremental modifications, which leads to a Strangulation of Feature Releases.
- Over 60,000 SKUs (Stock-keeping Units or distinct product offerings) and 100+ order characteristics is also sadly not unusual. The complexity ramifications of having this many SKUs is significant. I refer to it as The Colour Palette Analogy. The complexity is not just in IT systems, but also for customers and internal teams (eg sales, contact centre, operations, etc)
- No end-to-end view of inventory. AKA Information of all sorts, not just inventory, spread across many siloes. The ramifications of this are also many, but ultimately it impacts speed of insight (and possibly related SLA implications). Whether that’s via swivel-chairing between products, data scientists having to determine ways to join disparate (and possibly incompatible) data sets, data quality / consistency implications, manual workarounds, etc
- Manual Sales Processes and “Price on Availability” tend to also imply a lack of repeatability / consistency across sale (and other) processes. More repeatability means more precision, more room for continual improvement and more opportunity to automate and apply algorithmic actions (eg AI/ML-led self-healing). It’s the Mona Lisa of OSS. Or to quote Karl Popper, “Non-reproducible single occurrences are of no significance to science”… or OSS/BSS.
The Vocus transformation was built upon the following Architectural Principles:
Interestingly, Martin describes that Vocus has blended TM Forum SID and MEF data models in preparing its common data model, using standards of best-fit.
Now, this is the diagram that I most want to bring to your attention.
It shows how Vocus has leveraged TM Forum’s Open APIs across OSS/BSS functionalities / workflows in its stack. It shows actual Open API numbers (eg TMF620). You can find a table of all available Open APIs here including specifications, Swagger, Postman, etc resources.
A key to the business agility objective is making product offerings catalog-driven. Vocus’ broad list of product offerings are described as:
And underpinning the offerings are a hierarchical, catalog of building blocks:
Martin also raises the importance of tying operational processes / data-flows like telemetry, alarms, fault-fix, etc to the CFS entities, referring to it as, “Having a small set of tightly bounded reusable components.”
Martin then provides a helpful example to show flows between actual suppliers within their transformed stack, including the Open API reference number. In this case, he shows the CPQ (Configure, Price, Quote) process as part of the L2Q (Lead to Quote) process:
Note that the continuation of decomposition of actions is also described in the video, but not shown in this article.
And finally, Martin outlines the key learnings during the Vocus OSS/BSS transformation:
Final call-outs from Martin include:
- By following standards as much as possible means less unique tech-debt to maintain
- The dynamic architecture was the key to this transformation
- The Open APIs have varying levels of maturity and vendor support. These Open APIs are definitely a work in progress, with evolving contributions from TM Forum members
- Partnering with organisations that have experience with these technologies are important, but even more important is retaining design and architecture accountability within Vocus and similar carriers
- Careful consideration of whether data needed to be retained or orphaned when bringing across to the new EIM (Enterprise Information Model)
- There remains swivel-chair processes on some of the smaller-volume flows that didn’t warrant an API
- Federated customer, network and services inventory information will continue to inter-work with legacy networks
Martin has also been kind enough to be a guest on The Passionate About OSS Podcast (Episode 019), where he provides additional layers of discussion to this article.
And a final call-out from me. It’s a really detailed and generous sharing of information about the recent OSS/BSS Transformation by Vocus and Martin. It’s well worth taking a closer look and listen for anyone embarking on an OSS/BSS transformation.