- 1 Introduction
- 2 Key Issues
- 3 Key Problems
- 4 Building the Business Case
- 5 Conclusion
5.4 Building the Business Case
The models we use in these business cases are necessarily broad and generic. Your particular situation may have unique issues or issues that need a different emphasis. The purpose of these models is to help you quickly build a business case without getting caught in the details. To use these models, there are three things you will need to do
Understand the concepts behind each model
Make sure you address the issues they raise
Modify the models for your situation
Each model builds on the previous model. It is useful to build a single spreadsheet for all the calculations. Be sure to include calculations for both buy and build scenarios. Once the spreadsheet is built, filling in a few values can quickly help you assess any component project.
5.4.1 GUI Components
The business case for using GUI components is the easiest to build. Many development environments come with free GUI components. One caveat about using this type of component is the need for a developer with enough skill to use them. Fortunately, this is a fairly low skill level and should have negligible impact on your organization. You may have to allow for a few days of experimentation, but this is less costly than building a component from scratch. Can you justify purchasing more sophisticated controls? The business case here is almost as easy. Consider this example: there is a vendor who sells a developer license for either their ActiveX or JavaBean spreadsheet component for $399. You can't develop a fully functioning spreadsheet component for $399, so clearly it's cheaper to purchase the component.
Unfortunately, things become more complicated when you want to deploy an application using purchased GUI components. For components that come with a development environment, there is usually no extra cost to deploy them. This makes them the most cost-effective to reuse. With other components the cost of deployment changes with either the number of users (typically for client-side components) or the capabilities of the server hosting for the component. In your business case you should look at the value of a component in terms of its cost per user. The idea is that a reused component adds value to the business and the more it is reused, the lower its per-user cost. Many vendors have aggressive pricing for large-scale deployment. Using the component from our previous example, let's look at the deployment cost.
For a small deployment of less than 10 people, assume the per-user cost is $99 and a 10% discount is available when 10 or more licenses are purchased. To purchase a developer version and deploy this component for 10 people will cost $1299. Compare this to the cost of developing a GUI component. Let's assume a developer costs $50 per hour. At this rate, the cost of the purchased component is worth about 26 hours of a developer's time. Clearly no developer can create the equivalent component in 26 hours.
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 amount of savings will be based on some productivity factor. Reuse can pay for itself even for these small-scale components. Reuse of GUI components can typically lead to a 40% improvement in productivity. This is a nice payback for a low cost. I use this factor (0.4) in the application reuse savings equation in Figure 5-2.
){kind=link}
If you choose to build your own reusable component you are responsible for its maintenance and support. Therefore, you need to account for more than development costs. Each reusable component you create will have ongoing support and maintenance costs. How much support and maintenance you need for a component depends on the complexity of the component and the skill level of those who will use it. A component such as a fully functional spreadsheet may require as much support as an equivalently sized stand-alone application.
Another issue for developing your own GUI components is the need for more skillful developers. A solid grounding in component-based software engineering and object-oriented methodology is needed to create reusable components. While GUI components lack the infrastructure issues of more complex components, you still need sound engineering practices to create good ones. If you already have skilled developers there is no additional cost. If your organization doesn't have this skill set you will either have to develop it internally or hire appropriately skilled developers. You need to add this cost to your development cost (see Figure 5-2).
Figure 5-2: GUI component calculations.
I summarize the business case for GUI components with the calculations in Figure 5-2. Using these calculations for both buy and build scenarios can help you determine at what point each scenario is most appropriate. For example, with GUI components, if end-user cost is relatively high, then building a component becomes more cost-effective for large-scale deployment.
5.4.2 Service Components
With service components the business case becomes more complex. You should extend the earlier basic calculations by accounting for additional factors. From our discussion of issues, these additional factors fall into three categories
Technical sophistication
Infrastructure support
Organizational readiness
Let's examine how each of these affects the business case.
5.4.2.1 Technical Sophistication
Service components are more complex because they must integrate with other pieces of software to function. They are not as stand-alone as GUI components. Server components may wrap legacy systems or require additional middleware such as application servers, message brokers, transaction servers, or EAI tools to function. You can't simply deploy a service component. You must pay for and deploy the appropriate supporting software. This means a higher cost.
5.4.2.2 Infrastructure Support
Unfortunately, it's not enough to simply deploy the additional middleware—you need to support it. You may have to provide (or outsource) operational support 24 hours by seven days a week for the middleware, separate from application support. Another issue is that new middleware often requires new hardware to ensure promised performance and reliability. Both additional support and hardware can add often-unanticipated costs to service component deployment.
5.4.2.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. If your developers do not have those skills, you will either have to hire those who do or train programmers and give them a chance to develop the needed skills. Furthermore, you will need to use a software engineering process to develop and deploy these components. If your organization doesn't have the right processes, you will need to develop them. If you have none of these capabilities or resources, you really need to ask yourself if your culture is ready for service components. Expect resistance to the imposition of software or component development processes. To account for these new costs I will create a complexity cost to show their impact.
Implementing interfaces between systems can account for as much as 40% of the cost of deploying new systems. Accordingly, service components have a higher payback when they are reused. Service components, as in Figure 5-3, typically have a reuse productivity factor of 150% because they do so much to ease the pain of integrating systems.
){kind=link}
Figure 5-3: Service component calculations
We can summarize the business case for service components with the additional calculations shown in Figure 5-3. As with the GUI component business case, it is useful to build a spreadsheet with both build and buy scenarios. One thing you will notice is that it is more costly to deploy service components. This usually means you need a larger user base to spread the costs across. Still, their productivity factor can have a very important affect on your calculations.
5.4.3 Domain Components
The last business case is for what I define as domain components. Domain components are the most difficult to build as reusable components. If you construct or derive a class-level diagram of your system you will find that domain components are your key abstractions. They are among the most central and highly connected components in the system. They are not usually monolithic. For example, you don't have a monolithic component named Customer. The Customer component contains many others such as name, address, and demographics. This aggregated Customer component may require interaction with other key abstractions such as Order and Bill. These interactions are often constrained by business rules, thus it is often most effective to deploy domain components within a business component infrastructure. This component infrastructure requires a cast of supporting components. Building these key abstractions and their associated component infrastructures is very difficult. Most component infrastructures require four iterations before they are truly useful and reusable. Accordingly, deploying domain components will be the most costly use of component technology. They will also provide you with the highest payback. Domain components typically have a reuse productivity factor of 1000%.
My calculations need some modification to account for these new costs. We 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 component model within which the component infrastructure will work. We treat these two items separately because of the variations in component models. We can summarize the business case for service components with the additional calculations shown in Figure 5-4.
){kind=link}
Figure 5-4: Domain component calculations.
These components are usually only cost-effective when their costs are spread across the entire enterprise. Purchased domain components and component models may be a real bargain due to the difficulty in creating them. However, purchased component models and domain components often need modifications to fit your particular business. You need to account for these modifications in your cost model.