Moving legacy applications to the cloud is an issue many ISV's and Business IT departments are grappling with today. Although there are a variety of technologies available to create new cloud applications, engaging in a monolithic rewrite of a legacy application in new technologies may not be a viable option both from a cost and time-to-market perspective. In addition, the modern target platforms for the next generation of the legacy application is much more complex than the original target platform when the legacy application was first built. New target platforms are characterized by multi platform access, device independence and mobile enabled user interfaces.
There are two options that are worth considering to address this challenge, neither of which requires a rewrite but both can be supported in agile best practices and continuous deployment.
Transposition versus Rewrite
The first option is to approach the legacy application as a real estate developer might approach an old house purchased as an investment. Although I am not a real estate agent I would assume the questions might be similar to questions we ask when considering the evolution of a legacy application to new target environments. Is the house in such bad shape that it must be torn down and built back up from scratch, ie is it riddled with termites, is the foundation cracked. Also combined with this analysis, is there really a budget to build a new house and still be profitable?, was there time factored into the investment to build a new house, or was a quick turnaround built into the investment returns. Alternatively if the answer is no the house isn't a tear down, then the question is what needs to be done to the house on a more limited time frame and budget to modernize it to have the features that sell in the new real estate market of today?, ie does it need the kitchen remodeled?, should some walls be removed to increase the size of the master bedroom?.
Now lets put these questions in the context of a legacy application. Do we need to start from a clean slate because nothing is salvageable, ie the application is so buggy and unpredictable with crashes so frequent as to render it useless. In addition we need to ask if we have the budget to rewrite the application and does the time to market fit in the investment case. Alternatively if the answer is no, then the question is what needs to be asked what can be done to the legacy application on a more limited time frame and budget to modernize it to operate in the new target environments of today. And that is the idea of transposition, a unique paradigm that combines concepts from migration, rewrite and virtualization combined with a set of supporting technologies and integrated development environments into a single solution that reduces the time to market and budget required to transpose the legacy application into a new modern application that can run on the modern target environments of today. The leader in transposition techniques, a company headquartered in Israel - GizMox, refers to transposition as 'computer aided rewrite that reproduces an application that runs on one computing architecture, to an equivalent HTML5 application that will work multi-browser on multiple devices.
The transposition magic is contained in their product Instant CloudMove and Visual WebGui. Below is the full transposition process.
 |
| The Transposition Process |
Following this assessment report GizMox offers a more thorough analysis of your application which outlines accurate costs & establishes a detailed work plan including recommended personnel and Time to Market. Also offered is a free trial of the Instant CloudMove which actually transposes the application so you can develop your own Proof of Concept (POC) or you can contract GizMox to develop a POC based on a representative module of 10,000 lines of code, GizMox will even help you create a representative module from your application..
The Instant CloudMove set of tools transposes most of the original legacy application and user interface code to its new (web-based) environment automatically, approximately 80-85%. The transposition is executed by a sophisticated engine that translates source language into intermediate target language. By transposing into intermediate language the original legacy application code and the target code are isolated from each other, so work can continue on with the original legacy code and be translated back in should a merge be necessary eliminating the need for code freeze of the original source application. This frees the transposition team to work iteratively at their own pace to deliver the highest quality application. It's also important to mention that using intermediate code enables a 'push button' generation of code for the desired target environment. So working the intermediate code new retargeted applications can be generated at any time.
And because it integrates with Microsoft Visual Studio IDE, it provides the flexibility to customize, upgrade and add pieces of code as you go. There are even sophisticate pattern matching capabilities you can use to create your own mapping packages for the 15-20% of the code that is not automatically transposed.
Using simple drag and drop actions, you can redesign legacy user interfaces to new front-ends such as HTML5 using another GizMox product Visual WebGui (VWG). VWG extends ASP.NET APIs to support rich user interfaces and incorporates Ajax connections for further enhancements. By targeting VWG, you are practically targeting an enhanced ASP.NET application with an HTML5 user interface. Once your application is transposed into VWG HTML5, you will be able to inherit part or all of the generated forms and redesign them into mobile and tablet form factors using the VWG Visual Studio integrated designer.
I have been involved in many rewrites of legacy applications for many target environments over the years and these are the kind of tools and translators that each development team would create in-house to 'transpose' the legacy application to run in a new target environment. In most cases legacy applications have embedded rules and calculation engines and in the extreme cases the engines have a time dimension that is built up over years. Rewriting these rather than transposing them can be a risky proposition, especially when the customer can't tell the difference.
Here are some tables from the GizMox site that make the case for transposition over standard rewrite.
Comparing Instant CloudMove to a standard rewrite.
Factor
|
Standard Rewrite
|
Instant CloudMove
|
Quality of code
|
High
|
High
|
Level of automation
|
Low
|
High
|
Time to market
|
Long
|
Short
|
Ability to estimate resources, costs and completion times
|
Low
|
High
|
Built-in capability of adaption to tablet and mobile 'touch' devices
|
Requires multiple skillset
|
Built-in drag 'n drop simplicity,
|
Level of MS Visual Studio integration
|
Varies
|
Very high
|
Risk
|
High
|
Low
|
Cost
|
High
|
Considerably Lower
|
Below is a dollar-for-dollar comparison of smart rewrite against traditional rewrite showing rate of progress and cost per line (LOC)
Source
|
Rate of Progress in Lines of Code per Developer per Day
|
Cost per Line $
|
Cutter Consortium
|
185
|
12.3 - 18.5
|
Gartner
|
170
|
N/A
|
BNA Software
|
284
|
N/A
|
Tactical Strategy Group
|
50
|
$15
|
Forrester
|
N/A
|
$6-23
|
Fedora Linux
|
N/A
|
$52
|
HP
|
100
|
$10-30
|
Gizmox Instant CloudMove
|
3,000 - 6,000
|
$0.35 -1.2
|
Published Figures for LOC a Day and Cost per Line for System Rewrite
No comments:
Post a Comment