“A guarantee in this life: Change! Flexibility is better than predictability!”
There are two distinctly differing views regarding customisation of your OSS:
- A specifically customised solution will deliver more efficient processing
- A specifically customised solution allows no room for flexibility
Which solution would you seek to deliver and why?
My first OctopOSS was by far my most challenging. I was contracted to a vendor that was tasked with delivering an OSS in a country that had recently deregulated their telecommunications industry. Our customer, the first new entrant into the fixed-line market was finding it almost impossible to pry experienced engineers away from the incumbent so their OSS team consisted of a mathematician, an automotive engineer, an architect, etc and no telecommunications experience.
We were delivering a software platform that was powerful in its flexibility and elegant in its simple core data structures. We found new ways of modelling ATM, DWDM, ADSL, wireless technologies, VPNs and other topologies into a platform that was originally designed for transmission (SDH/PDH) and point-to-point links, with minimal change requests (CRs).
To overcome the shortage of telco experience within the customer’s team, they insisted that we customise their solution to deliver flow-through provisioning from the point of customer data entry. This was achieved but only after a huge number of refinements and CRs. Turning on a new customer service was incredibly simple for the OSS team as they only had to enter the customer order details and the type of service without needing to consider any network design implications.
Shortly after delivering the heavily refined OSS solution, the customer’s network equipment vendor made one tiny little change to circumvent major outages on their Broadband Service Node (BSN) and without informing the OSS team. By changing their VP-based ATM network to a VC-based topology, it brought the whole OSS flow-through provisioning engine undone.
The uncustomised solution would’ve taken this network change in it’s stride with only some minor data re-modelling and cleansing, but the customised solution was rendered inoperable.
I would always recommend to maintain an open, flexible model that can cope with the continual evolution of a CSP’s network and systems. But I also espouse automations that make an operator’s job more efficient.
When considering the dilemma posed at the start of this post, which path would you take?