This topic came up at lunch today…it is a contentious issue, but I’ll wade in fearlessly!
It seems to me that although there are many applications used in an enterprise, very few of them are actually deserving of the title “Enterprise.”
I am sure that this is one of those “how long is a piece of string”-type arguments that can’t ever be ‘won’ but one of the best “feature-lists” that seems to cover all the requisite bases is given in the Gartner report Magic Quadrant for Enterprise Application Servers, 2Q08, which I excerpt here:
“…a system software product of the following minimal characteristics:
- Offers a “container” implementation for the execution of application software modules (SM):
- The container provides a “programming model” (a set of APIs for use by the SMs).
- The container deploys as a long-running server operating system (OS) task (OS “daemon”).
- SMs are programmatically addressable on request remotely through services that are associated with the container.
- The container allocates and uses OS resources (memory, threads, tasks) on behalf of the individual SMs, freeing SM code from the necessity of direct interaction with the OS.
- The container provides resource pooling (database connections and network connections), and the pools are shared by the SMs.
- Supports distributed computing (load balancing and failover clustering between container instances).
- Provides an API or other means for authentication and authorization by the container.
- Provides an API or other means for monitoring the status and minimal management (such as start and stop) of the container instance(s).
- Provides an API or other means to access a file system by an SM.
- Provides an API or other means of access to a relational DBMS (RDBMS) by an SM.
- Provides an API or other means of invoking SMs by an SM:
- Within the same container instance
- Across like container instances
- In other unlike container types
- Provides an API or other means to demarcate an atomicity, consistency, isolation, durability (ACID)-style transaction by an SM.
…”
In addition to all this, Martin Fowler, in the introduction to his book Patterns of Enterprise Architecture gives other properties:
- A lot of persistent data
- Concurrent data access
- A lot of user interface screens
- Integrate with other enterprise applications, often transactionally or in a time-sensitive fashion
- Lots of translation between data formats (usually for integration or reporting)
- Complex business ‘illogic’
- A requirement for ’scalability’ (meaning the application has to deal with those intangible and ill-defined issues of response time, responsiveness, latency, throughput, load sensitivity and degradation, to name but a few)
But wait, there’s more!
An Enterprise Application also lives in a context: what is the application’s Service Level Agreement and how is that monitored; how is that application deployed and how is it maintained; how does server/network infrastructure maintenance impact on the application; what logging facilities should be made available and how are those logs to be used (reporting); how is ‘uptime’ defined and managed; etc., etc., etc.
Don’t forget the people! A typical Enterprise Application is not simply “install and forget”, indeed, it may resemble an overgrown baby with very particular care and feeding needs; ‘nanny’ must have a very different skillset to that needed by a person skilled at managing a desktop SOE.
Just because an application is used in an “enterprise”, just because it is client-server, just because it is written in Java, C#, C, Python, or Whitespace, just because it is running on JBoss Application Server, Oracle WebLogic Server, IBM WebSphere, or whatever, just because you have a load balancer in front of a load of disparate server instances, etc. doesn’t necessarily make the software worthy of the term “Enterprise.”
Not many applications will touch all the bases outlined here, but it should be quite clear that real Enterprise applications are hard to build and that in reality the tag ‘Enterprise’ is a hard one for an application to earn.
It should also be quite clear that the tag ‘Enterprise’ is a hard one for a developer to earn!
Truthfully, it is hard for a development team to earn. The days when an Enterprise application can be developed by a guy and his (C/Java/C#/…) compiler are (or should be…) long gone. Of course, that one guy can produce good, useful software having significant value to its owning enterprise but it is doubtful whether that code will qualify as true “Enterprise” grade stuff.
