in reply to What is Enterprise Software?
Software whose failure everyone notices quickly
I think your brief statement cuts to the heart of the definition but leaves out at least one important aspect, which is any notion of the environment in which it is expected to operate.
Although I like and use Perl, the vast majority of my paid work is in Java. One of the descriptions that I've found useful to me as I've read my way through ridiculous numbers of books was in Ted Neward's "Effective Enterprise Java" published by Addison Wesley where he describes qualities of an Enterprise System. Unfortunately, it doesn't do much to narrow the definition.
"An enterprise system is one that has the following qualities.
- Shares some or all of the resources used by the application: The ubiquitous example here is the relational database(s) in which all application data resides. Sharing these resources adds some additional implied complexity: the data is shared because it needs to be available to multiple users simultaneously. As a result, the system must support user-concurrent access both safely and quickly.
- Is intended for internal use: "Internal" here means "the opposite of mass-produced software sold to end consumers." While the system may in fact be shared between the company and business partners, it is written with specific knowledge of the company, its business practices, and its specific requirements.
- Must work within existing architecture: With rare exception, the company already has a set of hardware and software in place that the system must be able to interoperate with. In particular, this implies that the application must adapt to the existing database schema (rather than the other way around). An enterprise system must be able to adapt to the heterogeneous environment in which it lives.
- Will be deployed and supported by internal IT staff: For most companies, the actual "production" machines remain out of the reach of developers. This is a good thing—most developers are not particularly interested in being awakened in the wee hours of the morning when their application fails. But it also implies that the deployment of the system will be done by hands other than theirs, and it implies that the staff responsible for the data center must have some way to monitor, diagnose, and fix problems short of writing code.
- Will be deployed and supported by internal IT staff: For most companies, the actual "production" machines remain out of the reach of developers. This is a good thing—most developers are not particularly interested in being awakened in the wee hours of the morning when their application fails. But it also implies that the deployment of the system will be done by hands other than theirs, and it implies that the staff responsible for the data center must have some way to monitor, diagnose, and fix problems short of writing code.
- Requires greater robustness, both in terms of exception-handling and scalability: Enterprise systems, particularly when made available over the Internet (the classic e-commerce system comes to mind), represent a huge investment for a company. Every minute the system is down means thousands, perhaps millions, of dollars of missed revenue. Every user turned away from the company Web site (or worse, forced to stare at the browser waiting for the login request to complete) leads to a loss of credibility and/or potential sales for the company.
- Must fail gracefully: In an application such as a word processor, an unexpected condition can be handled by throwing up an "oops" dialog, saving the user's work, and asking him or her to restart the program. An enterprise system can't afford to do this—if it crashes, millions of dollars go down the drain in lost productivity, sales, client perception, and so on. An enterprise system strives for "Five Nines Availability": total system uptime of more than 99.999% per year. That leaves downtime, scheduled or otherwise, of 0.001% per year, or roughly less than five minutes.
- Must gracefully handle evolution over time: Enterprise systems have long-lived lifecycles; the Y2K problem testified to that. As a result, a system must be able to accommodate the inevitable changes that occur within the company over time: mergers, sales promotions, policy shifts, corporate changes of direction, acquisitions, and so on.
Well, I don't know if this adds more clarity or more mud. Certainly, it is more of the same ideas. It was the first thing to come to mind when I read your post. I believe that the first chapter of his book is available online as a sample at informit.com.
The main problem I have with "enterprise software" is one of context. I find that the thing that is being built ends up being lumped in with the things that are being used to build it, and I see a fairly distinct difference between twhetwo. At my customer site, I find that "Enterprise system" and "Enterprise solution" tend to refer to the things that are being built using tools that some vendors market as being "enterprise software" or "enterprise versions" of their software.
Is Perl Enterprise software? Well, at the very least I'd say it is a tool (or a collection of tools) that can be used to create Enterprise systems.
Rob
|
|---|