Enterprise software for me tends to mean, very flexible and very scalable. Let's take perl and php sans mod_perl and the php cachers out there. As a "web language", it's not enterprise level. But even then, perl has its advantages in how flexible it is. Flexibility gives it more power, 'casue in today's day and age, less flexible software, like dbase, isn't helpful. We need replication. Relational capabilities. Live backups.

Peoplesoft is big because of this. They have a mamoth piece of software that's flexible to a point, and they have consulting services to further that felixibility. Apparently, it's also quite scalable too.

Have you looked into vendor assistance in what contracts you are about to forge? Like a 1 month, reduced cost setup thing?

Humma la beeba la seeba la booba la
Humma la beeba la seeba la bop

Have you looked into vendor assistance in what contracts you are about to forge? Like a 1 month, reduced cost setup thing?

I believe that our vendor contract reads something like "we agree to place our nuts in a vice and allow the vendor to tighten it as much as the vendor cares to"

When they are the only company in the field, they screw us for everything, and we smile, and say "thank you sir, may I have another?"

And secretly we trial GPL software to see if it has caught up yet. Nearly there, but not quite...

____________________
Jeremy
I didn't believe in evil until I dated it.

For me, an example of an "enterprise level requirement" is a need for an accepted series of design patterns and underlying technologies for supporting software transactions accross multiple machine boundries with completely different transaction methodologies.

For example having an atomic software transaction which needs to update a series of databases (perhaps Oracle and MS-SQL, as an example) as well as fire off some CICS transactions and to be incredibly nasty, an update to an LDAP system. This is where going with an IBM J2EE stack makes sense, and this is where they "shine" as an enterprise application framework. From monitoring the livelyhood of your system with a Tivoli installtion, to perhaps using MQ for asynchronous message beans (oh, it seems that the mainframes are busy doing reports for 1/2 of the day, and we need an infrastructure that provides transparent asynchronous transaction execution) to being able to leverage it with a bunch of webbie programmers by giving them a custom tag environment to work within from within JSPs, and knowing that this environment is multi server failover "guaranteed" due to Websphere server clustering.

That's the sort of thing that's "enterprise" to me. 99% of the work in the software world is sure as hell *not* enterprise :) (At least in my humble experience...) Oh, and to finish off, yes, I do know that all of this is doable with Perl... hell, I'm sure it's doable with emacs lisp :) It's just that Perl doesn't have a quijillion dollar corporation betting their reputation on continuing to iterate through these tools and make them better and more suited to similar "enterprise" needs.

Just curious -- have you ever actually written Java code to do the kind of thing you're talking about here (transactions across heterogenous systems), and if so, how difficult was it? One thing that occurs to me is that the high-end vendors who sell these database systems typically also sell some kind of two-phase commit option that will work across competitors systems, so that could be an option for systems built using Perl.

I have... across a mainframe / oracle / mssql boundry. It was not exactly the most fun thing in the world I've ever done, though I am reticent to admit (btw, I don't like java on a "personal preference" level), using Java did make it considerably easier. The mainframe vendor (IBM) already had a great many objects we could use to interface with MQ and CICS... Oracle behaved in an intelligent manner (they have too much invested in java to not at least *attempt* to behave in an intelligent manner), and the MSSQL work... actually, now that I think about it, someone else completely did that work :)

i'm not saying that it's not likely and possible that if such a framework and series of libraries existed for perl, it wouldn't be equally suited. i just *personally* have no experience with perl on that level, nor have I successfully in my googling found a vendor (or preferably vendors) that provide a perl framework with such functionality. *sigh*, what a shame.

Personally, I take "enterprise" application as application used in an organization that has a medium to large size, and the application is used across the organization, to support its main business functionality. The failure of the application usually has a serious impact on the organization's main business.

Although complex business requirements usually end up with having a complex system to support it, it is not the complexity of the system we used to measure whether an application is "enterprise". (That's the result, but not the origin.)

For example, the supply chain system I am working on now, I consider it as an enterprise solution. If it fails, the company cannot order from vendors, thus has nothing to sell and make profit.

During the implementation of the project, I made some tool to generate DCO/DAO's for myself, this tool is obviously not an enterprise solution, even if I share it with other developers.