March 04, 2003, 12:00 AM — Where does all the money go when you install a line-of-business software
application? Obviously there is the cost of the software product and
perhaps the other software and hardware pieces required to make it
function. There is the ongoing cost of system management and perhaps
there are training costs for staff. What else is there?
In an ideal world, that should be just about it. However, as we all
know, unless the product is very simple or very commoditized, or both,
there is one big outstanding cost.
I speak of the potentially long and potentially costly exercise known as
"configuration".
Application configuration cost is something an Einstein-like thinker
should take a close look at. Just as the speed of light is constant no
matter what, it appears that application configuration costs (at least
in terms of elapsed time) are constant no matter what. In particular,
the time taken to configure an application appears to be independent of
how much money you spent on it.
Let me try and express that in more concrete terms. Imagine that two
identical twins set off in opposite directions to run identical business
ventures.
The first twin installs a set of open source components to make up the
required software application. The software cost is zero or so close to
zero that it is zero for all practical purposes. It then takes two
months (at X dollars a day) to configure the software to the needs of
the business.
The second twin installs a group of best of breed, commercial
applications. The capital cost is significant. It then takes two months
(at Y dollars a day) to configure the software to the needs of the
business.
Odd, don't you think?
Then there is the nature of application configuration itself. An
endlessly fascinating and eclectic activity! At one end of the spectrum
we have configuration by modifying a few parameter files. At the other
end of the spectrum we have fully blown custom programming to effect the
required configuration. When does configuration stop and custom
application development start?
Perhaps it is my imagination but I get the impression that as
applications get more and more flexible and complex and abstract, the
need for configuration is growing apace. So much so, that I have seen
examples where the distinction between "product" and "collection of more
or less re-usable bits and bobs plus a Java/c# compiler" blurs
significantly.
Furthermore, the growing use of powerful scripting technologies like
Javascript, Python, Tcl and so on make it possible to do at
configuration time, effectively anything you could do back in the
development shop. You can change the behavior of the very guts of the
application, on site in an, um, 'configuration file'.
Actually, I'm all in favor of this latter form of configuration - as
long as the configuration consists of manipulating well defined core
components in the application.
Unfortunately, as I have written before in this column, we as an
industry suffer greatly from the lack of a workable concept of a
'component'. Some day, we will get there. For now, let's just be
charitable and say that application configuration is necessarily a mixed
bag of techniques.
The not-insignificant cost of tailoring a set of applications to a
business has resulted in an interesting phenomenon in recent times.
Namely, some entrepreneurs have found it easier to build their business
models around the default capabilities of a line-of-business application
rather than go through the time and cost of tailoring the application to
their business model. I came across two examples recently. One was a
five person company of road-warriors selling office equipment who set
themselves up to directly reflect the model built into their
off-the-shelf contact management system. The second was a much larger
enterprise that found it easier to change their model to suit the needs
of an ERP system rather than have the ERP system configured.
Configure your business to the needs of the software. Now there's an
idea!
