I posted the first draft of this at
http://www.relevancellc.com/blogs/?p=36#comments in response to a
query along the lines of "What would it take for Ruby to be considered
enterprise software?  Transactions?".  It received some positive
responses, so I thought I'd save a copy, revise it slightly, and share
it with a wider audience.

I wish I were online at the moment so I could add references, since
this essay draws on the ideas of many other people, in particular

"Enterprise software" is software that gets sold to a so-called
enterprise.  Native English speakers might think an "enterprise" is
something brave, noble, and dangerous, such as starting a small
business, but in this case, "enterprise" is used to mean the opposite:
the executives of a large, risk-averse company have chosen to flatter
themselves by pretending that they're engaged in something brave,
noble, and dangerous.  These "enterprises" use a lot of software, but
most of that software doesn't get sold to the "enterprise" itself; if
it gets sold at all, it gets sold to one of the employees of the
"enterprise", who has the authority to spend $400 or whatever to get
the software they personally use to do their job.  That's not
"enterprise" software, because it's sold to an individual, not a
so-called enterprise.

"Enterprise software" is software that has to be sold to an
"enterprise", where someone who doesn't use the software (typically a
manager) must be persuaded to use his purchasing authority to buy the
software.  It's different in a variety of ways from other software,
but none of these ways are strictly technical.

First, "enterprise software" costs more.  If software doesn't cost a
lot, individuals can generally buy it themselves without managerial
buy-in, although other factors may interfere; for example, everyone
has to use the same bug-tracking system for it to work.  Getting
managerial buy-in often involves expensive salespeople, whose
commission comes out of the software's price, and managers everywhere
have a well-known perverse incentive to expand their budgets.

Second, "enterprise software" doesn't necessarily work, although
sufficient effort can usually make it work.  An up-front $50 000
price-tag makes it seem more reasonable to spend $1000 or $10 000 to
customize it to your needs before you can use it.  In extreme cases,
such as ClearCase and Oracle, keeping the software operational
requires a team of expensive, specialized full-time employees.

The nontechnical background of many managers, in addition to the
perverse incentives in many managerial structures, often allow
enterprise software to sell well even if it does not work at all, no
matter how much effort is applied.

Third, "enterprise software" is surrounded by consultants who will
sell you the service of making it work, as explained above.  In some
cases, these ecosystems of consultants are competent and highly
skilled.  In other cases, such as the case of Java, many of them are
spectacularly incompetent, vociferous in their ignorance, and prone to
attack competing systems.  This results directly from the sales
process for "enterprise software," in which expert persuaders gull
technically incompetent managers into adopting the software.  Managers
who aren't technically well-informed enough to select the software in
the first place will also not be well-informed enough to distinguish
between competent consultants and incompetent consultants, so both
competent and incompetent consultants will flourish --- but the
competent ones will eventually get sick of it and go elsewhere.

I didn't really understand this until KnowNow, the startup where I
worked, got turned into an enterprise software company by its VCs and
management; although I had previously had the opportunity to observe
most of the pieces of the puzzle, I had clung to the idea that
"enterprise software" was technically better in some way from the
software I was used to using.  It turns out that the differences are
entirely social, not technical, and one of the major differences is
that "enterprise software" is under much less pressure to have any
technical merit.

Reply via email to