Columns

Building a business case for Components

• By John D. Williams
• March 1, 2000

I've spent recent weeks discussing the business case for components with several IT managers. While I'm a strong supporter of component technology, I recognize that building the business case is a challenge for many organizations. As you move beyond using simple GUI components, making a business case for component technology can be a complex task. No matter what approach you take, you have to make assumptions about your technical environment, organization, infrastructure and business drivers.

Important issues you need to consider include business goals for the technology, technical sophistication, organizational readiness, infrastructure support and reuse. These issues are not isolated from one another, but are interrelated. Overlooking any one of these can lead to failure in rolling out component technology.

Business goals help you understand when you should or should not use component technology. Believe it or not, components are not needed for everything. Simple Web pages get along just fine using HTML and JavaScript. Perl is perfectly adequate for many CGI and scripting needs. If your application is very simple, non-component-based tools may be quicker or cheaper to use. How do you decide? It's not easy. The line can be fuzzy and it will change as components become more pervasive.

Another problem is that the potential payback for components may be too low for a given application. Suppose your company is new to components and doesn't have the infrastructure or skills to deploy a moderately complex component application. You may not be able to justify the start-up costs for a single application. Many firms address this by identifying ways to distribute the costs and benefits across the enterprise. Unfortunately, this is not always possible.

Successfully developing and deploying components requires that you use a software engineering approach to application development. Time or cost pressures may make the use of modeling or other rigorous processes unacceptable. This is often part of the justification for those "quick and dirty" programs that are supposed to be temporary fixes to problems. Unfortunately, these programs are rarely eliminated or replaced. Many of us discovered in preparing for the Y2K problem that old software never dies, it just keeps running.

Components are the right answer for complex and critical systems. They are robust, scalable and flexible. These are crucial factors for mission-critical systems. In fact, it is fair to say that component technology often trades simplicity for scalability and flexibility. Anyone who has deployed an n-tier app will acknowledge that this is more challenging than deploying a client/server or monolithic app. Accounting for the sheer increase in software pieces and platforms makes it a more challenging task. This tradeoff with simplicity is not always the case, but it is usually true for most medium to complex applications.

Component technology is also one of the best ways of making applications portable in heterogeneous environments. Many monolithic and client/server applications are written with a single platform in mind. The underlying technology used in these apps often does nothing to support portability. Some component technologies, on the other hand, can be very portable.

Component technology can show real benefits to companies that understand an application's life cycle. This type of understanding implies that an organization is looking at the Total Cost of Ownership (TCO) of an application. A TCO viewpoint makes it much easier to demonstrate the development and maintenance savings that component technology can bring to an organization. We know that development costs can be reduced through reuse. We also know that for medium to complex systems, a component approach is quicker for development, even for systems starting from scratch. A component architecture can also reduce maintenance costs through its use of encapsulation, clean interfaces and reuse. The fact that component applications can be very scalable means they don't have to be rewritten as frequently.

There is another reason to use components - quality. Quality components minimize development time and maintenance costs. They are also essential for reuse. Many firms give lip service to quality. Those who take it seriously will want to adopt component technology.

Building the business case

Given this starting point, how do we go about building a business case for components? One technique is to break down the business case by the level of technical sophistication of the components you want to use. Each level of sophistication has corresponding requirements on infrastructure, organizational readiness and cost. By dividing our business cases in this way, we can create incremental business cases to move an organization along in its use of component technology. This approach is more likely to succeed in large organizations where the cost of full-blown component adoption is viewed as prohibitive. What do we mean by technical sophistication? Components differ in complexity, scope and level of functionality. They differ in the skill sets needed to use them and in the infrastructure they require. This differentiation between components makes it difficult to create a single business case for components. On the other hand, it provides us with a way to create a useful set of business cases. For the purposes of our business case, let us divide components into three categories: GUI components, Service components and Domain components. These three categories let us divide the business case into models that differ based on complexity, cost and organizational readiness. As we examine them further in a later column, we will also see different productivity factors within these categories. Another benefit of this approach is that it lets you select the correct business case based on your company's environment and needs.

GUI components are the most ubiquitous type of component. GUI components encompass all of the buttons, sliders and other widgets used in building user interfaces for apps. Reusing these pre-built components is fairly easy and has a quick payback. In fact, it is rarely cost-effective to develop your own anymore. It requires a greater level of skill and commitment to component-based software engineering. In 1999, the market for GUI components was about $300 million, most of which was for COM technology components. The market for Java technology components was small but growing.

Service components provide access to common services needed by apps. One common characteristic of service components is that they all use additional infrastructure or systems to function. For example, you may construct a service component by "wrappering" an existing system. In that case, the existing system, through the component, becomes a service to other apps. Other service components provide infrastructure support, such as a common method of accessing databases or message queuing systems. Another common use of service components is to facilitate Enterprise Application Integration (EAI). You will find these components combined with other EAI tools such as Message-Oriented Middleware (MOM), transaction servers, data transformation engines and workflow systems. Since they don't provide the full functionality of these systems, these components are usually less complex than domain components but more sophisticated than GUI components.

Domain components are what most developers call business components. They may be reusable. Non-reusable domain components have an impact similar to service components, and you can use the same business case to justify them. For the purposes of our business case, we consider domain components to be those that are truly reusable. We call them domain components because truly reusable ones are often found only within a singular domain. For example, in an insurance application, domain components could include Bill, Policy and Claim components. It is unlikely that they would find broad reuse outside of that domain. Reusable domain components are difficult to design and build. They may have their own infrastructure as part of an application framework. They also require a high level of organizational expertise to build and deploy. The business case for domain components builds on the technical sophistication required of both GUI and service components.

Clearly, there are more issues that affect the business case for component technology. Next time, we will look at the implications each level has on organizational readiness, infrastructure support and reuse. After that, we will examine the business cases for components. This will demonstrate success at simpler levels and lay the groundwork for future success and justification.