Home: Issue 5 2008 › Lead Story › There is another way
There is another way
29/10/2008 | Channel: Information Technology
David Ballard offers a smart approach to modernising legacy sofware applications
According to industry analyst Evans Data Corp, .NET and J2EE (Java) are two of the most popular development platforms on the planet. Many companies have decided that all ‘strategic’ application developments will be conducted using one of these two modern languages.
At the same time, many organisations still have valued applications that are written in legacy 4th Generation Languages (4GLs) such as PowerBuilder, Centura/Gupta, and Delphi. Skill shortages, increasing support cost, inadequate performance and incompatibilities with system-level upgrades are exposing these companies to risks, and increasing the cost of ownership of the legacy software.
At the same time, the IT departments in those companies are being pressured by business users demanding software improvements that these older languages cannot support, such as requests for web services. Clearly, such organisations are thinking: ‘something must be done’.
As many development managers will have experienced, a large part of an IT strategy can involve migrating from legacy applications to modern technologies, such as .NET and Java; and as anyone who has managed such projects will testify, such re-developments can be very expensive, risky and time consuming.
It isn’t just a case of ‘translating’ legacy 4GL syntax to run under J2EE or .NET using conversion tools or compilers. These are totally different architectures and such literal translation will just deliver the old logic in a new language, bringing none of the benefits of the new architecture. Logic must be coded in a completely new structure. This coding involves an understanding of the business logic in the old application.
The problem is that the people who understood the logic of the old application will have left. Even if you can find staff to develop for both the old and new platforms, it would take them years to write fresh code. That process can be costly, troublesome, time consuming and risky. If the logic isn’t right, then the new application may be inferior to the legacy version it replaced.
The alternative is to re-evaluate the business process underpinning the old software application, and start afresh. But sophisticated business processes in sectors such as finance and logistics can take years to analyse and code.
Fortunately, another way of modernising applications has been gaining ground. Automated application transformation can deliver better results than manual rewrites, for 20 per cent of the cost.
Transformation is a sourced service combining sophisticated skilled consultancy with automated tools, developed by people who understand both the old and the new technologies. The service will deliver fully-tested, (and often enhanced) applications at a fixed price. Transformation should not be confused with code migration conversion, which often delivers low quality code by duplicating the existing application structure for J2EE or .NET.
Northdoor recommends a five-stage approach to automated application transformation:
1. Planning
Produce a full project plan including checkpoints where you review the transformed code at different stages of the process.
2. Architecture Design
Choose the technical architecture that best matches the needs of both the business and IT. The transformation consultancy will be able to guide you in this step.
3. Code transformation
Use software tools to map out the functions of the legacy code and translate them into an object-oriented structure to run under your target platform. Map out the inheritances and relationships within the business framework. The code is then converted to a universal layer and finally migrated to .NET or Java. This stage will use native functions and datatypes alongside code reassembled using an object generator.
4. Refinement
The service provider applies skilled consultants and more software tools to improve the productivity and accuracy of the transformation process. The result is a refined target application, possibly with software enhancements.
5. Testing and implementation
Test the code using a pattern-based approach and full impact analysis. This will ensure that the transformed application performs efficiently and accurately and to the agreed project plan. Implementation may now follow, with checks built-in to ensure business logic has been preserved, and surveys taken to confirm that business users trust the application.
Application transformation will not enable you to turn a badly written application into a good one, and organisations should be certain that the original application is a valued business asset. But if an application is deemed worthy of migration, automatic application transformation is a simple and manageable way forward.
David Ballard is a founding member of Northdoor, an IT consultancy of more than 110 people based in London. Northdoor offers lifecycle IT solutions; consultancy, design, procurement & build, implementation and lifetime support of IT environments – to all sectors.
David can be reached via www.northdoor.co.uk
At the same time, many organisations still have valued applications that are written in legacy 4th Generation Languages (4GLs) such as PowerBuilder, Centura/Gupta, and Delphi. Skill shortages, increasing support cost, inadequate performance and incompatibilities with system-level upgrades are exposing these companies to risks, and increasing the cost of ownership of the legacy software.
At the same time, the IT departments in those companies are being pressured by business users demanding software improvements that these older languages cannot support, such as requests for web services. Clearly, such organisations are thinking: ‘something must be done’.
As many development managers will have experienced, a large part of an IT strategy can involve migrating from legacy applications to modern technologies, such as .NET and Java; and as anyone who has managed such projects will testify, such re-developments can be very expensive, risky and time consuming.
It isn’t just a case of ‘translating’ legacy 4GL syntax to run under J2EE or .NET using conversion tools or compilers. These are totally different architectures and such literal translation will just deliver the old logic in a new language, bringing none of the benefits of the new architecture. Logic must be coded in a completely new structure. This coding involves an understanding of the business logic in the old application.
The problem is that the people who understood the logic of the old application will have left. Even if you can find staff to develop for both the old and new platforms, it would take them years to write fresh code. That process can be costly, troublesome, time consuming and risky. If the logic isn’t right, then the new application may be inferior to the legacy version it replaced.
The alternative is to re-evaluate the business process underpinning the old software application, and start afresh. But sophisticated business processes in sectors such as finance and logistics can take years to analyse and code.
Fortunately, another way of modernising applications has been gaining ground. Automated application transformation can deliver better results than manual rewrites, for 20 per cent of the cost.
Transformation is a sourced service combining sophisticated skilled consultancy with automated tools, developed by people who understand both the old and the new technologies. The service will deliver fully-tested, (and often enhanced) applications at a fixed price. Transformation should not be confused with code migration conversion, which often delivers low quality code by duplicating the existing application structure for J2EE or .NET.
Northdoor recommends a five-stage approach to automated application transformation:
1. Planning
Produce a full project plan including checkpoints where you review the transformed code at different stages of the process.
2. Architecture Design
Choose the technical architecture that best matches the needs of both the business and IT. The transformation consultancy will be able to guide you in this step.
3. Code transformation
Use software tools to map out the functions of the legacy code and translate them into an object-oriented structure to run under your target platform. Map out the inheritances and relationships within the business framework. The code is then converted to a universal layer and finally migrated to .NET or Java. This stage will use native functions and datatypes alongside code reassembled using an object generator.
4. Refinement
The service provider applies skilled consultants and more software tools to improve the productivity and accuracy of the transformation process. The result is a refined target application, possibly with software enhancements.
5. Testing and implementation
Test the code using a pattern-based approach and full impact analysis. This will ensure that the transformed application performs efficiently and accurately and to the agreed project plan. Implementation may now follow, with checks built-in to ensure business logic has been preserved, and surveys taken to confirm that business users trust the application.
Application transformation will not enable you to turn a badly written application into a good one, and organisations should be certain that the original application is a valued business asset. But if an application is deemed worthy of migration, automatic application transformation is a simple and manageable way forward.
David Ballard is a founding member of Northdoor, an IT consultancy of more than 110 people based in London. Northdoor offers lifecycle IT solutions; consultancy, design, procurement & build, implementation and lifetime support of IT environments – to all sectors.
David can be reached via www.northdoor.co.uk
