IT consultants and software makers have spent the last few years propagating one of the biggest myths in the history of computer-systems design (portable language), and the typical business technology consumer has been their victim.
Portable language is the Holy Grail of computer development, and while it has some allure for consultants, it doesn’t make sense for most corporations. Why? Well, consultants like it because they can reuse the same code in different engagements on different architectures. But companies that buy into the portability promise usually end up buying more hardware to run unoptimized code and fund more consulting hours to keep the project going.
In this column, we’ll examine why language portability isn’t the wunderkind it’s been touted to be and what CIOs need to know before taking the development plunge.
Examining the myth
The latest incarnation of the myth is Java. Like COBOL, Fortran, UCSD Pascal, and C before it, Java was expected to standardize the development process by providing a single language that could execute on any platform.
I recently worked with a large manufacturing company that bought into this myth. A top national consulting firm had convinced the company’s CIO that since employees needed to record their time, the company needed to develop a uniform system to collect that data. Since there was no guarantee that users would all be on the same platform—given the size and geographic distribution of the company—the consultants also convinced the CIO that the entire time-entry system should be developed in Java. This way, according to the consultants, users could download a rich GUI interface based on the Java “standard” and interact with a back end based on the Enterprise JavaBeans (EJB) “standard.”
A little over a year and $2 million later, the entire project was scrapped. The current system was then implemented in less than six months using a series of client Web pages and a set of time-management objects tuned for internal systems.
What went wrong? First, the client code couldn’t be stabilized on “any JVM (Java Virtual Machine)” as the consultants had promised. As a result, one of the first decisions made was to code only to certain JVMs and JVM versions, and to require clients to be on one of those versions. That was strike one for code portability.
Second, the project was originally designed and coded to work with EJB deployed on BEA Systems’ transaction servers in the middle tier. About halfway through the project, the company decided to standardize on IBM WebSphere for middle-tier processing, a logical choice since much of the data was still trapped in DB2 databases in the company’s mainframe. When the consultants wanted to add two full-time bodies to assist in the “conversion” from BEA to WebSphere, the CIO cried foul: “But you told me we were developing using Java and EJB because we could use anyone’s JVM on the client or EJB middleware and just move the code.”
After the consultants dropped the 250-page “conversion guide” provided by IBM for moving from BEA to WebSphere on his desk, the CIO understood that he’d been taken. That was strike two for code portability.
Once the system was deployed in a test environment, it became painfully clear that the performance would suffer if all of the business rules processing took place in EJB in the transaction-processing layer. It then became necessary to code much of the underlying data manipulation code in stored procedures in the underlying Oracle and DB2 databases. Once the code moved from Java to a stored procedure language, not only was the code no longer portable, but the necessary skill sets and associated costs began to rise precipitously. That was the third, and final, strike for code portability, and the project was cancelled.
It’s important to note that this is not an attack on Java per se. There are thousands of systems today using Java and EJB technology. But the developers working on the project mentioned above recognized they needed to pick a tool set and tune their application based on assumptions about the tool set and the platform together.
In fact, in order to make a system perform, it’s almost always necessary for the code used to develop the system to be tied in some way to the underlying hardware and operating-systems architecture. Although source code is rarely portable or reusable, the object code generated can be reusable. In the past, this meant interfacing code at the object level using proprietary protocols like COM and CORBA. But with XML and SOAP as the lingua franca of cross-application communication, CIOs should focus on developing software as reusable modules optimized for a single platform but accessible from any platform.
CIOs should also focus on reusability in areas outside of actual source code for an application. These areas include specific skill sets (developing database procedures, developing UI, testing, and QA), design patterns, and development methodology that’s not tied to any specific language or platform.
In expecting true portability, CIOs inadvertently put developers in a trap, and they must be willing to pay the price for what they give up: database optimization, rich user interface, integration with other devices, and lower total cost of application ownership.