If your crown jewel has become a bit rusty over the years, it’s now perfect time to give it a new life. This article is about method we’ve used to transform legacy apps into shiny, modern cloud based web application to replace your trusted workhorse.

Most modernizations can be dealt with simpler refactoring or rearchitecting approach. The method presented here is for systems that require a bit more drastic approach; The technical platform may be nearing end-of-life – or – all the original app builders are gone, and nobody knows how the app works under the hood (you’d be surprised how many cases like this exist!). The only alternative is then to replace the app with a new one.

Rethinking the app

This article is a about the method on a high level we’ve used to re-create the business critical line-of-business apps (in short LOB apps). This may feel like a challenging – even daunting task, but this article shows you how to control both time, and the cost of the project. This is done by rethinking the app, and focusing on the essentials. The rest we automate. The method leverages the wisdom concentrated in your application over the years all the way through the process.

Where the method fits

The method is best suited for medium to large size applications, which typically consists of a database containing roughly fifty to few hundred tables, and an almost matching pair of forms ( = user interfaces) used to list, create, read and update the database. LOB apps usually contain an integration and/or business logic layer on the back, which may even be hardcoded in the user interface layer itself. The method itself is platform independent, and can be applied to apps built on once popular platforms like Oracle Forms, MS Win Forms, Visual Basic, SAP, Lotus Notes etc.

Fundamentals

The method itself doesn’t really contain anything groundbreaking or new, but the approach just seems to fit exceptionally well the issue at hand. It has already received good results on real life modernization projects, and the gains expected also increase by the size of the application: The bigger the better.

First of all, I need to emphasize that you are not doing a conversion. I say this because the estimates you may have gotten earlier about the task most likely assume that you are making one. By making a conversion I mean that everything in the old app is reproduced in the new app. You are not doing this. The key part is to rethink the app by what is important to your business. This is done by dividing the app functionality into essentials and supplementals and dealing each accordingly. This article also introduces you to the magical 80/20 rule.

Next, the method:

The Essentials

Start by making a list of the app goals – why the app is there in the first place. Describe the goals in terms of how the app supports your business. This will be your checklist for later use, to make sure everything is covered. Then proceed to study your application, and verify your goal list. The next task is to observe.

Essential user interfaces

Follow a few days how the pro users in different user groups are using the app. User groups are usually defined by your organization structure – marketing, sales, products and services. Each user group uses the application to achieve different goals – you need to find these essential goals. By observing the use you’ll very soon notice that 80% of time is spent on maximum of 20% of all screens. In my first modernization project we had roughly a 400 screen app, and most of the time users spent on less than 30 screens. The popular screens should correlate with the business goals you previously listed. Crosscheck the result the other way too – see that every business goal is now covered (they usually are).

Essential background activities

The next step is to identify the essential integrations and background processes. In real life – you should have already seen most of the key background processes by observing people using the application. Look for sentences like: “I’m cross-checking the data coming from the bank” or “I’m checking the results from last night’s mailing run”. Finding the essential background activities may require some detective work. If everything else fails, there are monitoring tools to find the information flow in/out of your application.

Setting your priorities

What you actually did in the previous steps, was that you identified the essentials: key actors (both real people and automated accounts) and the essential use cases of the system. You also have your essential business goals list, which is your requirements definition. You have probably seen a pattern developing; Your are going to make a new app, which handles these top priority use cases. By my experience, these essentials cover roughly 20% of all app functionality. By implementing this 20% the new app will already cover ~80% of the old app use, including your essential business goals. This 20% essentials is where you put most your money in (ideally – 80% of the money) and make the best app imaginable. User experience (UX) design is one of key key things here to ensure everything runs smoothly, and all unnecessary things distracting the user are weeded out in the rethinking.

Next we deal with the leftovers.

The Supplementals

The rest 80% of the application is what I call supplementals. These include (but are not limited to) configuration parameters, business rules or other runtime settings. Exceptions to the common flow of events. Things not used daily, weekly or even monthly, or used by one or few users only. You may have to juggle a bit on where to draw the line. I mainly use two criteria: If it’s runtime behavior configuration of the system – it’s clearly supplemental. If not, I judge the case by it’s use frequency and number of users affected. And maybe later I ditch the screens (and functionality it contains) back to supplemental basket. You don’t have to decide immediately.

The strategy with the supplementals is to minimize the effort, cost and time. First weed out obsolete functions and data – believe me, there will be plenty of this cumulated in your app over the years. Next; there is no rules: Convert, dirty code, copy-paste – whatever it takes to get rid of the remaining stuff. A good approach: Give the architects planning the transition a hard cost limit: The supplementals may cost 20% of the essentials budget, and they’ll make the right decisions. Give them a tip that you are going to use Model Driven Development Method and Tools to do the dirty work for you, while you focus on the important stuff.

Hey – What just happened?

Let’s summarize. First you limited the scope of actions to the essentials – max 20% of the original app functions. This in turn reduced the costs to about one fifth of the original estimate. All things considered and leftovers taken care of, I usually expect roughly 50% cost and time cut using this method. This figure will most likely keep even if you made the best app imaginable to support your business goals – having the best UX, modern graphics, state of the art backend etc. Minimize the effort on supplementals with automated tools to get bug free and quick solution.

That wasn’t too difficult, or was it?