Some got over the initial frustration by adopting a longer-term perspective. They recognized that in spite of the fact that they had been tricked into swallowing this candy that was bitter at the core, the pain associated wit h automating routine processes was something that would be felt sooner or later if they had any hopes of delivering quality services. Others delegated all responsibility to an already-busy subordinate who prayed that nothing would go wrong with the system.

Recognizing the error of my ways, I began searching for alternatives. Improvements in the scalability of server technology soon made it possible for a central computing organization to efficiently deliver LAN services to departments. We used to call them virtual LANs, a term that has since been co-opted by another segment of the industry. Unfortunately, despite the apparent management benefits of centralization, we couldn't shake either the image or the reality of the glass house. The standardization drive to deliver a low-cost, centrally managed service led to a lot of "sorry, but we can't do that" discussions with department managers. We simply weren't flexible enough t o meet peoples' needs, and the truth was that we just couldn't afford to change within our budget.

Share and Share Alike I eventually came to advocate a more federated model of network and systems management, one in which responsibilities are shared between central computing staff and distributed computing departmental support staff. Initially, our attempts to develop this model were met with resistance by department managers who couldn't afford a highly paid technical specialist and saw this as a cost-shifting ploy on our part. We responded by offering to share the cost for such staff by paying one-third of the specialist's salary. The appeal of a subsidy was simply too much for many managers to resist and the program expanded quickly, forcing us to adjust our own central IT staffing levels to free enough resources for those subsidies. We thought it a fair trade, since our contribution would carry with it a subtle pressure for distributed staff to maintain effective relations with the central I T organization. This would presumably diminish the ill effects that often accompany uncoordinated decentralization.

Having experienced the highs and lows of such a model for several years, I remain convinced that on balance, this model works. Departments are much more satisfied with service when they have their own departmental computing and network administrator (DCNA) to provide it. And the central organization is liberated from many of the challenges associated with supporting departmental computing. But beware the many obstacles to success. Let's look at the most common mistakes a central organization can make with this program. In my next column, I'll take the opposite perspective and discuss the ways in which DCNAs can play the role of saboteur.

· Proscribe fundamental changes to the network infrastructure without consultation. Although there are exceptions, most DCNAs will not have significant experience in the design or management of organizationwide infrastructure. Thus, it is tempting for the engineers and analysts in the central IT organization, diligent in their efforts to meet ever-increasing demand for performance and bandwidth, to make unilateral decisions that have significant impact on departmental staff, without adequate consultation. Example: The central IT organization decides to flatten its IP network address space, replacing routers with switches, but it badly underestimates the effort required by DCNAs to implement address changes.

· Assume that the central responsibility of departmental network administrators is user support. It's common for nontechnical departmental staff to place a very high value on the consultative support provided by a DCNA. Often, they don't understand or really care about the technical skills required to manage departmental systems, but they love the fact that there's someone to call when they can't print a report on the network laser printer. It's fairly common for central IT staff to view DCNAs as an extension of the central helpdesk--a per spective that infuriates many a DCNA.