By Mike Lane and Robert O'Connor
Network World, 12/25/00

Permitting users to add software and devices to the network offers benefits and risks. Below are arguments for and against letting users have control. Read their arguments and then chime in with your thoughts.

Yes: Mike Lane, network engineer at Western Bank in Portland, Ore.
No: Robert O'Connor, network supervisor at Penn State University in University Park, Pa.
What do you think?

YES
While it may be extremely difficult for those wearing the IT hat to support users installing software on the network, that's the wrong perspective from which to view the question. If planned and implemented correctly, such a policy can work in an organized network.

The primary goal of your organization is not to have well-run systems. In most cases it is to make money, or maybe to provide information or a service. The IT department's purpose is to support and enable the company's primary function, including providing systems that help users do their jobs. However, what is good for the IT department - uniform, simple systems that are locked up tight - is not necessarily best for the company as a whole.

Workers always try to personalize their offices or cubes with photos, Dilbert cartoons, encouraging sayings and so on. This makes them more comfortable and increases productivity. Why should it be different with their systems? Goofy screen savers, stress-relieving games or software customized for their line of work make the office a better place to be, and happy workers are better workers. If your policies are too Orwellian, workers may even leave for friendlier pastures. It wouldn't be the deciding factor in a job move, but may tilt the scales the wrong way.

A second point is workers know much better than you do what software and applications they need. This is especially true in large, diverse organizations. You are not a CPA, lawyer, doctor or nuclear physicist - you know systems. The users know what functionality they need in their software. They probably know from word of mouth or professional literature which package is best.

I am not arguing for complete systems anarchy - that would be a disaster. However, letting users add software or devices to the network can work if you adhere to the following policies:

Do not let users add pirated software or software that could result in lawsuits.

Make users legally responsible for their own installations.

Have departments pay for the resources they use - disk space, server processing time and bandwidth.

Make it clear that IT doesn't support software it hasn't installed - IT agrees to keep the network up and servers running, not to fix some bug in a wacky piece of software.

Forbid system killers, hacker software or programs that compromise company or systems security.

This works best as a partnership. Encourage users to regard you as a resource. They know the best software, but you know best how to set it up.

You can also help them in the selection process by explaining which software will work best in your environment.

Lane is a network engineer at Western Bank in Portland, Ore. He can be reached at mlane@westernbank.com.

---

NO
Users should not be able to add software and devices to the network without the network supervisor's knowledge or approval. I suspect that some may disagree, so let's look at how my organization's network is set up.

My department supports the administrative computing functions of Penn State University. This includes administrative applications developers, an enterprise server and many midtier servers. Our goals are reliability, availability, performance and security.

Our network has been designed to help us achieve these objectives. First, the network is modularized as much as possible. The connections are distributed in such a way that the likelihood of a total network failure is minimized. In case of a failure, it is easy to swap in a spare switch for the connections affected.

Second, all the connections use static addresses with known devices residing on these addresses. We know what is being added to the network and when it is added. Abnormalities are easier to trace when recent changes to the network are known.

Finally, the various functions supported are segmented with nonrouting subnets. By isolating the subnets, we prevent one subnet from impacting the performance of another.

One subnet is dedicated to departmental users and developers;

another is the server subnet. This keeps undesirable protocols and traffic off the subnet supporting the production servers. A third subnet is for testing. The testing subnet lets us isolate new functions and servers so we can evaluate their impact on the production environments.

Performance is always an issue. To make sure users do not impact the servers, we've installed separate backbone connections.

Another consideration is security. Devices attached to the network pose a potential threat. Exposure to these threats comes in unexpected places. Most end users are unaware of how devices can be used for denial-of-service attacks or the ease with which the built-in security of some wireless devices can be circumvented.

The stability of the network segments is a major concern, due to the users we must support. On one subnet we have a large number of developers who cannot work without a functioning network. If a device were to be placed on their subnet that consumed an inordinate amount of bandwidth or caused a network outage, this would be an unhappy group. The server subnet must support 70,000 students. If these users cannot access the online student system, complaints come in quickly.

Letting users add software or devices without our knowledge would be an unacceptable risk. Mission-critical networks should be treated with the care they deserve. The cost of doing otherwise is just too high.

O'Connor is network supervisor at Penn State University in University Park, Pa. He can be reached at roconnor@psu.edu.