Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON (Self Organising Networks), so it was a fascinating conversation about network automation and many other things. The discussions inevitably led to RAN data.
As much as I’m Passionate About OSS, the real love probably originates from the data that underpin OSS solutions. The first OSS I got to play with (which really was a combined OSS and BSS) had a consolidated database that included alarms, performance, inventory / topology, service orders, activation, field work management and much more. It also had rich diagramming tools for presenting those data sets.
But the thing I found most exciting was that by learning SQL (Structured Query Language) scripting, I could ask far more wide-ranging questions than I’d ever been able to before. It meant I was no longer constrained to just asking/answering the questions that had been baked into menus or reports on network management software or test equipment.
This aligns well with the “connecting seemingly unconnectable dots” that Steve Jobs made in his famous 2005 Stanford Commencement address.
“You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.”
This quote reflects Jobs’ belief that experiences or events that might not make sense at the time often come together in unexpected ways when viewed in hindsight. The same might be true of the data we collect and curate with our OSS.
I’ll take a wild guess by saying that 99% of data collected by OSS/BSS is never used. But that doesn’t necessarily mean it is useless. It’s only useless if we never take the time to look at the data and see how we might make connections that haven’t previously existed…..
Which leads me back to the RAN / SON engineering discussion. This talented carrier employee pointed out that he used to love it when he had SQL access to RAN analysis / log data. With it, there was almost no constraint on the questions he could ask. But over the years, his equipment vendors have removed SQL access and abstracted (ie locked down) access to tools and data. In doing so, it has increased his dependency on the equipment vendors to answer questions and have reduced overall transparency.
But this isn’t about “bashing” the vendors. Whilst vendor-dependence is seen as an ulterior motive, the vendor product managers are responding to a growing trend I’m seeing in network management and network testing alike. Network technicians no longer have the time or patience (or even the expertise in some cases??) to use the old techniques and tools that were designed by skilled Engineers for skilled Engineers.
Unlike the RAN expert hero of our story, many network techs today can’t or don’t want to look at endless streams of data, hundreds of graphs, or run countless tests + diagnoses.
They just want to know what the problem is and what they need to do next to fix it.
This changes the whole way we must design user interfaces (UI) on OSS and test equipment. In fact, this is why I see the opportunity for the world of test and diagnostics (T&D) to move away from the handheld testers, probes and “Engineering” interfaces to simpler “question and answer” front-ends that are underpinned by software and data-science (including AI/ML).
But what do you think? Can you also see a convergence of OSS and T&D in terms of network monitoring and management UIs? Do you wish you still had the SQL interfaces of the past or the question/answer/iterate interfaces of the future?
Either way, it still (probably) requires a level of passion and inquisitiveness to ask new questions. And as Steve suggested in his Harvard speech, this only comes from carefully collecting and connecting dots. You have to collect the dots before you can connect the dots… you just have to trust that the dots will somehow connect in your future.
Leave us a comment to tell us your stories about wrangling data to present great insights!!
One of the things I love about my job is all the vendor demos I get to see. Product demos are one of the four
Have you read the book, “The 4-hour work week” by Tim Ferris? It was one of those relatively rare books that inspired a complete mindset
Over the years, we’ve been involved in many OSS procurement events and have seen a variety of different pricing models proposed by vendors. Being software,
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
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.
