Subscribe
About

Methodology, not technology

Java is often considered an expensive option for in-house development, but CIOs fail to realise it is the choice of methodology that determines the cost of development, not the choice of technology.
By Malcolm Rabson, MD of Dariel Solutions.
Johannesburg, 17 Nov 2005

Enterprise often considers the Java platform as an expensive option for in-house development mainly because of the perceived complexity of developing applications, but CIOs often fail to realise it is the choice of methodology that determines the cost of development, not the choice of technology.

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 a relatively short time.

Two approaches

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 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 better and cheaper approach.

A middle path

A middle path is also possible, which enables a fast initial development, but 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 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 and cost

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.

Although Java started out as a tool for architected solutions, new development environments have introduced RAD Java tools to assist in quick development projects. Consequently, Java applications can now be built to last longer or built quickly for a shorter lifespan according to business requirements.

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.

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 best.

In a dual approach scenario, the developers could start Java RAD and architected developments for the same project at the same time. The RAD solution would be put into operation first, allowing the business to proceed while the developers create a bullet-proof application that can be taken into operation as the RAD version reaches the end of its life.

In other words, by adopting a dual strategy, developers can deliver an immediate solution to enable business processes to continue without interruption, while backing it up with a stable, more robust system that will meet business needs for years to come at a reduced cost.

Share