The Hidden Costs of Client/Server

Unless your organization plans for client/server wisely, IT may be shocked at the expense.

Some analysts will tell you that the driving force behind client/server is saving lots of money by running applications on inexpensive servers and client workstations. However, this usually isn't true, and it isn't likely to be the case no matter how cheap microcomputers become. Why? Hardware is a relatively small part of the client/server price tag. Although client/server provides many bottom-line benefits, which I discuss later in this article, it is expensive and usually does not reduce the information technology budget. To gain a clearer idea of the cost of client/server, you must identify all of the operational and implementation costs involved. This article provides an approach to assessing client/server costs and benefits.

To establish a broad view, I've listed some of the key immediate and future cost elements of client/server. (See Table 1.) Some immediate costs include: server hardware, server operating system, server database engine, networking hardware and software, and networking installation. On the client side, you will need hardware, an operating system, and front-end tools. Some future costs include hardware and software upgrades, and application maintenance. You will need training for all of these elements. Do not underestimate the cost of developing a client/server pilot project. As a general rule of thumb, develop your best estimate of the cost of each phase of the pilot--and then double the number. It always takes longer and costs more than you think.

You must consider one key point at the outset: Compared to host-based environments, a much larger portion of the client/server budget goes to the acquisition, training, and ongoing support of personnel than to hardware and software purchases. As a rule of thumb, you can count on 70 percent of the client/server budget going to labor costs. Although analysts vary in their opinion, many say that mainframe labor costs come in at about 20 to 40 percent of total costs.

A surprising number of people think that once they get the right hardware and software products, their client/server implementations will fall into place without too much effort. This is perhaps the most misunderstood aspect of client/server technology, and it affects how people justify projects and draw up budgets. Client/server is labor-intensive. As an indication of how much effort and expense is required, consider the cost of upgrades alone: Moving 1200 users and their applications to the Windows 95 environment will arguably cost about two million dollars, much of which goes to labor expenses. (See Table 2.)

Organizations often do not take a careful look at what client/server implies in terms of investment. Instead, managers jump ahead, excited at the prospect of implementing inexpensive client/server applications on their LANs. After all, the LAN and at least some of the workstations are already installed. At first glance, it looks like all the company needs to do is to pick a pilot application, buy a relatively inexpensive, high-powered server and some application development tools, and start developing. For small workgroup-based client/server applications, this approach may work, but only up to a point.

For larger or more important applications, this "feet first" approach to cost estimation isn't adequate. In the discussion that follows, I point out several cost factors, but leave it to you to quantify the costs given your specific environment. You could call these "hidden costs"--not because they are kept secret deliberately, but because you may not anticipate them prior to implementation.

Discovering Hidden Costs

Systems management is also expensive and difficult to achieve on a LAN, simply because it is labor-intensive. On LANs, you do not have the data center automation capabilities that you have in the mainframe world. Staff must back up and recover system data when the system crashes, keep track of licenses for all of the software running on the client workstations, upgrade new software releases on the clients and servers, and so on. Although more automated tools are becoming available, don't expect them to be inexpensive. It will cost plenty to deploy adequate systems management tools--security, backup, performance tuning, change management and so on--to control the applications and protect the corporate data. Also, you want these systems management tools to integrate well with your existing systems management tools, including those in the corporate data center.

LANs are expensive to troubleshoot and maintain. Downtime can reach five percent or more, which may be acceptable when all you're running are e-mail and spreadsheets, but five percent downtime is intolerable for any operational system that you use to run the business or interact with customers. In addition, networks are often unstable when you are forwarding files and messages. When called upon to handle more advanced tasks, such as controlling various specialized servers, including database, application, and communications servers, this new level of complexity can cause trouble that is tough to identify. Every time IT adds a new server to the LAN or connects to another legacy data source, complexity increases exponentially.

Many organizations do not have in-house experts who are capable of troubleshooting the network operating systems (such as Novell's NetWare and IBM's LAN Server) driving the LANs. To achieve greater network reliability for client/server environments, organizations must develop this expertise in-house, as well as redesign the networks and acquire more tools. Most of today's corporations have in-house WAN expertise but not LAN expertise. A corporation can always hire an expert to install a LAN, but troubleshooting is ongoing and more difficult.

The next hurdle is internetworking a company's various LANs. Department heads often get a surprise when a major client/server project brings them to the same table and they discover that they have a "hodgepodge" of several different DBMSs, networks, operating systems, and applications. Their surprise will only grow when they see the bill for integrating these heterogeneous elements.

Also, bear in mind that client/server functionality--such as two phase commit--may increase network traffic substantially, and necessitate expensive network upgrades.

