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:

• associating a product with a problem domain that it addresses
• differentiating or positioning a product with respect to competitors

This rules out some of the definitions in other posts in this thread:

• cost versus other solutions -- this may be true, but it is correlated, not causal with the definition; it is an indicator either of the problem domain or of the success of the marketing designation in enhancing the price point of the product (or both)
• risk to executives/providers for failure -- likewise, this is predominantly an effect of the high cost; any waste of resources on a large scale leads companies to seek to assign blame or seek recovery

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:

• applying to the total organization (or a least more than one of the first-level organizational units)
• applying to the needs of the "corporate center" at the top level of the organization

Software in those problem domains would then seem likely to have some characteristics (though not necessarily all) along these lines:

• a centrally-administered resource
• purchase decisions made from the corporate center
• benefits multiple parts of the organization
• helps senior executives manage across the organization
• creates change in multiple parts of the organization, with commensurate implementation complexity and need for senior executive sponsorship and change management
• not directly revenue-producing (though it may be an enabler revenue gains within divisions)

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.