Solutions providers have learned that the money and opportunity in an infrastructure project is no longer in network deployment -- it's in the management services that follow. That's because these services provide recurring revenue and a chance for constant contact with customers, allowing development of further projects. One of those prime services is remote switch management -- the ability for providers to manage and monitor customer network devices from almost anywhere. But offering remote switch management services can be a challenge, demanding more skills and capabilities than some providers have.
Subhead: Technology 101
Remote switch management can vary widely, depending on client needs. In simplest terms, "management" may simply measure switch uptime or downtime. But it's more common to check the health and welfare of the switch, or even monitor switch performance over time. Management also involves backing up or restoring the current switch configuration so that new changes can be implemented in an orderly manner and unexpected changes -- or switch failures -- can be corrected.
"Remote switch management can take many flavors, from simple connectivity into the customer's network to complete automated management using a remote monitoring and management [RMM] solution," said Dave Sobel, CEO of Evolve Technologies, a solution provider headquartered in Fairfax, Va.
The technology involved in switch management is often the simplest consideration. It starts with providers establishing a secure connection that enables them to "see" each switch or other device under management. A virtual private network (VPN) is usually adequate for remote access.
Solution providers that provide health or performance monitoring services will also need reporting tools. Many switches and routers are already equipped with these tools, and they include native logging or reporting capabilities often based on Simple Network Management Protocol (SNMP). Commercial tools from vendors like NetIQ or Hewlett-Packard are widely used, though they can require servers to store and process SNMP traffic from the client's switch. Note that clients usually don't need to see comprehensive SNMP data (especially for successful daily operations), but concise reporting can help measure the effectiveness of your service and provide clients with insight into their environment. Help desk ticketing tools are the third technology set providers will need to implement, allowing providers to demonstrate their responsiveness to service events and calculate the "cost" of service so that management activities remain profitable.
Subhead: The devil is in the … process
Once the technology is in place, remote switch management should involve process or change control. Every activity should have a documented procedure associated with it, along with a mechanism for prioritization and escalation up through management levels.
"We treat each issue as we see it because we're proactively managing that device," said Steve Reese, director of solutions marketing at Nexus Information Systems, a solution provider located in Valencia, Calif. Reese points out that the data gleaned from management procedures can justify future upgrades and other client projects.
Solution providers will generally need a complete set of documentation for each client's network. For example, it may be impossible to log in and manage a switch without documentation of the switch's IP address, administrative password, and other details. Any changes must be noted carefully and added to the documentation.
Subhead: The right skill set
All the good technology in the world won't displace the need for skilled personnel.
There is no single skill set for remote switch management personnel. The skills will vary depending on the scope of services offered by the provider. As a minimum, the provider should have a strong knowledge of networking and traffic analysis (especially interpreting SNMP traffic). This often includes core CompTIA certifications such as A+, Net+ and Server+. In addition, personnel should receive vendor training around the switches being managed. Engineering personnel should be certified to a level appropriate for their responsibilities. For example, general technical staff may start off with CCNA, CCNP or CCVP, extend their repertoire with CCNP specialties, and then move to CCIE certifications.
Providers will also need to develop working relationships with product manufacturers. No matter how well trained a solution provider may be, contact with the manufacturer may be necessary to resolve serious or obscure issues at the client's site. Building this relationship with the manufacturer could mean maintaining a service contract with the vendor on devices under your management.
"[Providers will] require, as a part of their service offering for remote management, that the customer maintain a service contract," Reese said, noting that a service contract ensures the availability of technical support as well as a replacement parts network.
Solution providers in the management business should also have the skills (and the written authority) to manage other vendors at the client's site. The goal is to prevent other vendors from installing rogue equipment at the customer site and making unexpected changes that you would be expected to fix.
"We've seen rogue devices show up, from copy machines to time clocks," said Karl W. Palachuk, CEO of KPEnterprises Business Consulting Inc., a small business IT consulting firm located in Sacramento, Calif. "Vendors want to show up, pick an unused address, and start installing things."
A keen analytical sense is another skill worth honing. That means ignoring knee-jerk reactions or rushing under customer pressure to "fix the problem."
"You need to carefully consider what you know about the network, about this switch, and about this client," Palachuk said. "Don't get caught up in the stress of the moment when something goes wrong."
Remote management tasks typically don't require strong compliance skills, but it does help to have a working knowledge of the client's compliance obligations. Solution providers need to outline steps taken to protect compliance, or at least explain how remote switch management services are (or are not) affecting the current compliance posture. For some projects, solution providers may choose to partner with a compliance expert.
Subhead: Developing the remote switch management SLA
A solid service-level agreement (SLA) is critically important for solution providers in offering management services. It shapes the formal agreement between a solution provider and a client, setting client expectations and delineating the roles and responsibilities of both parties. Whether the solution provider has been in the management business for years or is just testing the waters, it must take time to clarify the most contentious issues in an SLA.
First up are response times by priority. For example, a top priority issue may carry a 15-minute, 24 x 7 response time; a secondary priority issue may promise a 60-minute, 24 x 7 response time; and a lesser priority issue may carry a four-hour, 8 x 5 response time. Response times are also routinely coupled with financial considerations that address what is recoverable for the client if the provider fails to meet the SLA. For example, if the provider meets the SLA 98% of the time or better, there may be no recoverable. Yet there may be some recoverable if the provider meets the SLA only 90% to 95% of the time, and that recoverable may increase as response percentage gets worse -- finally waiving the monthly fee at or below some cutoff point.
Also, solution providers must clarify SLA exceptions. Experts like Reese note that documenting SLA exceptions is crucial in the managed services business. Adding caveats can add significant protection for the provider. For example, the SLA may become null due to unauthorized changes to the switch or other network elements made by the client or other vendors.
"At the end of the day, you can't hold me accountable to an SLA when you've caused the damage," Reese said.
Finally, providers must clarify escalation paths that note when higher-level engineers or managers need to be notified or involved in the service issue. And both the solution provider and the client must be involved in this clarification. For example, the initial issue may be handled by the provider's help-desk technician, who will notify or work with the client's network administrator. The SLA should note how an issue moves up the ladder to engineers and field service staff on the provider's side, as well as administrators and corporate management on the client's side.