"Enterprise" is one of those buzzwords that is hot these days, but does not have a definition everyone agrees upon.
One definition: an application designed for corporate use. It helps the organization make money. Thus, games and consumer-oriented applications do not qualify.
Another common definition is that an enterprise application is one that interacts with multiple parts of a business/organization. Enterprise applications make use of databases and other organizational assets across a heterogeneous network.
Candidate features of enterprise applications (and the tools designed to develop them) include
Candidate attributes of enterprise applications include
While performance and high transaction throughput are benchmarks flaunted by database vendors they aim only to attract the eye of the business manager that seeks to get the best performance per dollar spent. No matter how fast a database, if it corrupts data at intermittent intervals or loses data under heavy load, they will avoid it like the plague. An enterprise will pay top dollar for EnterpriseAttributes?. Features listed above indicate the solution conceived to implement the BusinessProcess while having EnterpriseAttributes?. Alternatively the features may be required to solve some problem imposed by SoftwareRequirements.
I have the view that a lot of applications used in enterprises are not enterprise applications. The word 'application' may be a bit deceiving: it may imply both the typical application that an employee uses to perform work - ClientEnterpriseApplication? - or it may imply backend non visual software that executes on a server with the purpose of performing some business process - ServerEnterpriseApplication?.
I consider InternetBanking? a prime example of a ClientEnterpriseApplication? with Oracle DB and MS SQL Server as prime examples of a ServerEnterpriseApplication?. My examples may be seen as a key EnterpriseComponent? of an EnterpriseApplication by bestowing the EnterpriseAttributes? to the developed software as it is time consuming and expensive to develop a platform or framework that provides those attributes to the developer.
Some applications are called "enterprise" even though they don't need high uptime targets. They may support management decisions rather than directly control production. They may be used for making forecasts days or weeks ahead such that, if they are down a few hours, there is no immediate impact on the business.
Definition: "An application whereby a big-wig gets fired if it fails."
Variation: "An application whereby the total annual salaries of those fired for failure is greater than $600,000."
I think a good test for enterpriseness comes from a variation on GreenspunsTenthRuleOfProgramming:
"Any sufficiently complicated Enterprise Application contains an ad-hoc, bug ridden, informally-specified, slow implementation of half of SQL." --JesseMillikan
I don't follow this. EnterpriseApplications? are typically distributed across multiple machines, support complex workflows, and must address NFRs like resiliency, scalability, performance, and security. SQL doesn't begin to meet those kinds of requirements.
Nor should it. That would be like criticising a wheel for not meeting the requirements of being a wheelbarrow. SQL is a database language, not an architecture, application, or implementation.
Exactly my point. The original quote is comparing chalk and cheese.
A number of DBMSes, however, are resilient, scalable, exhibit high performance and security, support implementation of complex workflows, almost invariably support clients distributed across multiple machines, and sometimes support clusters of servers. Indeed, that is what DBMSes are for. The original point might have been better expressed thusly: "Any sufficiently complicated Enterprise Application contains an ad-hoc, bug ridden, informally-specified, slow implementation of half a DBMS." (I think someone already covered this here, as GreencoddsTenthRule or some such, but I can't find it. Gnomes? Little help?) This assumes, of course, that the enterprise application doesn't already use a DBMS, or is only using it as a crude persistent store.
"Crude persistent store"? Is that one that curses at you whenever you insert new rows?
Yup, that or a poorly-constructed 7-11 that won't go away...
Databases are an important component of many EnterpriseApplications?, but there is still a need for middleware, business process management, services (including governance and orchestration), and numerous other technologies. EnterpriseApplications? are often those that have such needs.
GreencoddsTenthRuleOfProgramming - I thought it must have been said before it occurred to me, but I couldn't find it at the time I posted the phrase; but my real meaning was attempting to create meta-database type features all over the place, with or without an RDBMS. "[...] or is only using it as a crude persistent store." This is something like what I was saying. The common example is creating a simple system of records with arbitrary name/value pairs somewhere, usually using SQL to implement it, to store whatever random information the application might require in the future, instead of waiting for the future and building a real relational model for the information then.
I also wasn't claiming that this 'reinvention' is a positive aspect; in almost all cases, the RDBMS should be used as one, and not used to build a database-like system on top of it.
So this is probably a duplication of an anti-pattern discussion somewhere. AbstractionInversion comes to mind. Often an attempt to build a SwissArmyKnife. I just mentioned it because I thought it might resonate with someone. --JesseMillikan