Avoiding Client-Server Disasters

By Paul Newcum, MS, Ph.D.

Know a good way to get heartburn? Install a client-server system! If you want to avoid this, consider the sound, "real world" thoughts from a client-server pro.

First, let's look at what causes most of the consternation and strife in first-time client-server projects. Client-servers take more time, more effort, more hardware, more software, and more training than are first estimated or eventually liked. Since organizations will still feed and maintain existing systems within the same time frame of moving to client-servers, there will be twice the work. Network connectivity upgrades and some increase in network support and client-server skilled people cannot be side-stepped since the client-server absolutely depends upon lively and strong services and support.

Secondly, a great deal of effort and unique programming is usually required to "pull off and clean up" legacy system data, and download it to the client-server so it can be accurately loaded into and concurrently maintained in its relational database. Consider the non-regular data that typically resides in legacy systems; this non-regular data must be physically re-structured "on the fly" by the offloading programs since generic client-server relational databases simply will "freak out" when presented with this unorganized, non-normalized, non-relational data. Organizations typically grossly underestimate the true work of doing this, as well as the extended computer operational hours needed to successfully accomplish this crushingly repetitive task -- since these databases must be refreshed on a weekly and even daily basis.

Thirdly, the "standard way" of programming and accessing any generic client-server database is "considerably non-standard" to a legacy-system oriented organization. It is often "very difficult" to accomplish the "same identical legacy-system business function" on a client-server system; clients/users often "just cannot accept or readily adapt" to this mind-shifting reality. If client-server programmers are "forced" to exactly emulate existing legacy-system business functions, plan on a good deal of client-server programming and long hours of debugging.

So how are client-server successes achieved? The key word is planning, planning, planning by the information technology staff. And for clients/users, the key word is communicate, communicate, communicate with the information technologists. Everyone from the top of the organization right down to the data entry folk must thoroughly understand and appreciate the shear impact and vast work that needs to be accomplished when moving to client-servers.

Avoid "absolutes." Don't pre-commit to a date certain when the client-server will "have to take over" the legacy system's functions.

A client-server success can be achieved with a "let's get our feet wet and let's staff up" to see what it will really take to do a real client-server project attitude. The chosen client-server project should be truly valuable to the organization, but it should NOT be a mission-critical project. There should be NO UNDUE pressure if the chosen project is late or poorly performing when initially started up. Client-server networks are VERY HARD to pre-tune, and therefore good performance cannot be implemented until AFTER the database is completely online and personnel begin to fully utilize client-server functions.

Almost everyone who tries a client-server implementation eventually realizes that a legacy hardware system is here to stay for good LONG time. It is a GREAT back-end data processor. Client-servers are GREAT people satisfiers and GREAT front-end processors. Recognize this. Plan for this. Activate this. Such a plan will assist your organization to spend its dollars well, and serve its market fruitfully.

Paul Newcum was featured at DCI's Engineering Solutions Conference: From the Desktop to the Internet.