To be fair, though, Java or .Net or anything else we like to demonize aren't the only things that can break for executives. Plenty of Perl things can do that too.

Except that Java/.NET will usually fail after > 10x the investment of the equivalent Perl/Python/Ruby/etc. solution.

My comment may be glib, but 25+ years involvement in "enterprise software" (as both producer and consumer) leads me to believe it isn't false.

Many of us have experienced the way that overly complicated nonsolutions get pimped as "enterprise", tagged with a massive price, and folks can't buy them fast enough. Meanwhile, elegantly simple solutions - some often free - are overlooked cuz they don't have a SKU code, a suit to pimp them, and someone to sue if they fail.

Does my answer avoid the question ? I don't think so; in fact, I think it directly responds to the appellation in question. You presented a rather lengthy dissertation about what "enterprise software" might (or might not) be, and end up with a (IMHO) trite generalization. Your generalization, in itself, should indicate the question may be searching for technical confirmation for a pure marketing term. I.e., the premise that there actually is a technical, rational definition for "enterprise software" may be flawed.

Based on your definition, if there's a bug in the firmware in my digital watch that also effects everyone who bought one, its enterprise software. For that matter, any of the numerous failings of MSFT's various Windows platforms also qualify it as enterprise software, tho Win95 seems an unlikely candidate for that classification.

I'll offer another glib, albeit true, definition:

If a manager (CIO or otherwise) gets fired when it fails, it's Enterprise Software.

Think about that for a bit: if its just a desktop app of convenience (e.g., Word, Excel, Outlook, etc), that breaks, the CIO won't even be advised of it (except when some sysadmin shows up to install the patch). But if the Exchange server screws up and sends a copy of everyone's salary to the entire organization, somebody is likely going to get an escort from security.

Here's another glib, albeit true, definition:

When Enterprise software fails, there's someone to sue.

Thats a major part of the reason PHBs pay the extra order of magnitude - and why it costs an extra order of magnitude. Again, its not a techie answer, but quite possibly (at least in the Litigious States of America) is what the purchasers of "enterprise software" are really looking for. (It lets them sleep better at night... hmmm, maybe thats another definition ?)

So far, both our definitions seem to define enterprise software as a product defined by its effect when it fails, and (in my case) by its cost. So lets think about the opposite:

• Enterprise software is software that demonstrably contributes to the success of the enterprise.
• Without the enterprise software product, the enterprise would either fail, or would otherwise demonstrably suffer.

Based on those definitions, I'd say Perl is undoubtedly enterprise software in many enterprises. Yet, if you collared the CIO's of those enterprises and asked if they agreed with that notion, they'd likely nrevously laugh at you, or otherwise ignore the question (very likely cuz they don't know what Perl is). For that matter, ksh, "Command prompt", and IE fit the definition as well.

Since that seems to fall short of a full definition, here's another glib definition:

Enterprise software is something complicated enough that a CIO will pay an order of magnitude more than its actually worth, regardless whether it actually solves the original problem.

So we're back to square one. There is no definition. "Enterprise software" is not a provable term. It's not 3NF. It's not O(NlogN). It may be NP complete. The value of the limit of enterprise software as it goes to zero is unknown.

Because its just a marketing term.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.