Via Stefan, here is a pragmatic posting that cogently explains that the enterprise software picture isn't as black and white as folks who constantly engage in the "enterprise vs. enterprisey" battle wish it were. I especially like the "Enterprise-Class Software" and "Software That Runs The Enterprise" distinction that the posting makes. I'll refer to these as ECS and STRTE, respectively, throughout the rest of this posting.
There are applications where ECS is absolutely necessary, usually due to a mixture of important technical and business reasons. IONA's many customers in telecommunications, finance, and manufacturing, for example, often require such software. If these folks merely laugh you out of the room for calling them "enterprisey" and suggesting that they should just use STRTE for everything they need, then consider yourself lucky.
At the same time, there are many things that can be solved with STRTE. Such software is far more flexible and far less expensive than ECS. The former may not perform or scale anywhere near as well as the latter, but it doesn't need to. The referenced posting rightly refers to STRTE as "the glue that never sets."
One way to view these two classes of software is to relate them along Geoffrey Moore's Technology Adoption Life Cycle curve. Often, but not always, ECS lies toward the right side of the curve, in the land of conservative users. STRTE, OTOH, is often, but not always, found more to the left, where visionaries and early adopters hang out. The argument between the two camps is therefore a natural one, not so much about pure technology but more about approaches and beliefs, and in fact it's not unlike the age-old and never-ending political and social arguments between liberals and conservatives.
Dynamic languages have been around for quite awhile, but today they're often at the center of the ECS vs. STRTE debate, as ECS is almost always built with "traditional" enterprise-class languages such as Java, C++, and C, while STRTE is almost always powered by Ruby/JRuby, Python/Jython, PHP, Perl, JavaScript, or other dynamic languages. For example, in his informative Ruby Ape Diaries, Tim Bray specifically mentions the integration problem and wonders if Ruby might be the language that ends up bridging the different language communities behind ECS and STRTE. Meanwhile, Jon Udell wonders why some continue to try to make the argument about choosing one or the other when you can have both together. Indeed, with JVM-based dynamic languages like JavaScript, Jython, and JRuby and CLR-based dynamic languages like IronPython allowing close integration of these languages with Java and C# respectively, there really isn't a need to choose one approach over the other. Rather, as Jon correctly points out, these systems allow you to have the best of both worlds.
This is kinda geeky (apologies in advance!), but if you verbally try to read "ECS STRTE," it sorta sounds like "Easy Street." Perhaps that's a sure sign that the combination of STRTE and ECS could make a lot of enterprise systems easier and less expensive to develop and maintain. Let's end the annoying "ECS vs. STRTE" arguments and keep working to use the best of each together.