The Secret to Effective Network Management

Like a lot of you, I've made a career out of getting supposedly easy-to-use technology to work. But breaking my head over a router misconfiguration or a VPN that won't connect isn't what bothers me. What bothers me are the engineers who just don't get what really matters about our work: helping users solve their business problems.

Whether we're talking about external customers who directly pay our salary or internal customers who indirectly pay our salary, customers don't hire us to implement VPNs or light up fiber or install VoIP systems. Customers pay us to solve problems. They couldn't care less if we pinged stuff all day long. At the end of the day, all they want to know is, does the application work? We do them a gross disservice when we walk away with things working from our perspective, without first checking to see if things work from their perspective. Yet I see this happen all the time.

DON'T LOSE THE PATIENT

A couple of years ago, I received a call to troubleshoot a critical health care application at one of our customer's sites. Apparently, this application failed to work properly after the underlying frame relay network was replaced with an Internet-based VPN. I planned to go onsite to fix the problem, but when the engineer of record heard this, he became irate. "It pings fine," he insisted, not quite using colorful language, but obviously upset that his professional acumen was being called into question. He just couldn't get over why I would even bother going to the site. After all, the site answered to a ping, so in his opinion clearly all was well.

Upon arriving at the site, I could see the problem. The VPN was up so ping did work, but the host-level configuration hadn't been completed. In other words, the operation--changing over to a cheaper transport--was a success, but the patient--our application--died. PLANNING IS CRITICAL

How do you avoid this within your IT organization? The answer isn't easy. Even if network engineers and technicians accept that projects aren't complete until the customer says so, logistical hurdles remain.

For instance, what if the customer isn't available for testing? What if the technician lacks a knowledgeable customer to test the remote application? What if the problem is capacity-related or otherwise intermittent and therefore hard to repeat? What if the host running the application isn't available to network engineers?

It all boils down to creating an effective game plan and escalation procedure. If your technicians lack the knowledge to test an application, then hire experts who can teach them. If a knowledgeable customer isn't available to run the application or a remote host is physically inaccessible, deploy a remote control agent with the application so that a local operator can troubleshoot the problem. Of course, it doesn't do any good to close the gate after the cows are out, so these issues must be worked out prior to the network engineering work. The problems may be countless, but so are the solutions if you plan ahead.

This might seem like adding a lot of new work, but remember, it's not the network or even the application that matters. It's how the users put all those pieces to work. Whether it's public safety, health care, military work, or financial information technology, the fact is that technology users with bad or inaccessible information aren't going to be able to help their customers, and in the end helping those customers is what really matters.Jonathan Feldman is director of IT services for the city of Asheville, NC. Previously, he was an IT management and security consultant serving the military, financial, and health care markets.

Send comments to [email protected].