Client/server legacies-2

I have previously criticised IBM for their failure to provide the thin CICS client which would have made it easy to adapt 3270 terminal applications to PC clients and GUI interfaces. They however were not the only culprits.

At that time Digital was a force to be reckoned with and they never came to terms with exploitation of PC clients using their VAX/VMS systems as servers. The same criticism can also be made of Unix systems. Unix was in fact the obvious choice as the best server for networks of PC clients. This would have given a choice of hardware, reasonable scalability and an ability to mix low cost, legacy, ASCII terminal applications with PC clients. It was an excellent way to provide an evolutionary rather than a revolutionary path.
Instead of strongly pursuing the PC/Lan server market, H-P, Sun, et al gave it away, in the first instance to Novell. In turn Novell has been usurped by Microsoft Window NT, allowing Microsoft to gain control of the market and to directly challenge Unix, despite its relative shortcomings.
Netware was a simple file server (a standard feature of Unix by the way) and totally unsuited to the role of database server, let alone application server. Thus developers were forced to improvise and built applications using a thick client architecture. No experienced developer would have made such a mistake, but nor were they able to develop GUI interfaces. As a result the GUI tools dominated and they were extended to allow application logic to be coded in the PC. Many of these early applications even ran the database management software in the client, sharing only the low-level files, but these were in the main replaced by applications which shared a common relational database.
Unfortunately this is not enough, although better than file sharing. Sharing of business logic on the server is a necessity, a concept proven many times over in older host-based applications. All the experience of the past was thrown away.
But worse was to come. A thick client application requires the client program to handle the user interfacing, the business logic and the database access in one program. This might work for a very simple application but the PC bigots were by then racing ahead and writing business critical applications. Who were these people who were experts at user interfacing, business rules and database design? They don't exist. Development of a major application is a team effort. It is not impossible to allocate work to different members of a team working with a thick client program, but it is unnecessarily difficult. By using a thin client architecture, the skill requirements are divided, those working on the client having different abilities to those working on the server, etc.
But if developing an application in a thick client architecture is difficult and unnecessarilycomplex, then the problems of implementing it are even worse. How can this code be tuned? How will it scale? How do you cope with inherent network overloading? How do you fault find?
It can't get worse, can it? Unfortunately the answer is yes. Now we have reached the stage where these thick client programs, largely written in VisualBasic or C, have got to be maintained. There are inevitable changes which have to be made to the code. The original developers are difficult to find and even when they can be, they more likely than not won't be able to understand it!
If you think mainframe programs were a legacy problem, forget it. The problems were insignificant compared to the legacy nightmare now brewing up with thick client applications!< BR>
 
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.