The cost of components
I recently heard about a doctor who was suing
his bank because they 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
His attitude reminds me of many technical people I know. We work hard
to understand technology and use it well. We rankle at the thought of
dealing with business cases, budgets and schedules. These things are just
not as clean and neat as technology.
Unfortunately, just like the doctor, we find ourselves embroiled in
tasks we would rather avoid. This becomes the case as we roll out component
technology at an enterprise level. In fact, it is unavoidable. As we move
beyond the realm of simple GUI components, we find ourselves in a technological
world that requires ever-increasing levels of infrastructure. These increased
levels of infrastructure bring additional costs to the enterprise. These
costs must be justified based on their impact to the business. Suddenly,
we're not in technology land anymore.
We can't do enterprise-level components without infrastructure. For
example, I've never heard Enterprise JavaBeans mentioned outside the context
of running in an application server. We talk about serving up HTML pages
to end users, but that in turn implies that we have Web servers to deliver
those pages. It doesn't end there. There are also the data transformation
tools of Enterprise Application Integration (EAI), message queuing systems
and transaction servers. All of these pieces of infrastructure have a
place in supporting the n-tiered distributed applications we develop with
|While we rightly tout the benefits of components, we also need to
point out the implications of needed infrastructure to the organization.
Infrastructure components can be very costly. There is more than a
single up-front software cost.
good business sense about technology
is key to getting it purchased and adopted.
There are ongoing support, training and development tool costs. That
is not to say infrastructure components are not valuable or cannot be
justified. They certainly have a necessary role to play. What it does
mean is that we must spend more time creating the business case for our
technology. Like the doctor, we are pulled into tasks we would rather
As developers, we often focus on what a technology can do for the company.
Our business customers are more interested in the bottom line. If we can't
explain how our technology will help the company from a business point
of view, they are unlikely to care about its technical benefits. A good
business sense about technology is key to getting it purchased and adopted.
Our challenge is to make the business case for the things we know make
A key task in developing the business case is to identify, as best we
can, the costs of the infrastructure. Some costs come immediately to mind:
development tools, software server licenses and hardware, for example.
Others are not so obvious. How will you pay for operational support of
the server? What about operational support for the tool itself? You may
also need to pay for development support. The scalability of the infrastructure
and your rollout strategy can also affect costs. Some parts of the IT
organization may view your deployment of new technology as an opportunity
to increase their staff. This is particularly true for support organizations.
Dollars for staff may be the price of their support. This is the corporate
version of pork barrel riders on congressional bills.
Most infrastructure projects have large up-front costs. The greatest
challenge we often face in deploying these technologies is determining
how they will be funded. Funding for infrastructure usually comes in one
of two ways: it is either centrally funded or it is done on a project
basis. Usually, it is easier to do a cost justification with a centrally
funded infrastructure. This is because you can use the whole enterprise
as the basis for justification. Unfortunately, this isn't always an option.
When funding is done on a project basis, you must find a project large
enough to pay the high initial costs. You can also seek the help of several
projects to provide the initial funding, but this is more of a challenge.
If you've identified an appropriate project, you still need to get buy
in to the technology. The best way to do this is to first involve people
in the tool selection process. This gives them a sense of ownership in
the tool. Next, develop a prototype with the selected tool that is oriented
toward their application. This lets them clearly see and demonstrate the
value the tool brings to their project. You can usually do a 30- to 90-day
prototype for little or no cost in software. What you learn in the prototype
can be used to calculate the benefit of the tool to the project and beyond.
Another issue is the need to ferret out hidden costs. For example, support
costs and types can be difficult to quantify. Companies may divide various
operational and development support roles between different parts of the
IT organization. This usually means that you need to gather the support
of several people to successfully deploy your technology. One key to their
support is clearly showing how their costs are fairly represented in your
Have you thought about training costs? It's usually more than the cost
of training one or two developers. If you are creating an enterprise infrastructure,
you need to train the enterprise to use it. This implies training for
an initial development team, training for the support teams, and ongoing
training for the rest of the development organization as they adopt the
technology. Even if you plan to do training in-house, there are costs
incurred when developers aren't spending their time working on applications.
One of your greatest challenges in building the business case is to
make the intangible real. For example, we often believe, deep in our gut,
that a particular tool will benefit the company. If that benefit is savings,
the question then becomes how you capture and demonstrate those savings.
Sometimes organizational accounting practices make it very difficult to
do this. Also, projects may prefer to re-interpret the benefit as cost
avoidance and not savings. Regardless, the point here is to be aware of
what benefits you are trying to show and understand how you will demonstrate
them in a tangible manner.
In dealing with the issue of benefits and savings, we need to be careful
what we promise. Many of the business case presentations I've seen focus
on how time and money will be saved by replacing the old way of doing
things with a new technology. It rarely works out that way. Legacy systems
continue to use old technology. Some development teams never adopt the
new tools. In the end, adopting a new technology simply adds additional
costs, because old costs are never eliminated. If you claim the benefit
of saving time or money, be sure that existing processes and structures
will let you do so. Ask who will step up and let their budget or staff
be cut based on projected savings. This is when people start talking about
cost avoidance, not savings.
Organizational structures can also affect your business case. In most
organizations, each development team owns the skill sets and licenses
to use a tool. With a high-priced infrastructure, it is often more cost
effective to centralize development skills. This lets you reduce the cost
of training and the number of development licenses needed. This implies
that development teams can't own all of the resources for a project. However,
this runs against the grain in many development shops. Most project managers
want to own the resources working on their project. Still, the business
case often shows it is more cost effective to centralize these specialized
Once your tool is deployed, be sure to quickly demonstrate its value.
Focus on getting an initial success. You can then leverage this success
to get opportunities to demonstrate value. This is often the best way
to get development teams to adopt your technology. If one group succeeds
with it, others will want to use it as well. It's important to remember
that not all development teams will derive the same amount of benefit.
Look for opportunities that will allow you to maximize the value you claimed
in the business case.
One of the real joys of working in IT is the opportunity to explore
new technology and envision its value to the company. Along with the fun
comes the hard work of making the business case to those who don't care
about technology -- only the business benefit. If we do this well, everyone
benefits. How do you face this challenge? Write and let me know.
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@example.com.