Data administration is centralized for host-based systems. Client/server environments demand more than one data administrator, and companies must have technical support available in-house. Generally, client/server implies a multivendor environment in which tools from different vendors must connect together. Organizations must function as systems integrators to get it all to work. As a rule of thumb, "dirt connects at the interfaces," which means that connecting all this stuff together and then maintaining the connections is difficult and time-consuming. All too often, companies budgeting for a project forget to allocate any time or resources to connecting the components together and resolving interface problems.

Consider application development. Companies are excited by the graphical development tools that promise to boost programmer productivity. However, they often do not realize that testing event-driven GUI applications requires three times as many testing personnel as testing process-driven applications. This expense offsets programming productivity gains significantly. Also, most client/server development tools do not increase productivity for all elements of the application. Many of these tools excel at developing GUI screens rapidly, but do not help much with automating the coding of the transactions among client and server and other functions. Furthermore, there is still a relative dearth of packaged client/server applications available, so companies must often build their own specialized vertical applications.

In addition to increased operations and support personnel costs, client/server requires that most of the technical staff undergo extensive and ongoing training in new concepts, processes, and tools. Some industry analysts estimate that it costs $35,000 to $50,000 (including lost productivity costs) to train an information systems administrator in a new infrastructure, and $25,000 to $40,000 to train a programmer in a new platform. While the cost of training is too big a subject to address fully here, training is a significant recurring expense that is usually underestimated. (See my October 1994 DBMS article, "Train or Fail: The Hidden Side of Client/Server" for a discussion of the scope of training required for client/server environments.)

As you can see, client/server implementations are more expensive than they seem at first glance. In fact, the pursuit of IT cost savings should not be a primary driver for organizations deploying client/server. If you sell this benefit to management, be prepared to eat your words and polish up your resumé.

Benefits

Another big benefit is that GUIs encourage users to utilize the functionality. A third key benefit is the ability of client/server to facilitate implementation of business process reengineering, thereby enabling a company to redesign jobs and workflow to achieve order-of-magnitude operational improvements. (Although reengineering processes for client/server may seem like a "cost," it is not directly technology-related. The benefit is derived from the logical reeingineering of the business to a more efficient process model.) Indirectly, all three benefits are about making more money.

Here is another way of looking at client/server's benefits: When choosing application candidates, remember that any successful client/server system should result in at least one of five performance objectives: increased revenue, increased profit, improved customer satisfaction, cost savings, or increased market share.

Cutting Perceived Costs

In addition, you do not have to buy a developer's license of every product for every developer. In the client/server environment (unlike the mainframe environment), both a developer's license and a runtime license are usually available. The runtime license is much less expensive than the developer's license.

The ability to spread client/server investment over several years implies a different approach to budgeting. The traditional model for budgeting--year to year to year--could give you problems with client/server projects. With client/server, you should budget in smaller cycles, perhaps using a three-month or six-month budget. Trying to predict expenses in the next quarter or the next six months can be difficult. Instead, you should gather the requirements and the needs of the users just before you begin work on each new phase of the system. You can also budget training to occur just before it is needed, which may help soften the blow of training expenses.

Additionally, your budgets should minimize inventories because costs keep declining for client/server hardware and software. The hardware or software you purchase today, even at a 20 percent discount, could be 40 percent cheaper six months down the road.

For some companies, the shift from spending money on hardware (capital investment) to spending it on people (expense) may have tax implications in terms of write-offs. There may also be other financial advantages to buying a software package instead of spending money on personnel to develop it.

Briefly, managers looking to minimize expenses should develop an approach that results in the following:

• Minimal personnel in charge of operations and support
• Maximum application development productivity
• Easier learning curve for application development
• More packaged applications
• A smooth path to new technology without additional replacement costs
• Cost-effective access to legacy data

1. Deploy fewer, larger servers
2. Collect servers in fewer locations
3. Implement automation and single-point management
4. Cross-train staff to minimize the number of specialists
5. Limit number of vendors and number of products

One is Silver; the Other is Gold

Companies moving to client/server systems want to salvage as much of their past investment as they can. According to popular myth, companies want to throw out all their existing mainframe systems and deploy everything on cheap hardware tied together by an open systems architecture. This clean-slate approach is absurd: Companies are not about to throw out anything unless the replacement benefits are tremendous. Often, a better, more cost-effective solution is to use the mainframe as a server for certain applications.

Vendors are beginning to realize that to be successful they must take responsibility for shielding the user organization from client/server's complexity by offering products that overcome the limits of the multivendor environment. As a buyer, a good way to control costs is to ensure that you find the vendors who are going to help you handle this complexity.