Five Things to Keep in Mind before Modernizing your business Desktop Applications for Web, Cloud or Mobile platforms

Monday, 25 September 2017 07:06
5 Things to Keep in Mind before Modernizing Web Cloud or Mobile platforms
  1. Trust me, your app will need a certain level of reengineering if you really want to reap the benefits of the new Web, Cloud or Mobile platforms. Why?
Mind you, your good old desktop application – whether Visual Basic, PowerBuilder, .NET, Delphi or some version of Java desktop – was written most probably sometimes ago during the last couple of decades. Facing the modern technologies, these applications are lagging behind:  They were written for outdated infrastructure and operating systems like older versions of Windows; They were written using languages and platforms that are either already out of support like Visual Basic or frameworks that do not evolve as fast anymore and see fast migration of developers to more modern platforms, like PowerBuilder, Delphi and others; They were written by developers who had been pushed to deliver the application here and now back then – even if they were the visionaries at the time, they could not foresee the way software will evolve over so many years or foresee the revolution of the web, cloud and mobile.

Consequently, there are wide architectural gaps between a monolithic desktop application and a Web or PaaS cloud application, so the application will not run as is on neither.  Even if the desktop application will be rationalized to run on virtual infrastructure (IaaS for example), "old" code will still have to be maintained and the user interface will have to be reengineered especially for a multi-transactional application to really provide an acceptable user experience and accessibility from multiple devices.

The old-era obstacles require a massive application reengineering, including redoing of its user interface, if you seek to truly reap the benefits of native Web, Cloud and Mobile platforms and provide acceptable user experience.

 

  1. Do you really know your options when it comes to application reengineering? Familiarize yourself with the options before you decide.
There are 3 main options and some gap stoppers such as virtualization or containerization, which are temporarily bridging solutions that will not provide an adequate and scalable user experience. If you seek to provide native, scalable and maintainable solution, your options are: 1) Redevelop the application; 2) Replace it by a modern package application; 3) Modernize it.

A study conducted in 2010 by the Standish Group has found that application modernization projects have the highest likelihood of being completed on time, on budget and with all critical features included when compared to alternative approaches. The following tables clearly demonstrate the core difference between these 3 application reengineering options:

 

Resolution Results Comparison

The following table shows the likelihood of resolution of the project in all three cases:

Resolution/Project

1: Application development

2: Package application

3: Application modernization

Successful

4%

30%

53%

Challenged

47%

54%

39%

Failed

49%

16%

8%

 

Expected ROI Comparison

The following table shows the expected return on investment in all three cases:

ROI

1: Application development

2: Package application

3: Application modernization

High

11%

34%

52%

Average

66%

57%

37%

Low

23%

9%

11%

 

 

  1. Be careful if redevelopment is the option you lean towards - experience shows that a mistake here could be fatal for your organization.
Old code is often regarded as a pile of ugly mess that programmers would rather dismiss altogether and start over. Indeed, it's harder to read code than to write it - what makes the old code not so easy on the eye happens to be the very attribute that makes it valuable: bug fixes, feature additions, and architectural changes that result from long-term usage and maintenance of the application. When one decides to redevelop or rewrite from scratch, one is likely to lose the knowledge and functionality hidden in all that legacy code. Rewrite at the expanse of discarded legacy code could be dangerous when applied to large scale commercial applications and too often proves to be a strategic mistake.

And this is what Joel On Software, a guy with a lot of experience, has to say on legacy code rewrite in his blog: " they did the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch"

Why does he say that? Because too many companies that took the decision to rewrite legacy code, found the hard way that it was the wrong decision. You are welcome to read more about it.

 

 

  1. Whatever it takes to pre-assess the task you are about to face – it might be the best investment you ever make.
With so many layers, code additions, bug fixes, generation of developers and owners, poor or no documentation – there is only one acceptable solution: reverse-engineer the app and map the gaps to the target platform.

Is it imperative? Absolutely. Do not start a journey if you are not sure that you know where you want to go and how you should get there. Yes, nowadays you can really do it using tools to help you.

One of these tools is GizmoxTS Analyzer. It is based on a unique algorithm for semantic-holistic code understanding – the legacy application is read and holistically represented. Unlike with the traditional ‘line by line’ processors of yesterday, the holistic approach allows re-architecting to a new platform or framework, while preserving the semantics (business rules, data relationships and flow, UI element functionality).

One important benefit of holistically understanding the legacy application is that it removes the need to reverse engineer the legacy application’s business functionality – thus considerably reducing the cost, duration and especially the risk of the modernization effort.

The semantically explicit internal representation of the legacy application serves as the basis for the machine-driven process to automatically perform a large proportion of the re-architecting. Through a process of virtual continuous compilation, the software guides the user – in most cases a software architect – through completing, refining and modifying the migrated application.

 

 

  1. Set measurable milestones! Define them clearly, and get your vendor or service provider to commit – Fixed, no T&M! 
Here is an example of building a modernization project  with measurable milestones. Coupled with tight schedule it should become a plan to commit to, follow and monitor:

Setup

Initially, a stable source and baseline environment is setup by loading the legacy code & configuring the Automated Rewrite Tool.

 

Analysis & Automated rewrite PLAN

Next, the sources to target gaps are identified via a virtual compiler and other Automated Rewrite assessment and query tools. The automated Rewrite expert then presents and discusses with the customer team the optional target components and code patterns. The deliverable is an agreed plan.

Refactoring and standard mapping

Once a plan is in place, the next phase includes refactoring and mapping of code fragments and components to the target environment using standard or common custom mapping rules. Stubs are generated for non-common specific mappings.

 

 First compilation & code quality tests

At this point, the transposed code compiles. Code might include stubs for custom extensions, components and custom rules. This phase also includes Initial code quality auto-testing.

 

Custom extensions, components and rules  

Custom extensions, components and mapping rules are created for non-standard types and members by either mapping legacy 3rd party controls to .Net equivalents, or by implementing specific code in the generated stubs. This phase can start earlier, in parallel to the standard refactoring and mapping phase.

 

Final compilation (Developer tests)

The final version of the transposed code compiles with all custom stubs mapped and ready for delivery tests. Some additional edits (post-transpose actions) may be done at this stage.

 

QA phase

- Delivery Tests/Bug Fixing - According to defined scenarios and success criteria.

- Acceptance Tests (followed by final bug fixing) - According to defined success criteria.