Challenges to Component Technology Success
- By John D. Williams
- January 1, 1900
In my last two columns,
I described the issues surrounding the business case for components. I talked
about the importance of understanding business goals and the component life
cycle. I also discussed the roles of organizational readiness, infrastructure
support and reuse as key success factors. While all of these things are important,
I cannot neglect to mention the risks and challenges users face when trying
to use component technology successfully.
While you can develop a
business case for components, it is another matter to actually obtain the value
you want to achieve. There are many reasons the expected value may not be achieved:
poor planning, shifting business conditions or a change in the basis used for
your assumptions. The chance of any of these happening is the risk users take
when moving forward with any technology. Most business cases require users to
identify areas of risk and to define ways to mitigate such risk. Accordingly,
it is worth taking the time to look at these areas of component technology.
Understanding the risks
you face not only helps you to develop a good business case, it lets you understand
which battles you need to fight. Identifying risk in your organization depends
on the answer to one important question: "What will keep us from obtaining
the value we desire when using components?" Evidence suggests there are
three areas that can cause significant problems: wrong culture, wrong goals
and wrong purpose.
When discussing a wrong
culture, we are not judging its correctness, only its readiness for component
technology. For our purposes, a wrong culture is one that is not prepared to
make good use of components. However, this is not simply a matter of saying
you are ready to use components or not. In order to take advantage of the different
levels of components, there must be a corresponding change in the development
Consider the following anecdote,
which may describe the culture at your company. There was once a ditchdigger
who was given the job of digging a particular ditch by 6:00 p.m. It was a challenging
task, but he figured if he worked hard all day, he just might get the job done.
He had been working for about two hours when a fellow pulled up with a backhoe
and asked him if he would like some help. The ditchdigger told the man to go
away; he had to finish digging the ditch by 6:00 p.m. and didn't have time to
As our little story shows,
some cultures can be narrowly focused. Because of time or cost pressures, they
feel they cannot take the time to consider alternatives to the way they currently
work. A narrow focus is understandable, but organizations often do themselves
a disservice by not considering alternatives to current practices. Developers
usually approach this problem in one of two ways. They either wait for a brief
respite before bringing in new technology, or they bring it in by stealth and
declare victory once they have accomplished their goal. Either way, moving to
a new technology in this type of environment can be a real challenge.
The stealth mode of technology
adoption has its own risks, however. What happens if this back door, under-funded
and unsupported approach fails? It often means that the technology will not
get another chance. Successful stealth programs require both support and protection
to succeed. It may be at a low level, but it must exist. One-man heroics rarely
carry the day.
Another organizational problem
is a lack of infrastructure for the level of technology you want to use. This
is most often seen when moving to more advanced levels of component usage. Organizations
may not be inclined to make this move because of the investment required. Even
if you make the case for a good return on investment, budgetary constraints
may make it a moot point. For example, business conditions may require that
resources be focused on certain projects, leaving none for rolling out new technology.
One approach is to deploy new technology on a small scale before rolling it
out to the enterprise. However, some pieces of infrastructure are so expensive
that a small-scale rollout makes little sense.
And while reuse can deliver
great value to an organization, companies often have to change both their processes
and structure to take full advantage of it. Developing truly reusable components
is hard work and requires a software engineering process to do it well. Furthermore,
you often need to modify your development process to include reuse. Most processes
I have seen do not make any allowance for either creating or using reusable
components. In addition, you need someone to support commonly reused components.
This means establishing some type of reuse center.
Yet a corporate culture
can also undermine reuse. I know of a company that rewards its developers based
on the amount of code they write. The more they write, the greater their reward.
That company won't have reuse as long as the "more is better" reward structure
is in place. Companies that succeed at reuse have a culture, as well as a reward
structure to support it.
When building reusable components,
you must envision not only today's needs, but how your components may be used
in the future. What if you get it wrong? You may simply not anticipate a particular
usage of a component. This is not unusual. Developers will often try to use
components in ways that the components' designers never imagined. The problem
with this is that you may be unpleasantly surprised by the results. Good documentation
and a focus on black-box reuse can help.
Even if your component has
the functionality you need, there may be a mismatch in system engineering goals.
For example, you may have designed a component for great flexibility — a worthy
goal. What happens, though, when someone wants to reuse it but needs high performance
within narrow constraints? In this case, your component may not be the right
one to use even if the functionality is there. Many factors go into determining
whether a component is a good fit for a particular application. Good component
documentation helps characterize engineering constraints and fitness for use.
Another area where goals
can go wrong is when the component is well designed, but business needs change.
When you design a reusable component, you usually make some assumptions about
the nature of a domain and the processes that will work in it. In today's economy,
however, it is not unusual to have your assumptions challenged and discarded.
Businesses change their processes and models to meet the changing demands of
customers. Some businesses even change the type of business they are in (I know;
I worked in one). This is one reason it is so difficult to build good domain
components. You are gambling that your assumptions about the future of a business
are correct, and that is not always a good bet. Because the cost of developing
domain components can be so high, firms find it cheaper to modify a generic
model than to build one from scratch. This is part of the reason the ERP market
has grown so much. This is also the reason it is easier to gain value from service
components. While your business may change, your need to access a database probably
will not. In dynamic markets, infrastructure services may remain more stable
than the domains they serve.
Closely related to the
issue of wrong goals is the problem of wrong purpose. For example, service components
and domain components each have a different scope and purpose. Because they
have differing needs in terms of infrastructure support and developer skill
sets, you should not use the same component for both purposes. I have seen this
type of problem happen most frequently on small projects when analysts try to
cram lots of functionality into a few components. For some reason, they think
that having fewer components will make their system simpler; instead, they end
up with poorly abstracted components that have mixed types of functionality.
This quickly becomes a debugging, maintenance and reuse nightmare. Good analysis
and design can overcome this problem. In this case, more classes can mean better
abstraction, greater flexibility and higher quality.
The business case for components
must address the risks we face. Understanding these risks also helps users to
understand which battles they need to fight in their own organizations. In order
to identify risk, however, we need to determine what will keep us from obtaining
the value we want when using components. This will vary from organization to
organization, but for many companies the key areas of wrong culture, wrong goals
and wrong purpose are a good place to start.
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]