Perhaps the biggest problem however was the relatively poor state of workflow management. Only mainframe systems had significant investment in job control and scheduling sub-systems, which made it all the more difficult to integrate all those separate systems. Fortunately today many of the major management tools and specialist products such as Cybermation provide workflow management covering a variety of platforms.
A common solution to the problem of multiple databases was to make a major commitment to a completely new "ERP" package, based on a common database, SAP being the major beneficiary of this revolution. The GUI interfacing problem was attacked by introducing client/server architecture applications, exploiting the PC as a client. Unfortunately the wrong model, the thick client one, was used with totally inadequate server technology. One key feature behind the success of SAP was the realisation that the thin client model was the only way to go. By keeping the client thin and therefore undemanding they were able to achieve some success with the old single-tasking Windows 3.1, which was incapable of reliably supporting a thick client workload. They were also able to use the same clients with a variety of server platforms and were thus able to exploit the growth of Unix and Oracle. They are equally capable of supporting mainframes, DB/2, etc. The huge commercial success of SAP shows that there is often a big benefit in getting the architecture right in the beginning!
However there are a lot of good legacy systems which can be exploited in an integrated fashion rather than throw them out and start again. The most valuable applications in this respect are the solid, somewhat boring batch programs. They can be relatively easily integrated and better controlled with the modern workload management tools mentioned above. However there was a lot of value in the older "green screen" interactive applications in some cases. It needed a lot of analysis to determine if applications could be enhanced by integration and adding GUI interfaces or whether it was more economic to go for the ERP solution. There is no simple answer; it depends upon the specific circumstances. However in the early stages IBM made a massive blunder. Instead of embracing the PC world at large, they tried to control it to their advantage. 3270 terminal emulators and coax cables, the TRN instead of the Ethernet, but worst of all SNA (ideal for mainframe to mainframe, but not many PCs to host) instead of TCP/IP. Further they tried to implement distributed software, making a full version of CICS for each client PC. Eventually they saw the light and replaced this with an ideal "thin" CICS client, TCP/IP, etc., but far too late. Not all, but a lot of legacy applications could so easily have been adapted to GUI client interfacing given the thin CICS from the beginning.
The advent of e-commerce set the same process in motion all over again. This time there was more awareness of the problems and Enterprise Application Integration tools became the new way to support thin clients with older application software.< 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.