At Passionate About OSS, we’re lucky enough to count the utilities market as an important part of our client base. This probably puts us in a very small percentage of OSS exponents that work across OSS for telco and utilities.
Utilities have a number of interesting and unique nuances compared with other OSS markets. Starting at the top, the network is core business for a telco, whereas the comms network only supports the core business of other utilities.
Despite having vastly different functions, there are still many similarities between operational support tools at telcos and other utilities. Similarities include:
Anyway, enough of the preamble. I find it interesting to observe the tools used by the different utilities to prompt alternate ways of thinking about our OSS.
Last week I observed a tool called a Restoration Manager. It is used widely in the power industry to handle fault restoration on comms networks. It has little direct equivalent in comms network management.
Some ticket managers allow task templates to be developed and defined. Similarly, the Restoration Manager also retains restoration plans, which are sequences of responses, but it also goes further by:
The restoration plans could be made to tie in with DRP (Disaster Recovery Plans), CRB (Change Request Boards), outage window sequencing/management and even security incident response.
What are your thoughts? Would a Restoration Manager be useful for our OSS stack (ie solves an existing, unsolved problem) or do we already have suitable ways of solving / avoiding the outage problem?
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
One Response
I suppose the big difference between utilities (pipes, valves etc) and comms (fibre, switches and routers) is that the telco industry is heavily invested in resilient protocols. There’s a greater focus on building a comms network that will be able to leverage those protocols to respond effectively to a range of unexpected outages.
How effective this approach is, is probably up for debate, but I’d imagine a well invested and designed comms network’s response to an outage should be at least as good as a Restoration Manager response.
Or maybe I’m underestimating modern utility networks! Is there any equivalence of a protocol in utilities? Or is all the intelligence in it’s OSS layer?
All that said, there’s still a set of faults in networks that protocols cannot handle effectively (otherwise we’d never see a network outage IRL!), and I really like the idea of dedicated processes that don’t just manage the necessary network change but also look ahead at the same time to predict the outcome and determine whether it’s still the correct course of action. For any network fault that takes more than a few minutes to resolve, that approach adds a lot of value.