There’s this phrase that just keeps ringing in my head when I see OSS and BSS in action – “Made by Engineers for Engineers.”
This was certainly a badge of honour. If the people who built OSS tools had network engineering experience, then there was a great likelihood that they were building solutions to solve real-world problems. Early OSS builders were scratching their own itch in many cases.
These early OSS solutions were engineering panels, where every metric that mattered was on the console. It was a bit like a pilot’s cockpit. If you were a highly trained network pilot, you knew exactly which instrument cluster to look at when problems arose. Each instrument cluster was precisely designed to provide maximum information from which the engineer could make an informed diagnosis and respond accordingly.
Early OSS reminded me of the days when I used to do fibre network testing with OTDRs like the one below:
They were really useful tools… if you knew how to drive them.
Just like the Test & Measurement industry, the OSS industry is undergoing a drastic change in terms of the user interfaces (UI) on the tools we use. Many users no longer want tools that provide lots of information that facilitates expert diagnosis. As discussed in a recent article, technical “apprenticeship” roles are diminishing, resulting in a skills gap of people able to interpret and diagnose complex problems from engineering panels. Even where expert diagnosis is required, rectification windows are shrinking, with operators expected to resolve issues ever-faster.
The preference is for the tools to not even just quickly identify the source of the problem / issue. Instead, the preference now is for the tools to recommend exactly what steps are required to fix it.
Taking it a step further, we’ve now even come to expect our tools to automatically resolve the problem without even bothering us. This is the prime objective of ZTA (Zero Touch Assurance), Autonomous Networks, SON (Self Organising Networks) and similar.
It’s no longer a case of these tools being designed by engineers for engineers. Instead of being designed for a human user interface, they need to be designed for a machine interface with occasional reporting to, or cross-checking by, a human.
If your OSS GUI resembles the OTDR pictured above in any way, and many still do, then it’s likely in need of a UI/UX/CX audit and potential UI overhaul. OSS have always been built as efficiency engines. This starts with the UI/UX.
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
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.
