Columns

Computing the Cost

• By John D. Williams
• January 1, 2001

In the past few columns on our back pages, we've been looking at issues related to the business case for components. Last month, we talked about the risk and challenges in obtaining the value users expect from component technology. This time, we dive into how an organization can calculate the cost of purchasing components vs. building its own.

Much of the economic value of components is gained through reuse. As we've discussed before, an organization cannot gain the full benefits of reuse unless it adopts systematic reuse. How will you build the business case for components?

If you have a reuse metrics program in place, you can use the information you gather to build a company-specific business case. This is actually the ideal thing to do, because using your own numbers is more convincing than using industry numbers. If you are looking for metrics of this type, I highly recommend Jeffrey Poulin's Measuring Software Reuse: Principles, Practices and Economic Models (Reading, Mass.: Addison-Wesley, 1997) as the best source of information on reuse metrics.

The formulas we will use in our business case are designed to help you "kick-start" the business case. They will provide a fairly simple way for you to estimate the value of components to your organization. The information needed for the formulas should be relatively easy to obtain or estimate. To simplify the process, we will use the component architecture divisions discussed in an earlier column ["Building a business case for components," March 2000, p. 88] to help us estimate component value.

GUI components

The business case for using GUI components is the easiest to build. Many development environments come with free GUI controls; if this is the case, it just doesn't pay to write your own. The business case for purchased components is almost as easy. From a development point of view, the cost is usually quite low. For example, there is a vendor that sells a developer license for either its ActiveX or JavaBean spreadsheet for $399. You can't develop a fully functioning spreadsheet for $399, so it is cheaper to purchase it.

....Unfortunately, things become a bit more complicated when you want to deploy an application using purchased GUI components. Often, you need to factor in either per-user or per-server costs. There is usually no extra cost to deploy components from a development environment, which makes them the most cost-effective to reuse. For other components, the cost of deployment changes with either the number of users or the class of server.

Using the spreadsheet component example, let's look at the deployment cost. For a small deployment of less than 10 people, the per-user cost is $99. Discounts start at 10 people and, in fact, there is a difference of only $1 between the cost for nine users and that for 10 users. We can purchase a developer version and deploy this component to 10 people for $1,290. This is significantly less than the cost of developing a spreadsheet component.

What happens when we expand the user base and the deployment costs go up? The purchased component may still be a bargain. Remember, each time you reuse a component you save on both development time and cost. The savings will be based on a productivity factor. Typically, the reuse of GUI components can lead to a 40% improvement in productivity. We will use this factor (.4) in our app reuse savings equation below. If you choose to build your own reusable component, you need to remember that you've created a software product that you will have to maintain and support.

One thing that can be helpful to your business case is to look at the value of a component in terms of cost per user. The idea is that a reused component adds value to the business and that the more it is reused, the less its cost per user becomes. Distributing the cost across all users gives you some indication of the component's impact on the whole organization.

We can summarize the business case for GUI components with the following calculations:

• Your Component cost = Cost to build + Cost to maintain the components you build.
• Your Component cost = Developer cost + End-user cost + Maintenance cost for the components you buy.
• Buy a component if: Build cost > Purchase component cost.
• Improvement in productivity factor for GUI components = .4
• Your App reuse savings = (.4*Cost to build)*Number of apps > 1.
• Your Cost per user = Component cost/Sum of users across all apps (ignoring overlap in users).

Using these calculations for both buy and build scenarios can help you determine at what point each scenario is most appropriate.

Service components

With service components, the business case becomes more complex. We will build on the basic calculations we used for GUI components, but we need to account for additional factors such as technical sophistication, infrastructure support and organizational readiness. Let's examine how each of these affects the business case.

1. Technical sophistication — By our definition, service components are more complex because they must interface with other pieces of software to function. Server components may wrap legacy systems or require additional middleware such as app servers, message brokers, transaction servers or EAI tools to function. You can't deploy a service component by itself; you must pay for and deploy the appropriate supporting software.
   
   
2. Infrastructure support — Operational concerns, such as 24x7 operational support, add to the price of middleware. This is separate from app support. The middleware may even require new hardware to get the performance and reliability you are looking for. Both of these items can add operational costs to service components.
   
   
3. Organizational readiness — Because using service components is more complex than using GUI components, you need developers with higher level skills. This is true for both use and development. You will either have to hire developers that have these skills or train programmers. To account for these new costs, we will create a complexity cost to show their impact.

Implementing interfaces between systems can be as much as 40% of the cost of deploying new systems. Accordingly, service components have a higher payback when they are reused. Service components typically have a reuse productivity factor of 150%.

We can summarize the business case for service components with the following additional calculations:

• Your new Complexity cost = Middleware cost + Operational support cost + Hardware + Organizational readiness cost.
• Improvement in productivity factor for service components = 1.5
• Your App reuse savings = ((1.5*Cost to build)*Number of apps > 1) - Complexity cost.
• Your Cost per user = (Component cost + Complexity cost)/ Sum of users across all apps (ignoring the overlap in users).

One thing you will notice in these calculations is that it is more costly to deploy a service component; you will therefore want to spread the cost across a larger user base.

Domain components

The last business case is for domain components, which are the most difficult to build as reusable components. They are also among the most central and highly connected components in a system, because each component may contain other components. A reusable application framework is often created to govern business rule-constrained interactions. Creating domain components and frameworks is difficult work; most frameworks require four iterations before they are truly useful and reusable. Accordingly, domain components will be the most costly to deploy and will provide you with the highest payback. Domain components typically have a reuse productivity factor of 1000%.

Our calculations now need a domain cost, which is the sum of the costs for a domain component and its associated supporting components, plus the cost of the app framework it will work in. We treat these two items separately because you may or may not have a framework.

We can summarize the business case for service components with the following additional calculations:

• Your Domain cost = Sum of costs for the domain component(s) and its supporting components + App framework costs.
• Improvement in productivity factor for domain components = 10
• Your App reuse savings = ((10*Domain build cost)*Number of apps > 1) - Complexity cost.
• Your Cost per user = (Domain cost + Complexity cost)/Sum of users across all apps (ignoring the overlap in users).

Domain components are usually only cost-effective when their costs are spread across the entire enterprise. Purchased domain components and frameworks may be a real bargain compared to the cost of creating them.

If one thing is clear from our business cases, it is that component technology can be a cost-effective way of constructing systems. Reusing components also has a significant impact on productivity. If you build a business case for components, select the appropriate model based on organizational readiness and business goals.