Going GUI: breaking the Windows pain barrier

Two years ago, PACE decided that they were going to have to grasp the GUI nettle and redevelop their application portfolio for a Windows environment. It proved more difficult - and more expensive - than they imagined. John McGrann recounts their experiences and offers some valuable advice for other software developers contemplating a similar move.

The biggest single issue facing the Pick community today is going GUI and client/server. It is a question of survival, unless your Pick application is properly GUI-ised, integrated with the desktop and Internet ready it will not survive much beyond the millennium. This problem threatens the survival of the MultiValue model itself as applications are completely re-written for non-MultiValue environments and it was the richness of applications that made the MultiValue model so enduring.

As a Pick software house developing and marketing applications which ran on UniVerse, Unidata and Pick, the commercial reality of falling sales and the exclusion from many short lists because of our lack of a GUI interface and client/server architecture made us face this issue two years ago. After careful consideration and a six man-month evaluation of the options available - including SB+, UNIFACE, Delphi etc - we decided for technical and marketing reasons to go for all Microsoft products i.e. NT, Visual Basic, Access/SQL Server. I hasten to add that I am not a fan of Bill Gates even if he is a latter-day Dick Pick type character without the sense of humour.

This was not an easy decision. On a purely business basis I was loath to move away from the flexibility of the MultiValue model which meant low cost development, ease of change, superb performance, scalability and low administration. Most of all I was not keen to throw away all the skills, experience and 40+ man years of MultiValue code but it was just not feasible to go proper GUI Client/Server without a total re-write. We ruled out interim solutions such as SB+, screen scraping with terminal emulators etc because we were not sure how much life these would really add to the product, making any investment risky. Furthermore such an approach failed to address the issue of IT staff retention, which was fast becoming an issue in that we began to find we could not attract the new staff needed for growth.

Based on a further 3 months of evaluation with Visual Basic we budgeted £90,000 and nine months to re-write our core suite of Financial Ledgers. Some £320,000 poorer and two years later we are a lot wiser and have a magnificent product with spectacularly enhanced usability, functionality, desktop integration and I-Net ready.

What have we learned from this exercise? We have learned that:-

• It takes 6 months to convert a good MultiValue programmer to a proficient Visual Basic programmer. During that 6 months they have to immerse themselves in VB. Expect to get about 1 month’s worth of VB code for these 6 months of work.
  
• There is at least 300% more coding in GUI Client/Server applications in comparison to MultiValue programs. This is needed to manage event handling, applications flow, data access and management.
  
• Testing takes 10 times as much effort in GUI Client/Server because the event-driven nature of such applications makes testing much more complex.
  
• The design of the database and the applications architecture is a non-trivial task and takes much more thought and planning. In fact it is of a different magnitude when compared with the MultiValue approach. It requires a senior person to adopt the role of database designer for a significant amount of time.
  
• The design of the GUI screens is a major task. Designing good easy to use, intuitive GUI screens is an acquired skill which takes green screen programmers a long time to acquire. Microsoft’s Windows Interface Guidelines for Software Design manual, which is the basis for good GUI design, is a 556-page book. As a result screen design takes considerably longer and requires a lot more re-work. On one occasion during the development of our nominal ledger we scrapped 6 man weeks of work because we got the GUI design of one form wrong.
  
• Deployment of the applications with client/server architecture is a lot more onerous when it was only a server based MultiValue environment. You need to be sure each client has the latest copy of the client programs for a start when you are installing changes and fixes.
  
• It is much more difficult to make changes and amendments particularly to the database, changes take a lot longer to do and require considerably more testing. This emphasises the real cost benefit of the flexibility of MultiValue environment, which is totally lost, when you move away from it.
  
