Whoa, boy. Thassa BIG enchilada.

I think talexb is the closest of the posters so far. The application that enables and models and enhances the business functionality is the focus of enterprise software. There are tools such as Perl, Java Beans, Apache, Solaris, and Oracle which enable enterprise-level systems to be built, but the tools are the means to the end. There are tools at the nuts-and-bolts level (BSD and Perl, f.e.), there are tools at the middleware level (Apache and Oracle, f.e.), and there are tools at the architectural level (UML, flow charts, f.e.).

The key to building an enterprise-level application system is in the top-down holistic approach to its development. This can be done successfully or unsuccessfully by either payware vendors or homebrewers, and it includes careful attention to the human aspects of the processes being automated. This holistic approach also includes provision for other systems to have access. This is why applications which use a scalable SQL database like Oracle (or MySQL in its recent incarnations) on a *NIX platform are more often successful enterprise solutions and why closed-API systems like Brooks' FACTORYworks cause growing companies so much heartburn.

The key to a successful enterprise application is the careful attention to all aspects of design, not the particular tools used. My successes in architecting useful business-enablers have come from applying the following heuristics:

• Never buy a first-year car! or CPU, or language, or toolset dot-zero release...
• Use well-traveled API's like SQL, HTML, and BSD
• Recognize the holes you can't fill and shape the human interface so that people can plug them
• Focus on the robustness and flexibility of the core and make everything else out of small pieces that attach to it incrementally
• Think about loose coupling which will save your @ss over and over!
• Make your tools not matter in case you need to switch.

Management often has the Holy Grail in mind when they ask for an enterprise-level enabler, and this often results in an uneducated preference for name brand or bleeding edge tools that will save their bacon. In the Sixties and Seventies, this meant buying an IBM mainframe. In the Eighties and Nineties, this meant SAP or a customized Oracle solution, or worse, some idiotic PC-centric monstrosity like FACTORYworks. These days, it usually means some sort of Java medication.

What I've found is that today's managers have been toasted, fried, baked and burnt so many times by software automation vendors, especially "consulting firms," that they are ready to listen when you explain that solid solutions are built from well-grounded toolsets and proper architecting. They are already "there" in the sense that they understand that effective systems that are deployable in the short run are much better for their bottom line than any amount of hypervaporware that might someday hit the streets. I have successfully architected systems using open source Java and its underlying middleware like Jakarta/Tomcat and Hibernate, but I have had even more success with Perl/Apache systems that are prototyped on MySQL and deployed on Oracle.

In most cases, a modern enterprise app is transaction- and state-based, and the processes usually go to sleep waiting for human or other execution threads to complete the handshake, so there are very few places where computational speed is a factor. It's much more important to have robust middleware and underlying platform software that can deal effectively with transaction volume and varied client systems. Since databases coupled with web interfaces form the basis of most such systems, code can be reused very effectively.

Perl lets me deploy pieces of such systems one by one, using CPAN to augment its raw capabilities. More important, I can add more programmers as needed and the learning curve is minimal. Very rarely is a properly architected application dependent on quirks and special features of a particular database or operating system or toolset. If the architect does his job well, the tools are chosen for their ease of use rather than their raw performance or feature set.

The key to success of an enterprise solution is to plan a deployment that gives your users productivity wins all along the way. Do that, and your managers will become your evangelists, leaving you alone to concentrate on hitting more home runs.