The Business Case for Components
I recently heard of a doctor who sued his bank. It appears the bank 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. The good doctor's attitude reminds me of many technical people I know. We work hard to understand technology and use it well. We often rankle at the thought of dealing with business cases, budgets, and schedules. These things are just not as neat and clean as technology. Just like the doctor, we find ourselves embroiled in tasks we would rather avoid.
However, you need a high-quality business case to successfully deploy component technology at the enterprise level. A business case provides both the rationale and plan for a project—in this case, deploying component technology. A well thought out business case identifies the benefits and risks in adopting a technology. It also calculates the costs and payback for using the technology. A good business case provides the foundation for technology success. Without it, you may never get the chance to deploy your technology.
As you move beyond simple GUI components, making a business case for component technology can be a complex task. No matter what approach you take to building a business case, you have to make assumptions about your technical environment, organization, infrastructure, and business drivers. Technology advocates often miss many factors while building their business case. This chapter should help you identify and understand the key issues you need to address in your business case. There are also critical problems for which you need to prepare.
Rather than promote a single approach, I will examine three different models for building your business case. The model you ultimately choose will depend on your goals and the level of component technology you are trying to introduce. These models are based on differing levels of technical sophistication, organizational preparedness, and commitment to the technology. No one model can meet all needs. However, you will see that, as shown in Figure 5-1, business models build on one another by identifying the incremental issues and costs you encounter as you move from one level of complexity to the next.
Figure 5-1: Relationships between business models.