A very clever colleague of mine, Keith, recently stated, “The failing of network engineers is that they don’t trust software (ie OSS, NMS, etc).”
Do you agree with Keith? Do you feel that most network engineers prefer to work from the command line rather than the GUI?
If so, why is that? Lack of confidence in tools based on past failures or functionality gaps? Speed / efficiency of task completion? Job security through having mastery of a more specialised interface? Other?
Is it true only within some domains (eg IP networks, network performance management, traffic engineering, etc) and not others? Enterprise networks or Service Provider networks?
If it is quite true, what do we have to do to regain their trust, and / or improve their experience of OSS tools?
I’d love to get your thoughts on this one.
Making your OSS easy to use isn’t about adding more “easyness” – it’s about subtracting what sucks. “To make your stuff “easier to use” you
During my first forays into OSS, over a period of 6+ years, I averaged 85 hours a week whilst being paid for a 40 hour
The call came in at 5:43am. “The routers are acting up again down at 1313 Packetloss Lane” the night supervisor whispered, as if afraid the
Telco appears to be an increasingly tough industry. Demand for connectivity continues to soar, yet profitability and differentiation are becoming ever more difficult to achieve.
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
In my experience by and large tools are trusted for monitoring however they are still viewed with suspicion for provisioning.
The two main bugbears in our organisation are:
1, Speed of the graphical tool – typically slower than CLI as it has to read in config, parse etc.
2, The feeling of lack of control – i.e. the tools can be creating config the engineer may not be aware of. Coupled with stability this is a real issue if the gui breaks and the engineers have to re-work on the CLI.
Great insights Matt
Easy to see when the NMS tools are behind a couple of minutes. Sometimes, even more. With smoothing, the NMS tools seem to give away the SLA window. This is especially critical when your in the middle of something in real time, trying to figure out whats wrong.
Some NMS systems only handle traps they know about or the ones that are considered actionable. Inherently, they filter out data that could make or break the diagnosis.
Some devices don’t respond to ICMP pings when things are under stress. (Go figure!) NMS wares vendors swear that this should never happen but their own myopia is at fault. If the only method of status is pings, you are kinda “rudimentary” or weak in your design and implementation.
Amazing how much junk is out there. It is easy to mask bad behavior in your app. Like missing whole IP address ranges in discovery. (especially when NMap catches them! And the developers seem to only want to work on new features.
A TON of marketing spinning and smoke ware. I see a bunch of spin jockeys call me up and try to tell me how their product is this or that and think that I’m wet behind the ears.
With everything going towards continuous delivery, ironic how you don’t see any unit test apparatus in the products. Even the new stuff. Asking for a Unit test harness is like asking for an Audi engine in a Chevy truck.
I also find it AMAZING how terms like Root Cause Analysis seemed to have been solved YEARS ago but somehow, it was only solved as a marketing check box.
Hi Dougie
Another great comment! Thanks!
I tend to agree with all of your observations.
The question becomes, “why haven’t they been implemented?”
It’s not like any of them can’t be resolved technically. Is the challenge too difficult or the benefit too small? Or is it the current mode of features outweighing efficiency (ie focus on delivering more features rather than improving the efficiency of the vital ones)?
I’m currently working with an organisation that “gets” your unit test harness. We’re currently developing and using it heavily for internal purposes because of the massive regression challenge of working for a customer that’s rapidly customising its best-of-breed OSS. But I can’t help but seeing it as a saleable feature for future customers.