Building a business case for Components
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
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
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.
John D. Williams is a contributor to Application Development Trends. He is president of Blue Mountain Commerce, a Cary, N.C.-based consulting firm specializing in enterprise, domain and application architectures. He can be reached via e-mail at [email protected]