Columns

The cost of components

• By John D. Williams
• June 4, 2001

I recently heard about a doctor who was suing his bank because they kept bouncing his checks. It turns out he was overdrawn by $50,000. He complained that he went to medical school to become a doctor, not an accountant. He was upset that he was expected to do more than practice medicine.

His attitude reminds me of many technical people I know. We work hard to understand technology and use it well. We rankle at the thought of dealing with business cases, budgets and schedules. These things are just not as clean and neat as technology.

Unfortunately, just like the doctor, we find ourselves embroiled in tasks we would rather avoid. This becomes the case as we roll out component technology at an enterprise level. In fact, it is unavoidable. As we move beyond the realm of simple GUI components, we find ourselves in a technological world that requires ever-increasing levels of infrastructure. These increased levels of infrastructure bring additional costs to the enterprise. These costs must be justified based on their impact to the business. Suddenly, we're not in technology land anymore.

We can't do enterprise-level components without infrastructure. For example, I've never heard Enterprise JavaBeans mentioned outside the context of running in an application server. We talk about serving up HTML pages to end users, but that in turn implies that we have Web servers to deliver those pages. It doesn't end there. There are also the data transformation tools of Enterprise Application Integration (EAI), message queuing systems and transaction servers. All of these pieces of infrastructure have a place in supporting the n-tiered distributed applications we develop with components.

There are ongoing support, training and development tool costs. That is not to say infrastructure components are not valuable or cannot be justified. They certainly have a necessary role to play. What it does mean is that we must spend more time creating the business case for our technology. Like the doctor, we are pulled into tasks we would rather avoid.

As developers, we often focus on what a technology can do for the company. Our business customers are more interested in the bottom line. If we can't explain how our technology will help the company from a business point of view, they are unlikely to care about its technical benefits. A good business sense about technology is key to getting it purchased and adopted. Our challenge is to make the business case for the things we know make technical sense.

A key task in developing the business case is to identify, as best we can, the costs of the infrastructure. Some costs come immediately to mind: development tools, software server licenses and hardware, for example. Others are not so obvious. How will you pay for operational support of the server? What about operational support for the tool itself? You may also need to pay for development support. The scalability of the infrastructure and your rollout strategy can also affect costs. Some parts of the IT organization may view your deployment of new technology as an opportunity to increase their staff. This is particularly true for support organizations. Dollars for staff may be the price of their support. This is the corporate version of pork barrel riders on congressional bills.

Issues

Most infrastructure projects have large up-front costs. The greatest challenge we often face in deploying these technologies is determining how they will be funded. Funding for infrastructure usually comes in one of two ways: it is either centrally funded or it is done on a project basis. Usually, it is easier to do a cost justification with a centrally funded infrastructure. This is because you can use the whole enterprise as the basis for justification. Unfortunately, this isn't always an option. When funding is done on a project basis, you must find a project large enough to pay the high initial costs. You can also seek the help of several projects to provide the initial funding, but this is more of a challenge.

If you've identified an appropriate project, you still need to get buy in to the technology. The best way to do this is to first involve people in the tool selection process. This gives them a sense of ownership in the tool. Next, develop a prototype with the selected tool that is oriented toward their application. This lets them clearly see and demonstrate the value the tool brings to their project. You can usually do a 30- to 90-day prototype for little or no cost in software. What you learn in the prototype can be used to calculate the benefit of the tool to the project and beyond.

Another issue is the need to ferret out hidden costs. For example, support costs and types can be difficult to quantify. Companies may divide various operational and development support roles between different parts of the IT organization. This usually means that you need to gather the support of several people to successfully deploy your technology. One key to their support is clearly showing how their costs are fairly represented in your analysis.

Have you thought about training costs? It's usually more than the cost of training one or two developers. If you are creating an enterprise infrastructure, you need to train the enterprise to use it. This implies training for an initial development team, training for the support teams, and ongoing training for the rest of the development organization as they adopt the technology. Even if you plan to do training in-house, there are costs incurred when developers aren't spending their time working on applications.

One of your greatest challenges in building the business case is to make the intangible real. For example, we often believe, deep in our gut, that a particular tool will benefit the company. If that benefit is savings, the question then becomes how you capture and demonstrate those savings. Sometimes organizational accounting practices make it very difficult to do this. Also, projects may prefer to re-interpret the benefit as cost avoidance and not savings. Regardless, the point here is to be aware of what benefits you are trying to show and understand how you will demonstrate them in a tangible manner.

In dealing with the issue of benefits and savings, we need to be careful what we promise. Many of the business case presentations I've seen focus on how time and money will be saved by replacing the old way of doing things with a new technology. It rarely works out that way. Legacy systems continue to use old technology. Some development teams never adopt the new tools. In the end, adopting a new technology simply adds additional costs, because old costs are never eliminated. If you claim the benefit of saving time or money, be sure that existing processes and structures will let you do so. Ask who will step up and let their budget or staff be cut based on projected savings. This is when people start talking about cost avoidance, not savings.

Organizational structures can also affect your business case. In most organizations, each development team owns the skill sets and licenses to use a tool. With a high-priced infrastructure, it is often more cost effective to centralize development skills. This lets you reduce the cost of training and the number of development licenses needed. This implies that development teams can't own all of the resources for a project. However, this runs against the grain in many development shops. Most project managers want to own the resources working on their project. Still, the business case often shows it is more cost effective to centralize these specialized skill sets.

Once your tool is deployed, be sure to quickly demonstrate its value. Focus on getting an initial success. You can then leverage this success to get opportunities to demonstrate value. This is often the best way to get development teams to adopt your technology. If one group succeeds with it, others will want to use it as well. It's important to remember that not all development teams will derive the same amount of benefit. Look for opportunities that will allow you to maximize the value you claimed in the business case.

One of the real joys of working in IT is the opportunity to explore new technology and envision its value to the company. Along with the fun comes the hard work of making the business case to those who don't care about technology -- only the business benefit. If we do this well, everyone benefits. How do you face this challenge? Write and let me know.