Enterprise Application

"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

Complex business logic
Access to relational databases
Distributed computing, generally using some sort of remote procedure call or remote method invocation protocol
Distributed transactions
Data exchange between heterogeneous systems
Message-oriented middleware
Directory and naming services
Interpersonal communication (e-mail, chat, shared documents, video-conferencing)
Security
Web-browser-based client interfaces
Integration with legacy systems
Integration with the systems of other businesses/organizations
Centralized administration and maintenance
Something that costs boat-loads of money (and is considered to be worth it by its sponsors)
Something that wastes boat-loads of money
Slow developer velocity to near zero with 3-minute start-up times
Give BEA and IBM Global Services reasons to exist
Applications that have reach across multiple functional areas in a company

Candidate attributes of enterprise applications include

High availability
High integrity
High mean time between failure
Secure
Confidential
GracefulDegradation under excessive load and system failure
Does not lose information under failure conditions
Does not corrupt information under failure conditions
Defines a clear recovery path under failure conditions

Attributes that are not required of enterprise applications include

High performance
Fun to use

Software may be considered enterprise software if all the attributes are certified and measured against potential threats such as PowerFailure, HardwareFailure?, SoftwareBugs?, etc. Consider how much money could be lost if one banking transaction disappeared every day where each transaction had a value of $1,000,000.

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.

InternetBanking? may be seen as an EnterpriseApplication. You would be upset if you lost money and TheUserDoesNotCareAboutTheTechnologyFeatures?.

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.

Perhaps you need DynamicRelational. If not available, the next best thing may be an AttributeTable.

A second example would be the project I'm working on now. To be general, let me say that my boss's idea of how to implement it involves creating a SQL table for generically holding lots of 'choice' data, and a complicated set of other tables holding a decision-tree type of structure that involves the choice data, etc. (I'm not sure what my idea of the best solution is...)

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

For the SimpleMinded, the following will suffice for "enterprise": -- DonaldNoyes.20080512.1510.m06

a systematic purposeful activity
- Note the avoidance of limitation by any extensive introduction of motivation, profitability, classification or specification of structure or methods.

CategoryEnterpriseComputingConcerns