|There's more than one way to do things|
Software that solves an Enterprise Problem (rather than a departmental one) and that is written with an Enterprise Software Architecture
I actually find that the p5ee and Gartner definitions comes pretty close to defining what begins to differentiate "enterprise software" from other software. However. the subsequent p5ee laundry list speaks more to desireable characteristics of enterprise software rather than a definition.
Why do I feel this is so? My "theory" begins with the postulate that branding a product with a subjective qualifier or tag such as "enterprise software" is fundamentally a marketing endeavor, rather than an engineering endeavor. This kind of branding serves two purposes:
This rules out some of the definitions in other posts in this thread:
Interestingly, by focusing on the term for its marketing impact, I also rule out the real capabilities of any particular product in actually addressing a target domain or differentiating from another product in the quest for a definition of "enterprise software". What matters is the goal a company has in applying the designation, not in the ability of the company to have its product live up to the designation. It also means we can ignore software that may have similar characteristics but may not have been branded as such.
Therefore, one must address the two terms directly for what they evoke in the listener. We should also consider the intended audience, as that's the perspective we have to take in understanding the intended marketing effect. Others may have different opinions, but I would posit in the most general way that the term is intended for those reviewing, selecting, or funding the purchase of the product.
First, consider the goal of associating a product with a problem domain. "Software" is the easy word to address. Used generically for marketing, it just means program code running on hardware and, from a business perspective, implies which budget category it hits and how its purchase may be amortized under GAAP (or equivalent) accounting rules.
"Enterprise" seems like it could be a difficult word. Many of the other definitions in this thread focus on scale or criticality of the resource. However, in a business context, "enterprise" has an organizational interpretation as the root of the organizational tree, above all divisions, departments, and business units. This suggests a couple reasonable intents for the marketing meaning of the term, particularly as would be interpreted by potential reviewers, purchasers, etc. at that level of an organization:
Software in those problem domains would then seem likely to have some characteristics (though not necessarily all) along these lines:
Given this emerging definition of the domain, we can turn to differentiating or positioning a product with respect to competitors. Given the problem domain, the implication is that the product is addressing complex needs across an organization and has a high degree of senior executive awareness. This is where notions of "criticality" properly re-emerge. Positive characteristics of "critical" software then begin to resemble the p5ee list -- though I would argue that failure avoidance characteristics would wind up taking precedence over growth-supporting capabilities, as executives (and company stock) is punished more for unexpected failures than for slower growth or speed to market.
Summing up across these observations and thoughts, I'll offer my own definition, though with the caveat that this is what designating a product as "enterprise software" is intended to convey, not that any particular piece of enterprise software necessarily fully meets this definition.
Enterprise software is a centrally-administered resource that addresses common information processing needs of multiple departments or bridges information processing across departments. Enterprise software has the maturity, quality, robustness and support to be relied upon for mission-critical business needs.
Defined as such, Perl is not enterprise software, though particular applications written in Perl could be. Whether Perl can be taken seriously as a enterprise software development language will depend on whether software written in Perl for cross-department solutions can be shown to have the proper level of support for mission-critical needs. I think that has little to do with the language, and everything to do with the business model of Perl development. We need more success stories of Perl development companies serving the enterprise or more publicity on how Perl helps in-house enterprise developers better deliver mission-critical software.
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.