Where does Client Server technology fit into your data processing picture? Well, the answer most likely depends on your own personal view of what the term "client server" means. While the global definition of client server seems easy, the implementation of the term varies all over the map.
Generally, the idea of client/server is a cooperative set of processes where one side is responsible for work done on a resource and the other is the keeper of the resource. To understand why this makes for greater efficiency, lets look at a common non-computer example. Everyone has been to a McDonald's for a hamburger. Consider what would occur if every customer had to go to the back and cook their own food, pour their own drink, etc. Chaos would reign as people got in each others way and the throughput of the system (in this case, hamburgers per hour) would fall dramatically. Instead, they developed a simple and highly efficient client server model with a hamburger server, a fry server, a drink server, etc.
The expected computer model usually involves a local area network connecting a large number of PC based clients. These PCs are responsible for the customer interface (the GUI) and a central computer working as a database repository becomes the server, but many other physical and logical models could make sense and still be called a client server system. Dick Pick, described as a "software industry maverick" by Client Server Computing magazine, was quoted in their August 94 issue as saying "It still seems like, in client/server, the clients aren't doing much more than dumb terminals.", but this ignores some very significant developments in PC technology in the last several years.
Some of the confusion stems from some very different viewpoints on client server depending on your background as a main-frame user or a PC user. If you are coming at the problem from the high end of the market, your problem is generally structured as a "divide and conquer" scenario. How do you support larger and larger numbers of users on a large corporate computer? Because large terminal counts present significant character I/O loads to the system and even simple edit rule data validations can be CPU intensive, the hope for client server is to off load the mainframe by driving more and more of this simple human interface workload down to the server. In a most simplistic view, this could be seen as an attempt at "making dumb terminals a little smarter".
The opposite view is held by people approaching the issue from the PC end of the market. These people have always had a fully functional computer on their desktop that is doubling in power every 12 months. These machines are great for their intended single user purposes such as word processing, spread sheets and engineering work stations. They can often operate for hours or even days without any outside data. When they do need to exchange data, it becomes much easier to share it over a network rather than putting the files on a floppy and running down the hall. If the data frequently needs to be shared by several machines, administrative issues quickly make it much easier to put the data on one system a let everyone get the most current copy from that machine, now called a data server. This view of the problem can be summarized as a "consolidate and gain strength" approach.
The success of client server applications in the business world is heavily dependent on the workload partitioning problem. In general, the more the application looks like it runs on the PC and infrequently requests data from the server and the less the LAN traffic looks like serial line traffic to a dumb terminal, the more benefits you can expect to get from client server architectures. Unfortunately, its pretty easy to partition the classic PC type applications to do this and considerably harder to effectively partition the typical business on-line database applications.
If you are researching whether your business could benefit from client server technology, the first step is to look at your possible options for application partitioning. Some systems like airline reservations are very hard to partition well. Others partition into department servers along application subsystems or geographical lines. This type of partitioning is usually fairly easy to do in large business systems and allows greater performance by having more than one computer while having limited data interchange for accounting consolidations. This is not classic client server, but it does reduce the number of terminals per system and can still use your "dumb terminals" for data entry.
To really benefit from client server, you need to be able to partition your applications so that substantial work occurs on a PC terminal. In most situations this will require a fresh look at the application design and considerable energy, not to mention some new programming tools and techniques. Fortunately, you shouldn't have to tackle this problem as an "all or nothing" situation. It is generally possible to mix the two approaches in the same corporate MIS structure. While each situation will be somewhat different, you can start by looking at the areas that can be cut out of the corporate machine and give to PCs.
For example, for many businesses the word-processing portion of the workload is substantial. Leaving the data sit in UNIX or Pick database for sharing and backup purposes, but having PCs access it for word processing is easily accomplished on several Pick machines today. The same is true for software development source editing and data manipulation in spreadsheets. Pushing a summary data file down to UNIX or a PC server might allow considerable amounts of your reporting loads to be done on other machines. In many cases these simple types of off loads can improve personal productivity as well as free substantial resources on your primary computer.
As you begin to think along these lines you will probably gain new insights into your application and possible alternate ways to view and address your data. Focus on where the PC type user interfaces would most benefit your shop and then work on how to get the data down to them. Evolution not revolution is generally the key to successful MIS changes. You will surprise yourself and your management with how easily some highly visible and profitable changes might be integrated with your current system.