Nobody wants to be on the short end of the priority stick, but early implementers have learned some tricks for dealing with delicate policy debates.
Jim Barry, chief information officer of Insurance Holdings of America in Beverly, Mass., has a tip for IT managers planning to implement policy-based network management: Bring users into the decision-making process or expect trouble. About a year-and-a-half ago, Barry's IT group reconfigured Microsoft Windows NT domains to prevent some of the Web-based insurance firm's workers from accessing sensitive material on certain servers. However, the group neglected to tell users about the change before it happened, and employees were understandably incensed. "Although the changes made complete sense to me technically, I learned my lesson," Barry says. "Now, whenever I implement a new policy, I indicate my reasoning and get feedback from managers first. Then it's a fairly smooth process." But as Barry knows, sometimes end users just won't like the news no matter how far in advance it's delivered. Such conflicts are likely to become all too common as policy-based network management takes root in IT shops across the country. Policy-based management systems let administrators control network usage by allocating and prioritizing resources for different applications, workgroups and users. Naturally, all this power has its price. The more complex and sophisticated the policy, the more complicated and politically sensitive it is to determine who gets what resources and under what conditions. Consider this your guide to diplomatic negotiation of network management policies.Lead from strength
IT managers and analysts agree the crucial first step is to get support from upper management, not only at the outset but also during the enforcement phase. "Enforcement from the network engineering groups won't fly because business areas are going to whine and complain that network engineers don't understand business," says Jeff Pandolfo, a senior analyst at Gartner Group, a consultancy in Stamford, Conn. Invite management into meetings early in the game, as Compaq's IT group did when it began planning policy-based management about two years ago, says Gary Davis, manager of global network planning and design for Compaq in Houston. Compaq implemented weighted fair queuing (WFQ) on Cisco routers. WFQ allocates resources by demand and weight, which is essentially a prioritization scheme for factors such as time sensitivity and business importance. The next step for Compaq's IT group is to deploy a directory to assign priorities down to user and application levels, and by time of day and location. The CIO's involvement in Compaq's policy-based management is important because the vendor's bandwidth prioritization policies affect its employees around the world, Davis says. Upper management also is more likely to back implementers if there's a clear return on investment case to be made - specifically, if policies will guarantee adequate bandwidth to business-critical applications and projects.Get users involved
Even when they have the blessing of top management, IT implementers should be careful not to shove policies down users' throats. It's much better to invite comments and, ideally, win the blessing of key user groups and projects in advance. For example, Insurance Holdings' IT staff worked with the firm's call center agents to create new policies guaranteeing adequate bandwidth for critical HTTP, voice and data applications. "We listened rather than dictated, and built our model around their needs," Barry says. Feedback also is welcome at Widener University, says Gary Habermann, director of technical resources for the school in Chester, Pa. Habermann has already begun implementing 3Com's Transcend Policy Server and Transcend Policy Manager and hopes to test them with Novell Directory Services soon. 3Com and Novell have promised to integrate their products by the end of the quarter. When Habermann begins to set policies, he will include representatives from the academic, administrative and student computing areas.Have a plan in hand
Opening up the policy definition process to users can be a risky venture, however, because someone is bound to get upset. Executives accustomed to preferential treatment may lean on IT to give them more bandwidth, says Gartner's Pandolfo. And battling interest groups can waste everybody's time. "Nobody is going to volunteer to be lower priority," Pandolfo says. "It's like kids on a playground, you have a lot of little fiefdoms, and nobody makes room voluntarily on the jungle gym." To avoid lengthy debate and escalating conflict, some implementers are defining the basic policy framework first, then presenting it to a broader group for input and approval or, at least, begrudging acceptance. The better handle you have on underlying business, application and network realities, the more effective your bandwidth allocation policies will be. First, baseline the network. Inventory users, systems, services and applications. Analyze how the elements interact, and pinpoint potential candidates for policies, such as areas of congestion or escalating activity. Next, prioritize applications, projects and users to determine how much bandwidth to give each when there's not enough to go around. Decide which applications should only be allowed on the network during off hours - or, as is often the case with games such as Doom, not allowed to tie up bandwidth at all. Widener is beginning to iron out which of the school's applications are business-critical. "What's sticky is defining what's just business-sensitive; stuff like e-mail needs to get done, but only when the business-critical stuff is finished," Habermann says. After you've made these choices, the next step is to figure out the minimum amount of bandwidth applications need to function.Be firm but flexible
Of course, not all prioritization policy decisions are straightforward or unarguable. There will always be some gray areas in which resolutions are difficult, and users will challenge whatever decision you make. An increasingly popular strategy for minimizing arguments is to give users as much bandwidth as they want as long as they're willing to pay for it (see story, below). Of course, users need to know how much bandwidth they want or are already getting. Just ask Jimmie Rodgers, director of business development for XS Technologies, a systems integrator and ISP in Alexandria, La. The company uses Xedia's Access.100 bandwidth manager to allocate bandwidth to corporations that collocate their Web servers on the ISP's site. XS' collocating customers choose how much bandwidth to devote to their Web servers, from 56K bit/sec and up. Before XS bought the Access.100 router, however, these customers often got a faster link than they were actually paying for, Rodgers says. "We were just starting out and had a lot of excess bandwidth," he says. When the ISP recently began using the Access.100 to parcel out bandwidth more precisely, many users noticed a big drop in throughput. "They complained they weren't getting 56K bit/sec anymore," Rodgers says. "We had to explain that, on the contrary, that's exactly what they were getting." Engineers need to build some flexibility into bandwidth allocation policies above and beyond what service-level agreements (SLA) define. XS allows its customers to burst on a regular basis. As long as they don't gobble up brief spurts of extra bandwidth more than 60% of the time, the customers don't pay extra. When a corporate customer regularly exceeds its SLA, XS suggests that it might be time to renegotiate the contract. This bursting option is important to the future plans of one XS customer, the Trump conglomerate. Business residents at Trump Towers in New York, for example, will want the ability to grab extra bandwidth from time to time without having to renegotiate their SLAs. Bandwidth allocation flexibility will also be a key attribute of the Internet access services that Trump New Media plans to offer to business customers nationwide, says Harry Geruldsen, vice president of purchasing for Trump New Media. "We want to provide bandwidth on demand and commercial network applications to differentiate ourselves," he says.Expect change
Another reason for instituting flexible policies is that networks are always in flux. Usage patterns and network configurations change, new applications come on line and old ones fall out of use. The bandwidth you use today might be too much or too little in the future. Make sure to monitor the network on an ongoing basis to determine how bandwidth is being used. Be sure to build formal mechanisms for change into your policy-based management infrastructure. You also may need to act as a custodian for older applications, determining when an application's usefulness has degraded enough to downgrade its priority rating, Gartner's Pandolfo says. No group is going to come forward and ask you to drop the priority for an infrequently used application, he says. But don't make policy change decisions alone, the implementers advise. "There has to be a review process," says Widener's Habermann. "I'm leaning toward a quarterly meeting of the same committee that set the policies." The trouble with a formal decision-making body, particularly one comprising high-echelon members, is that it can't always meet at the drop of a hat. "There has to be a temporary override process so that if something comes up today, the decision to change a policy can be made tomorrow," Habermann notes. "Perhaps a small group of people can make decisions, particularly in the summer when half the faculty is away." Widener recently had a high-voltage line burn up, leaving a building without power for three days and a group of 50 people suddenly a few days behind schedule trying to prepare for arriving students. "For about two weeks, those people needed to be guaranteed the computing resources they needed to catch up," Habermann says. "They couldn't wait for a formal process to give their applications priority."Maintain an open-door policy
Formal or informal, committees share the drawback of involving only a limited number of people who usually hold senior positions. IT managers say they still feel a need to elicit feedback from the end users on an ongoing basis. It's a good way to nip user dissatisfaction in the bud before it becomes a full-scale revolt. Insurance Holdings' Barry, for example, makes it a point each month to visit the 28 business unit managers just below his level to get their feedback on how current policies are working. "Our goal is to get a favorable response at least 98.7% of the time," he says. "I make rounds like a doctor. Sometimes it's just, 'Hey, how's it going?' Sometimes it's a long visit."RELATED LINKS
You get what you pay for
Horwitt is a freelance writer and consultant in Waban, Mass. She can be reached at EHorwitt@ compuserve.com.
