OSS Made by Engineers for Engineers

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.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.