To split or not to split? Tools little help answering - includes related article on Cooperative Solutions Inc - Client/Server Computing: Development Tool Status Report - tutorial

Software Magazine, Feb, 1991 by Paul Korzeniowski

Chevron Canada Ltd., Vancouver, B.C., is spending $7 million to build a new set of LAN sales performance applications. The applications will link Canadian oil distributors to Chevron's Vancouver headquarters, and replace a set of 20-year-old batch processing applications.

Chevron decided to rewrite the applications in the spring of 1989, according to Bill Soper, a project manager at the oil company. "The old applications simply could not keep pace with our business requirements," he stated. Users were complaining that it was difficult to access needed information."

The company was open to many alternatives, and all but a LAN solution fell by the wayside. Chevron viewed IBM's DB2 as too expensive and IBM's AS/400 as too proprietary. Digital Equipment Corp.'s Rdb software came close to meeting Chevron's requirements but lacked amenities, such as a full set of application design tools, according to Chevron.

Next, Chevron chose the OS/2 operating system from Microsoft Corp., Redmond, Wash., as the foundation for its applications. Chevron did so because the operating system supports a workstation graphic user interface (GLT) and various database management servers. After examining database management servers from Gupta Technologies Inc., Menlo Park, Calif.; Oracle Corp., Redwood City, Calif.; and Sybase; Chevron chose Sybase. According to the company, Sybase offered the best performance and was most able to ensure that users worked with up-to-date information.

At the beginning of 1990, Chevron installed prototype applications at the Vancouver office. The company plans to have the entire project completed by the spring of 1992. At that time, the applications will run on 65 microcomputers at company headquarters, and process 165,000 transactions each month.

Chevron felt comfortable placing mission-critical information on local-area networks, but other companies are apprehensive. "LAN security is not as robust as mainframe security," said John Canestraro, vice president of product strategy at Easel Corp., a Woburn, Mass., software firm that sells frontend workstation software.

Even LAN proponents know security risks exist. "With a mainframe, security comes from limited access to the machine," said Shearer at Tex/Con Oil and Gas. Because companies can't physically secure each microcomputer, there are instances when you are not sure who is working with corporate information."

MAINFRAME AS SERVER

The numerous limitations have convinced many firms not to simply downsize mainframe applications, but instead link mainframes to microcomputer LANs. In many cases, the mainframe acts as a server and houses important corporate data. The microcomputer works as a client and provides the user with access to needed information.

Observers generally agree that number-crunching activities, such as searching a large database, should be completed on the mainframe server and less complex items, such as support for a GUI, should be done on a microcomputer client.

Sometimes, boundaries between the two systems are clear. "If you have to pull 10 records from a 10,000-record database, clearly the search should be done on the server and the information sent to the client workstation," said Hartley at American Airlines. You do not want to send 10,000 records over the network."