There’s an interesting thing with off-the-shelf OSS solutions that are subsequently highly customised by the buyer. I call it the trickle-down effect.
By nature, commercial-off-the-shelf (COTS) solutions tend to be designed to cope with as many variants as their designers can imagine. They’re designed to be inclusive in nature.
But customised COTS solutions tend to narrow down that field of view, adding specific actions, filters, etc to make workflows more efficient, reports more relevant, etc. Exclusive in nature.
The unintended result of being exclusive is the trickle-down effect. If you exclude / filter things out, chances are you’ll have to continually update those customisations. For example, if you’re filtering on a certain device type, but that device type is superseded, then you’ll have to change all of the filters, as well as anything downstream of that filter.
The trickle-down effect can be insidious, turning a nice open COTS solution into a beast that needs constant attention to cope with the most minor of operational changes. The more customisations made, the more gnarly the beast tends to be.
In our “chasm” series of articles, we’ve talked about the gap that exists between OSS buyers (eg carriers or network operators) and OSS sellers (eg
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
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.
