Customers want an application that has the features and ease of use that they need. System Administrators (SAs) want an application whose server is easy to manage. Traditionally either the customers or SAs have more ``power'' and make the decision in private, surprising the other with the decision. If the SAs make the decision the customers consider them fascists. If the customers make the decision it will no doubt be a package that is difficult to administer which will make it difficult to give excellent service to the customers.
There is a better way that strikes a balance that lets everyone win. We select protocols based on open standards and permit each ``side'' to select their own software. This decouples our client application selection process from our server platform selection process.
Customers are free to choose the software that best fits their own needs, biases, and even platform. We have a corporate standard client (software) that receives official support but many of our customers are happy self-supporting their own rogue selections. We can not force people to use software they don't like, so we must ``use the carrot, not the stick'' and draw customers to our recommended software with incentives of reliability and support.
We SAs can independently choose the server based on our needs for reliability, scalability, and manageability. We can now choose between competing server products rather than being locked into the (potentially difficult to manage) server software and platform required for a particular client application. In many cases we can even choose our hardware and software independently if a vendor supports multiple hardware platforms.
For comparison, the opposite strategy would be to let the customers select the application without the informed consent of the staff that would be running the servers. For example, a local (New Jersey) pharmaceutical company selected a particular proprietary e-mail package for their PC users after a long evaluation. Their selection was based on user interface and features with no concern for ease of server management, reliability, or scalability. The system turned out to be very unreliable when scaled to a large number of users. In particular, data corruption problems were frequent and result in having to send the e-mail database to the vendor through the Internet for de-mangling. The system also stores all messages from all users in a single large file which must be kept writable by anyone, which is a security nightmare. Because the package is not based on open protocols the system support staff can not seek out a competing vendor which would offer a better, more secure, reliable, server. Because of the lack of competition the vendor considers server manageability low priority and ignores the requests for server-related fixes and improvements.
The answer is to strike a balance by decoupling the client and server selections. Open protocols permit us to do this because we can select clients from one vendor and servers from another. These two vendors' products talk to each other because the protocol between them is created in an open forum and is publicly documented. Anyone could make a compatible client or server. Consumers can choose between any number of clients or servers. End-users can select from an array of clients, possibly even switching between different ones for different tasks. SAs gain similar advantages. Vendors of server software are forced to compete with each other on a level playing field [Fair]. If the current server software begins to lag behind the competition, SAs can opt to switch to an alternative vendor without forcing users to change clients. Vendors are more responsive to their customers when they know that their customers can leave them without significant pain.
Critics would say that the customers are the center of the universe and therefore their needs override any concerns of the IS staff. The IS staff should be able to learn any system that the customer selects. However, the reliability and scalability of the server is as much an issue to the customer as is a good user interface. Customers may not feel scalability is important, but they will understand that a mail system flooded by chain letters should not buckle and be down for a day as it is repaired. They might not be concerned by whether or not the IS staff will find it easy to manage the server. However, they will be frustrated if they have to wait a week for what seems to be a simple request, but is actually a major undertaking due to the way the server was designed. All of these ``secondary'' issues are important to the customer but usually only after a disaster has educated them the hard way. The SAs have a responsibility to present these concerns to the end-users in hope that they will be adopted as concerns of their own. To do this the SAs must partner with customers, use the customers language, not technical jargon and other techniques described in [Bashein].