Software Modernisation - UI options during modernisation

Posted by GarthBond on 27-Jan-2015 14:14

Hi Folks,

Automate is a DMS (Dealer Management System) software provider in Africa and we are busy with a software modernisation project.

The decision we made is that we would not go a big-bang approach and we would do incremental modernisation steps and every 2 or 3 months, we would download these changes into our production system.

We are also changing the UI and moving to a 3-tier OERA architecture based on SOA. Our challenge is how do we do incremental system improvements without changing the UI radically during this process and confusing our customers as a direct result. 

Can we for instance combine both legacy screens and new designed screens at the same time without totally confusing our customers? We have two trains of thought. Namely, replace all legacy screens with the SmartComponents UI and keep the exact same screen structure by essentially give it a face-lift, or redesign the screens and workflow, but then it requires a massive training / learning curve to our existing customers, which may frustrate them during our modernisation project.

Would be interested to know if any of the Progress Community members have faced a similar scenario and how you dealt with it.

Regards

Garth Bond

All Replies

Posted by Thomas Mercer-Hursh on 27-Jan-2015 14:41

There are a couple of options here.  One, that I think you alluding too, is that you basically provide a new UI envelope for the whole application, but where most of the rest of the screens are hosted inside this envelope in their initial form.  Given that you are using Smart Components, I believe Mike has a semi-automated way to do this so that it can be done fairly quickly.   The one qualification I would put on this is I am not sure that his tool will bridge your architectural differences.  That may require its own transition.

Beyond that, there are two usual strategies.  One is to convert one module at a time, where "module" means a collection of functions typically used by a particular type of user, e.g., the service desk.  The other is to work your way through the screens where there is the most value in making the change, leaving routine file maintenance functions and the like to the end.

Posted by GarthBond on 28-Jan-2015 00:46

Thanks Thomas,

Agree with your points.

We decided not to follow the approach of module-by-module for various reasons, so it is incremental modernisation, the outcome of which is put into bi-monthly PL Releases.

So our challenge is how best to coincide with both legacy and new UI and business processes at the same time.

Regards

Garth

This thread is closed