Java has an image of being suited to the high-end enterprise with an associated enterprise-level cost.
In today's enterprise IT environment, where CIOs are faced with making decisions on a multitude of tasks, selecting the correct platform for in-house development can seem a trivial responsibility. Are all platforms not the same, or at least similar at the core?
The choice of development platform is a simple choice if all a company needs is one or two applications. However, when considering a company's complete IT infrastructure, the choice becomes more difficult as issues such as backwards and forwards compatibility, integration as well as maintenance and future support for the platform become critical.
Of course, the issue of cost also plays a role in this decision. CIOs look at the platform and development environment that will provide all the functionality and flexibility the company needs, as well as the best total cost of ownership (TCO) over the long-term.
When it comes to the question of costs, the Java platform has often been seen as a fully functional, yet expensive option for the enterprise. This belief is based largely on the platform, as well as Java skills and the perceived complexity of developing applications.
Two approaches to development
This labelling of Java as a costly platform is not deserved. The choice of technology does not determine the cost of development, it is the methodology used that decides how expensive the project will be.
There are two basic approaches to development today: the architected approach which is defined by a careful process of architecting and modelling the solution before the coding begins; and the rapid application development (RAD) approach which, as the name suggests, allows developers to create applications in short order.
Using the architected approach takes longer to develop an application, but once finished it is stable, easily updated and integrated, and changes according to the needs of the company are easy to implement. Additionally, the application will have a lifespan of from five to 10 years. The RAD approach will get a system in use quickly, but changes are more difficult and the resultant system will have a limited lifespan of 18 to 24 months.
If a business is looking at a two-year lifespan for an application, the RAD methodology is the best and cheapest approach to adopt. If a CIO wants an application that lasts longer than two years and is built to make maintenance and changes simple, the architected approach is the answer.
A 'middle-way' is also possible which enables a fast initial development, with additional development added in short iterations. Refactoring is then appended to each new development phase - requiring a rework of existing code. This assists in growing and maintaining architectural integrity. To perform the refactoring step, a disciplined development approach must be employed, along with substantial automated tests capable of verifying the refactored code. This approach is typical of agile methodologies such as extreme programming and can extend the lifespan of RAD developments to rival those of architected solutions.
Methodology determines cost
Although Java started out as a tool for architected solutions, new development environments have introduced RAD Java tools to assist in quick development projects. So, Java applications can now be built to last or built quickly for a short lifespan - as the business requires, at the costs the business deems fit for each particular project.
The question of development costs is therefore not about which technology a CIO chooses, but the development methodology. In fact, in some instances, if the budget is available, taking both approaches could be the optimal answer.
The developers could start Java RAD and architected developments for the same project at the same time. The RAD solution will be put into operation first, allowing the business to proceed while the architectural process creates a bullet-proof application that can be taken into operation as the RAD version reaches the end of its life. This will provide business with exactly what it needs, an immediate solution backed up by a stable system that will meet its needs for years to come at a reduced cost.
Using Java as the development platform of choice is therefore not automatically an expensive option. In the appropriate business environment, supported by the proper development methodology, Java can be as cost effective as any other platform.
Malcolm Rabson, MD of Dariel Solutions