In last month's column, I introduced the key issues to be addressed in
building a business case for components. I discussed the importance of
understanding business goals and the value of looking at the entire life
cycle of a component. I also showed that all components arenot created
equal, and that the business case changes as the category of component
changes. Three basic categories of components were identified: GUI components,
service components and domain components. These are not the only potential
categories for components, but they cover the range of issues users need
to address when building a business case. This month, I want to highlight
additional key issues for the component business case: organizational
readiness, infrastructure support and reuse.
One of the greatest challenges to the successful use of component technology
is organizational readiness. Organizational readiness includes existing
development processes, developer skill sets and corporate culture. These
areas are often overlooked in business cases, yet it is here and not with
technical issues that we spend much of our time. For example, any time
you want to roll out a new technology, you need to get buy-in from both
developers and managers. This usually means you need to put together some
sort of communication and marketing plan to sell the technology to those
you want to adopt it. If you focus just on the technical issues, however,
you will often fail because you have not taken the time to address organizational
issues.
Every organization believes it has a development process, which may or
may not be true. Most organizations actually have less process in place,
rather than more. You might get away with using GUI components in a haphazard
fashion, but that approach just won't work for service and domain components.
It also won't work for building any type of component. A software engineering
approach to development and deployment is required to gain the full benefits
of component technology. You don't need to use an excruciating and overblown
process, but don't confuse just enough process with no process at all.
The process will need to encompass everything from requirements gathering
and domain analysis, to testing and release engineering. These areas are
all affected by component technology. For example, the design and creation
of high-quality components requires a process that embraces a good object-oriented
methodology. While components do not need to be implemented as objects,
the object-oriented principles of encapsulation, abstraction and inheritance
can be very helpful in designing good components. Testing changes as you
begin to reuse previously validated and tested components. A good process
will help you understand where useful testing begins and ends. The delivery
of n-tiered component systems is also different. Deploying different tiers
to various platforms is a complex task. A good release engineering methodology
will help you deploy applications smoothly.
Once developers acquire new skills, you'll find that you can't propagate
them fast enough. But component-based systems are more complex than older
client/server systems, so it takes longer to acquire skills that are both
broad and deep. But gaining such skill and experience affects an organization
in two ways. First, it slows the adoption of a technology. There just
aren't enough skilled people available to do all the potential work. Second,
the payback and benefits of the technology are delayed.
In my February column ["Challenges of component technology," p. 72],
I addressed how you might best organize the skills of your developers
for application development. I won't repeat that information here. Once
you've figured out your organizational structure, you can focus on staffing
and training. It is important to have a generalist on your staff, someone
who can help you make decisions about how to deploy technology. But not
everyone needs to be a deep generalist. Instead of trying to give everyone
the same skills, focus training in three areas — by layer, by process
and by tool.
There are other organizational inhibitors that need to be avoided. The
first is the "will" problem. Some people will not change unless they are
told to do so. There are many developers who would rather do what they
know how to do than learn something new. Senior developers and architects
with project leadership responsibilities may take this stance because
they are more comfortable committing to something they know, rather than
betting on something they have little or no experience with. The old "not
invented here" syndrome can also kick in. Each organization has a few
developers who believe that if they didn't think of an idea first it must
not be worth much. The challenge in getting these people on board for
component development is to help them believe it really was their idea.
Finally, one of the biggest challenges is who will pay. This is particularly
true in the area of reuse. No one wants to pay the extra cost up front
to develop truly reusable components. What is needed is an enterprise
perspective. If a reusable component will benefit the enterprise, then
it makes sense to fund its development. In practice, it is often a separate
reuse center that has to pick up the cost of making a component reusable.
They also become the ones to benefit financially from its reuse.
Infrastructure support
Infrastructure support becomes an important issue when you move beyond
the use of simple components such as sliders and buttons. When you start
using components in the middle or lower layers of an n-tiered architecture,
you need to think about infrastructure support. For our business case,
this becomes an issue for service or domain components. Any time a component
needs to make use of middleware services, such as application servers,
you need to consider the cost of the new middleware. For example, Enterprise
JavaBeans (EJBs) require an application server to run. If there is not
already one in production, then you need to consider what it will take
to make it possible to deploy EJBs. You will need to set up development,
testing and production environments. This may mean additional hardware
servers, as well as multiple application servers. What about support for
the application server in production? Do your operations people understand
how to operate it, respond to errors or restart jobs with it? You may
acquire additional training costs or require more staff to satisfy this
issue.
The same issues can apply to existing software as well. How will the
new combination of your reusable component and existing middleware be
supported operationally? New combinations of software often raise support
issues. This isn't simply a matter of an application development team
supporting its work. Reusable components and architectures may be used
by many teams and require more central support.
Reuse
Reuse is something that developers have talked about for years, but have
had great difficulty in achieving to a significant degree. While components
are not the only reusable artifacts, component technology strongly supports
reuse, which can have a significant impact on your business case. Reuse
also has a financial factor associated with it. You therefore need to
consider both the savings and costs in your planning.
The productivity factors used in the business case are ultimately based
on the productivity gained by reusing components. If we are developing
complex systems, we can gain some advantage simply by using a component-based
approach; however, we gain much more when components are reused. One reason
for dividing the business case into three types is the different reuse
productivity factors associated with each type. Companies that have implemented
well thought-out reuse processes have saved millions of dollars. Even
the simple reuse of GUI components has positive payback. This range of
value will be seen in cost models.
Reuse programs can pay for themselves, but you can't have reuse without
spending some money to get it. Simple components may be purchased, or
you can spend time and effort developing them. Their cost is relatively
small and their payback is OK, but not spectacular. At the other extreme,
we have domain components that are serious business assets. But you also
need people, processes and tools to manage them effectively. While the
overall cost is higher, the payback can be very great. Either way, you
need to account for these costs in your business case.
Clearly, the business case for components is about more than technology.
Organizational issues can have a significant impact on your ability to
use and deploy different categories of components successfully. Next month,
I will examine the different business cases for components. By creating
different categories for our business cases, I will show you how to demonstrate
success at simpler levels of component use and lay the groundwork for
future success and justification.