• The structure of our development resources changed dramatically because of the need for staff to specialise in certain areas. We no longer have a development team made up of generalist Pick developers with a good knowledge of a broad range of applications to whom you could give an outline spec (on the back of a fag packet) and who would specify the programs and database, develop and test programs and then test the application and install it (maybe even document it).
  
  Now we have formal roles for Applications Analysts, Database Designers, GUI Designers, Documentors and testers. In having to structure ourselves like this we have lost a lot of the labour flexibility which has meant that we have had to be much more careful in planning our work. As a result we have less productivity from our programming resources.
  
• Finally we estimate that writing a GUI Client Server using Visual Basic, NT and Access or SQL Server takes about four times as much resource and cost as the same application in the MultiValue environment.

We now have a suite of GUI Client software of which we are very proud and which will ensure our business can continue to survive and we can build on. However with three other suites of software to re-write and without the ability to generate the revenue needed to re-develop them, I decided to review the migration options for these suites of software.

Earlier this year I became aware of a product call ADAPT through a white paper from Data General. We got a copy of the product in April of this year and we have been carrying out a full evaluation. The evaluation is due to be finished in mid July but from our experience to date the product looks very exciting and certainly seems to offer a better route to GUI Client Server than total re-development.

ADAPT is a rather unique product specifically suited to the migration of MultiValue server-based applications to GUI Client/Server software. ADAPT’s key feature is that it preserves about 50% of your existing application, the server side, in the MultiValue environment and continues to work with the existing MultiValue database preserving all your data and most of your flexibility. ADAPT is a proven product having already established a track record in the COBOL migration market.

The ADAPT GUI client/server migration solution has two main elements, the ADAPT ADE and the Pick/Autogration Tool Set. The ADAPT ADE is a fully Microsoft-compliant GUI development tool for developing the client side of an application and enabling the hooks into the server side. The ADAPT ADE is used to develop the GUI screens and screen flow; it automatically adheres to the Microsoft GUI developers Guidelines making screen/form design much easier.

The ADAPT ADE has a unique and very exciting user-centric approach to design in that it starts the design with a Business Process Map, called the BPmap™, which identifies all the business processes within the scope of the application. Each process in the BPmap™ business process map can then be de-composed into separate tasks via the Activity Tree in ADAPT. Each task maps onto a screen form built by the GUI. The linking of Business Processes directly to an application has very significant benefits and tremendous opportunities for all users, developers and software houses.

The Autogration Tool takes your existing MultiValue BASIC code and analyses it, identifying which code is redundant (screen presentation etc.), which is potentially client-side code (e.g. field validation) and which is server-side code and then converts the client-side code to Visual Basic and changes the data reads and writes to the MultiValue databases to corresponding Client API calls (we are using UniVerse Objects). The server- side code is encapsulated for calling from client routines and lastly there is a simple manual process of joining the client Visual Basic to the GUI. The database remains untouched and intact.

Our evaluation of ADAPT involves using it to migrate our PCR package for which we already have a re-write project under way. To date ADAPT looks most promising, based on the metrics gained from our evaluation to date. Using ADAPT we will retain about 60% of our existing code and take 6 man-months to migrate the existing PCR to GUI Client/Server as opposed to 18 man months to re-write it using VB. It is almost impossible to tell the difference between the ADAPTed PCR Screens and the re-written Visual Basic PCR screens.

We now recognise that we were among the earliest of Pick developers to take the decision to re-write a significant application for GUI Client/Server. I believe that based on our experience with ADAPT to-date that had ADAPT been available then we would have gone down that route and it is almost certain that our remaining packages will be ADAPTed as opposed to being re-written.

John McGrann

PACE is a 15-man software house supplying applications software to the food industry and consultancy and support for multivalue migrations. John McGrann, MD of PACE, has worked in the PICK market since 1979, working with CMC, Memory Ireland, Microdata and MDISL before setting up PACE in 1988.

Last Updated: 30 June 1999

| Home | | What's New | | News | | Articles | | Workspace | | Pick of the Web | | InfoCentre | | Parting Shots | | About Us | | Subscribe |