I was lucky enough to get some time of a friend recently, a friend who’s running a machine-learning network assurance proof-of-concept (PoC).
He’s been really impressed with the results coming out of the PoC. However, one of the really interesting factors he’s been finding is how frequently BAU (business as usual) changes in the OSS data (eg changes in naming conventions, topologies, etc) would impact results. Little changes made by upstream systems effectively invalidated baselines identified by the machine-learning engines to key in on. Those little changes meant the engine had to re-baseline / re-learn to build back up to previous insight levels. Or to avoid invalidating the baseline, it would require re-normalising all of data prior to the identification of BAU changes.
That got me wondering whether DevOps (or any other high-change environment) might actually hinder our attempts to get machine-led assurance optimisation. But more to the point, does constant change (at all levels of a telco business) hold us back from reaching our aim of closed-loop / zero-touch assurance?
Just like the proverbial self-driving car, will we always need someone at the wheel of our OSS just in case a situation arises that the machines hasn’t seen before and/or can’t handle? How far into the future will it be before we have enough trust to take our hands off the OSS wheel and let the machines drive closed-loop processes without observation by us?
I know a guy. One of my great friends actually. We’ve known each other since kindergarten – back when we were five years old. He
Most OSS platforms monitor, but only the best ones take action. Is yours a thermometer or a thermostat? Does your OSS only report the temperature,
We love doing The Passionate About OSS Podcast, but it’s been a loooong time between episodes. Too long. We love the conversations, but the
After working with countless OSS product teams over the years, we’ve noticed one universal truth: they’re all overloaded by huge backlogs of feature requests. But
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.
4 Responses
I have a friend who recently left the IT business because he was fed up with constantly learning new languages and frameworks and tools to stay “relevant”. The problem also holds for humans.
So true Roland!
The proliferation of new “tools” across all facets of OSS (and IT) makes it really tough to stay relevant. But I also see this as an opportunity as well as a threat. The threat comes from not investing enough time in remaining relevant. The opportunity comes because if you dedicate the effort to your field of specialisation, yet are still battling hard to keep up, then what chance do the non-specialists have of keeping up (and therefore provide the chance to become your future customers)?
OSS will always be observed or ‘attended’ processes.
If it can be fully automated it probably won’t – perhaps shouldn’t – live in OSS.
Automation takes place at the network level, whether it’s relatively simple ‘intelligence’ in ISIS/OSPF route finding, or a more sophisticated SDN Controller managing route and flow.
OSS is operations *support*. OSS will increasingly relinquish control to the network. OSS should only be doing what the network can’t.
Of course, that’s not to say there isn’t a category of problem that OSS owns that can be automated/AI’ed/Machine Learning-ified. Let’s consider your SA example – Identifying and recovering from a fault, that should happen in the network. Analyzing historic data, predicting risks, and designing resilience to be applied to the network, that’s all OSS. But in all those cases, humans are involved to guide the discovery, evaluate options and project plan implementing the results.
That’s a really interesting perspective James, that “OSS is operations *support*. OSS will increasingly relinquish control to the network. OSS should only be doing what the network can’t.”
There are so many layers in what you’re saying and some alignment in thinking with this earlier post, https://passionateaboutoss.com/an-oss-automation-mind-flip/
I have an open mind about whether, “OSS will always be observed or ‘attended’ processes.” I wonder whether OSS will even exist if/when the tech develops far enough for us to completely take our hands off the OSS wheel… or whether as you say, the tech just does ever more of the support activities, leaving operators time to focus on higher value, less repetitive activities than the OSS can handle.