A third alternative is to take the thin-client route with Windows NT Terminal Server or a Citrix WinFrame/MetaFrame solution. The fat clients run in multiuser mode off the NT server and are remotely displayed over the network on PCs or thin clients. It isn't easy to get this kind of solution to scale and you'll take a small performance hit, but it will reduce overall management costs and it's a great way to go if you support mobile clients.

· Develop a workable server strategy. Standardizing your back-end systems environment is one of the toughest issues to come to grips with. The obvious approach is to move everything--from file and print services to databases to messaging--onto NT. Many sites have adopted this strategy. Unfortunately, there's a very low probability of achieving satisfaction taking this route. NT's directory is antiquated, the OS itself is reliably unreliable, and it doesn't scale. Aside from those limitations, it's a no-brainer, right?

So, what are the alternatives? IBM's AIX or Sun's Solaris can surely give you the scalability and reliability, but the directory, file, print and messaging offerings are more limited. That's not to say you can't make it work, but you may find yourself outside the mainstream. Throw NetWare into the mix and you gain a little more flexibility and much better performance and scalability, but the integration isn't as smooth as it needs to be and overall support costs rise.

Supporting all three and figuring out a way to tie everything together is probably the best of a number of suboptimal alternatives. It's better to bite the bullet early and build the appropriate support infrastructure, which means hiring the various OS experts and figuring out how to get them to work together. Again, it's easier said than done.

· Develop an aggressive training plan. The wisest decision you can make is to invest in training for IT staff and users. And though good training costs money, your bigger obstacle may lie in convincing people to carve time out of their busy schedules to participate. But don't take no for an answer. Training helps ease the anxiety associated with the implementation of new systems and sends a clear message that you are committed to your staff.

· Invest in desktop resources. Departments will inevitably look at a client/server migration as a way to enhance desktop computing environments, particularly if it's a central mandate for new systems and procurement of desktop computers falls within departmental budgets. It is very tempting for IT staff to see this ploy for what it is--a way to cost-shift desktop acquisition to another budget. After all, they might argue, the departmental staff would need to purchase upgraded machines to run other desktop applications even in the absence of any major client/server implementation project.

But this perspective misses a key point. The IT organization is often guilty of shifting costs itself; it makes extraordinary demands on departmental staff's time as part of the implementation process, particularly when implementing packaged applications rather than ones developed in-house. Existing procedures, often developed and refined to a high level of efficiency, must be changed in order to adapt work in a way that matches the new systems. While it's not unreasonable to insist that departmental managers see the big picture, greasing the skids a little with some centrally funded desktop hardware may help shape a more positive perspective.

· Develop both central and distributed support infrastructures. Just as training is critical to the success of a client/server project implementation, so is direct support. An efficiently administered centralized helpdesk is one component of the support equation, but it's seldom enough. Most knowledge workers will need focused, one-on-one attention as they adapt to the new environment. If not, they will almost surely waste lots of time figuring things out on their own or turning to equally frustrated colleagues for assistance.

New systems require new support structures, and the closer they are to the end user, the better. Ideally, the departmental staff are part of a virtual team that leverages the combined efforts of central IT and departmental computing and network administrators.

· Implement a workable security model. Client/server systems, particularly those based on open standards, introduce a range of new risks within today's Internet-connected organization. Most organizations recognize the importance of a firewall, but the tendency is to oversimplify the problem. Even the most secure firewall will not produce a secure environment if staff connect dial-up modems to their PCs to access applications from home using remote-control applications such as pcANYWHERE. And while the knee-jerk reaction of security administrators may be to prohibit the attachment of modems to staff computers, this policy often ignores a real need for remote access to business applications. The implementation of a secure remote-access facility using VPN technology may be a viable solution, but implementing such a system is often quite complex.

No doubt there are other lessons to be learned from the early pioneers of large-scale client/server conversion. Please send your own ideas and observations my way.

Send your comments on this column to Dave Molta at dmolta@nwc.com.