At the beginning of the third week of August, Mario Cilotta posted a thread to the CFDJ List asking for arguments in favor of upgrading from ColdFusion MX to ColdFusion MX 6.1. There are several reasons that I've chosen to focus this month's article on this thread.

One reason is that it's a nice change of pace from the "problemspecific" threads usually featured in this column; it's not that often that business decision questions are posted to discussion lists. Another reason is that ColdFusion MX 6.1 is new, and a popular topic. My main reason for focusing on this thread however, is because it is not uncommon for developers to argue the case of using or upgrading ColdFusion to the higher-ups who make business decisions but aren't technically savvy.

ColdFusion MX 6.1 is a crucial upgrade for anyone doing ColdFusion development, but how you convince people of this fact is not always as easy as you'd think. It's also a very different "sell" than prior versions of ColdFusion (version 5 and prior).

Mario's post specified that he has two servers, one running ColdFusion MX for J2EE and the other running the stand-alone ColdFusion MX server. He explained that his request to upgrade the servers was denied due to "budgetary issues" and that "The Powers That Be" had asked him for compelling reasons to perform the upgrade. He stated that he was planning to really push for J2EE on all of the servers because of the ability to run multiple instances, and that he also planned to use the increase in performance as another reason to upgrade. Mario wanted more fuel before talking with the person resisting the upgrade. Obviously, many list members responded immediately to tell Mario that the upgrade is free, so budget shouldn't be an issue.

I also responded by reminding Mario that I'd recently posted the performance matrix for MX 6.1, which shows drastic performance benefits; and that the new server not only has better mail support, but better (and more varied) database support, better Web service support, a more robust and stable component framework, etc. I also reminded him that when running multiple instances of CF, the garbage collection doesn't impact server performance anywhere near as much as it will on a single instance. I told him that in fact I couldn't think of a single reason not to upgrade from MX to MX 6.1. Stephen Moretti seconded the argument of performance being much better and added to my list of compelling reasons that the installer is much better.

Mario sent a response to clarify that what he really needed was something that would make his boss(es) see that ColdFusion can coexist with J2EE applications (J2EE is his boss's development platform of choice). He was looking for something in plain English that describes how ColdFusion can take advantage of resources already built into the J2EE Server (Java), that it will make separating business logic from the display layer easy as opposed to countering it, etc. His e-mail made it more clear that what Mario needed to do was not to show ColdFusion as an alternative to or replacement for Java, but as an enhancement to it. I suggested he state something like the following to his boss:

ColdFusion is a J2EE application that sits on top of a J2EE Server along with any other J2EE application deployed on the server. ColdFusion Markup Language, the scripting language interpreted by the ColdFusion Application Server application, is just an alternative method for developing Java applications. It's easier to debug, faster to develop with, offers out-of-the-box support for a variety of functional engines such as the Verity text-search engine, a charting and graphing engine, etc. Learning curves and development times are shorter with CFML than with Java or JSP, and developers with Java knowledge can easily integrate applications written in CFML with existing Java applications or functionality. CFML offers the same architectural benefits as Java and other object oriented languages and it tends to be easier to integrate with a display tier than with these other languages. Bottom line, it is the ideal method for developing Java applications.

This last sentence really sums up what ColdFusion is: "the ideal method for developing Java applications." No, it doesn't require knowledge of Java, but it does create Java byte code behind the scenes, and developers familiar with Java can take full advantage of its features in their ColdFusion applications. This is the ideal way to "pitch" ColdFusion MX, if not to everybody, certainly to companies and individuals who are either pro-Java or who just like buzzwords (you can throw in a "Web services this" and an "XML that" for these people while you're at it – and don't forget "cross platform," too). It's important that developers begin getting more comfortable and familiar with this way of explaining ColdFusion, as ColdFusion MX sometimes requires a very different "sales approach" than prior versions did.

Obviously, all of the great selling points of ColdFusion in the past still hold true, and should also be pointed out when convincing people to purchase or upgrade their servers. In order for us as developers to be successful, we must make the product successful. This can only happen if you take it upon yourself to learn the new features each time a new release is made available, and continue to persuade companies to use the product by showing your enthusiasm and educating them about just how cool ColdFusion is and continues to become.