|Perl Monk, Perl Meditation|
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:
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.