Client/server Considerations

Today almost every business systems analysis projects must consider the use of microcomputer or client/server network as the primary residence for any new system.   At the very least they must consider the use of microcomputers to augment both existing mainframe (or “legacy”) systems and primarily manual systems.  This chapter provides discussions of the various types client/server systems, the various platform options and the impact of networks and communications.

The Changing Micro Environment

During the intervening period since it became generally available, we have witnessed an explosive growth not only in the power and capacity of personal computers but also in their use by both firms and individuals.  While they started as little more than novelty items and offered their owners word processing and spreadsheet capabilities, now many firms implement all but their largest and most data- and communications-intensive applications on them.  The increasing proliferation of software packages in all areas of business support will continue as the power and capacity of the machines grow.

This explosive growth and the place of personal computer usage on the growth curves (especially with respect to mainframe systems; (see Figure 20.1) is placing a strain on information systems management and on developers.

Because of the rapid increase in the capacity and use of these machines and the rapidly increasing sophistication of the software available for them, it is difficult to stabilize the environment long enough to do a thorough analysis and to make valid software selections.

The lack of generally accepted hardware and software standards within most firms, the vast variety of manufacturers, and the availability of specialty add-on boards make almost every machine unique.  Few firms have sufficient control or sufficient hardware and software standards in place to ensure that an application developed for one machine, and for one user can even be moved to another machine for the same user, much less to another user's machine.  The rapid changes in both hardware and software make even "standard machines" outdated almost before they are installed.

One last issue of major concern is that of transportability.  Although there are widely touted standards, and many products claim compatibility both on a hardware and software level, the analyst should be wary of any mixed system environments.  Each package is unique in some respects and tailored to specific hardware and, in some cases, to a model.  Certainly the packages are designed to work with a specific set of operating system and peripheral software products, and then only certain versions and releases of those products.  This uniqueness may prevent movement of either package, or data, or both.  This lack of transportability extends even to various versions of a product produced by the same vendor.

Microcomputer Systems

Microcomputer systems, when compared to mini and mainframe systems are relatively inexpensive, and using the same base of comparison, they are extremely powerful.  The low cost, power, and small size of these machines make them ideal for use in running low-transaction-volume single-user applications, small department systems or even large corporate-wide systems.  Applications which were uneconomic to develop in the mainframe, or even the minicomputer environments

Aside from running a vast array of personal and business applications these machines are used to:

1. Download and upload of data from the firm's mainframe systems
2. Access to other micro machines to form a local network with shared data, applications, and peripheral resources
3. Access to other stores of data and to data provider services such as public databases, ticker and news services, and other information services
4. Transmission and receipt of data from other sources
5. Provide connection to a wide variety of communications capabilities including electronic mail and the Internet

Many of these capabilities may also be combined with locally programmed application functions mainly for retrieval, transmission and transfer of data between locations.

Since their introduction in the late 1970s and the early 1980s the quantity, quality, range, and sophistication of the packages available for these small machines have increased almost geometrically.  As of this writing there are literally  hundreds of thousands of packages available commercially.  These packages cover almost every conceivable type of application and range in price from a few dollars to a few thousand dollars.  Many are available free on public "bulletin boards."

The range of special use applications is too numerous to cover in this work, nor is it our intent to do so.  It  is sufficient to say that with the wide spread use of these machines as personal workstations and small office machines has created a demand for every  type of mainframe application and mainframe facility written for the personal computer or for a client/server or network implementation.

A Definition

Client/Server refers to that combination of common use, sharable machines which provide a variety of services to a network of personal workstations know as clients.  Server machines may be dedicated to providing file storage or peripheral device management (such as printers, scanners, etc.) services, or they may also function as personal workstations.

Client machines must have some method of communication with the server machines.  The combination of clients, servers and communications devices are known as a network, or more commonly a Local Area Network (LAN).

The client machines must have some network communications and network management software installed, and must have some direct physical connection to allow the two way communications

Client/server environments are characterized by combinations of workstations, minicomputers or servers and mainframes sharing and interchanging processing, communications and data.   We view each of these as a layer or platform on which we can built a portion of a system.  The term platform has come to be used when referring to a specific processing, communications  or data layer.

Network communications

Communications between client and server, between network and network and between network and mainframe, are enabled by communications software in conjunction with associated communications hardware.  Both hardware and software are usually installed within the personal computers and the network servers themselves.   The various machines that comprise the networks machine are linked by a variety of physical lines enabling both continuous connect and dial-up communications.

Developer Tool Kits

Most vendors of operating systems, database and other packages that are used as development foundations or platforms, make available a developer’s tool kit to application developers.  These tool kits are libraries of reusable software routines, and utilities which permit the developers to incorporate into their products such items as:

1. Menu bars
2. Pull down menus,
3. Pop-up windows
4. Dialogue boxes
5. Scroll bars
6. Window creation and manipulation facilities
7. Editing facilities
8. Application feature/control icons
9. Special fonts
10. Text formatting facilities
11. Help facilities
12. File open facilities
13. File save facilities
14. File browse facilities
15. Package set-up or install utilities
16. Print set-up and print facilities

Many of these tool kits are only usable in a single environment and are intended to provide a consistent user interface (“look and feel”) across all products on a particular machine.  Other tools kits are designed to operate in a multi-platform environment, and although they provide the same features and services they do not look or operate the same way.  User satisfaction with applications may be dependent on the level to which the “look and feel” of the application is familiar and similar to other tools on their machine.

These cross-platform tool kits however make it easier to build an application in one environment and to “port” it or move it from one vendor hardware or software platform to a different hardware or software platform without substantial re-coding.  This portability is especially useful in environments where potential user’s of the same application users may have machines with different architectures, or where the potential application users may be using different operating systems.

Table-driven or Rules-driven Applications

Unlike mainframe applications which receive data in blocks micro computers receive and can access data one character at a time.  Each character entered can be processed individually and immediately.  It is this capability that enables such features as word wrap in text processing applications.  In many applications processing of data being entered is tailored to the specific data, where some is processed immediately (e.g. text for word wrapping) some are processed when the cursor moves to a new field, and some processing is only performed after all the data has been entered.  In analyzing the user’s requirements it is helpful to recognize which data can be processed as it is input as opposed to which data must be retained until all entry is complete.

For those applications where processing can be performed field by field, rules files can be built which can direct both editing and automatic population of other fields based on the contents of the entered data.  Rules files vary in complexity from simple editing to complex editing, validation and data population.

Rules take many forms, but on a simplistic basis, they are tests where each particular result or sequence or series of results causes a specific action to be taken:

e.g.

IF a

THEN action-a

THEN action-b...

IF <>a, AND b AND NOT c

THEN <>action-aa

THEN<> action-bb...

These tests may be augmented by tables which contain test results and processing directions, or module names to be performed based on the results of a specific test.

Because of the availability of local data files (resident either on the LAN server or (very infrequently) on the workstations themselves) which can be easily refreshed, and which may have the same structure but different contents based on user requirements, tables are often incorporated into application processing to provide them with flexibility, ease of maintenance and change, and to allow local variations in standard applications.

Many client/server systems have critical variables, and constants stored in these local tables and these constants and variables tailor the application to the local user.  They also allow a certain degree of local user administration and control over the application. The kinds of data that are typically stored in local tables are:

1. User names and permissions
2. User identification information
3. Local report headings and titles
4. Local screen data labels and headings
5. Local application data
6. Local user organization codes
7. Local phone numbers
8. Local e-mail addresses
9. Translation information
10. Reference information
11. Special look-up information
12. Calendars and schedules
13. Critical application control dates
14. Control codes
15. Transaction logs and other transaction records
16. Application error messages
17. Application information messages
18. Employee/customer specific information

Network communication issues:

Client/server applications exist because of the ease of  interconnection and communications between common and user workstations made possible by network technology.  The combination of network management systems, network operating systems, and network protocols facilitate the transfer of information and messages between client and server on a LAN..  File transfer protocols facilitate the transfer of large amounts of data and application programs between workstations or servers and other LANs or between workstation or server and one or more Mini- or mainframe-computers.  For an application to operate effectively in a multi-LAN, multi-platform environment, system and network software must be compatible wherever there is an interface between separate components.

Aside from the issues raised by software and hardware compatibility, network communication issues for each client/server system or proposed client/server system include the following:

1. How many LANs will the system be resident on?
2. What is the level of compatibility of the network software between LANs
3. Will the system pass data from one LAN to another?
4. What file transfer protocols will the user require to transfer or receive data from other machines.
5. How will the users access LANs other than their own?
6. Must users have an account on each LAN they must access?
7. Are the User ID and passwords synchronized across networks?
8. How will the system recognize the user?
9. How will the system restrict user access and rights?
10. Is there a common e-mail system across the LAN the system will be resident on?
11. Do all users have access to and accounts on the e-mail system?
12. How often are the system files backed up?
13. How often are the application data files backed up?
14. If there are dial-in ports to the system, what security procedures are in place to prevent unauthorized access to the system?

Client/server databases:

Almost all client/server systems, or systems that incorporate client/server architecture somewhere in the mix are based on a database package.  The issues concerning database systems in a client/server environment include:

1. Number of databases involved?
2. Size of each database?
3. Location of the data files?
4. What data can reside on the Mainframe? 
5. What data can reside on the Server? 
6. What data can reside on the Workstation?
7. What data must reside on the mainframe?
   1. Server?
   2. Workstation?
8. What are the data currency requirements of each database?
9. What are the data consistency requirements between each database?
10. Data access restriction requirements for each database?
11. Are the databases in each location resident on the same  DBMS?
12. Will the database be centralized?
13. Will the database be distributed?
14. Will the database be partitioned?
15. Will the database be replicated?
16. If the databases are distributed are the databases in each location based on the same or different data models?
17. Must data be transferred between LANs?
    1. Between workstation and server? 
    2. Between server and mainframe?
18. Must the workstations access mainframe databases directly?
19. Can the workstations process using extracts of the mainframe data?
20. How often must the local extract databases be refreshed from the mainframe?
21. Are there any procedures in place that restrict the ability to upload data directly to the mainframe database?

Client/server Issues

There are a wide variety of issues that are specific to client/server environments including:

1. Where will the data reside?
2. What processing will be performed on the workstation?
3. What processing will be performed on the Servers?
4. What processing will be performed on the mainframe?
5. Are there timing restrictions on any of the platforms that restrict processing flexibility?
6. Where will the data be edited?
7. Are the data editing processes replicated on more than one platform?
8. Is the processing to be consistent company wide or will there be several organizational variations?
9. Will the user’s be granted permission to manipulate the data in the data files, or will access be restricted to authorized processing?
10. How may users will be accessing the system concurrently?
11. What special software must be installed on the user machines for this application?
12. What special hardware must be installed on the user machines for this application?
13. What software licensing must be obtained for all concurrent users to access the system?
14. How often can the vendors of the software be expected to upgrade their products?
15. Based on past history what impact can be expected from those upgrades?
16. How sensitive will the application be to software changes?
17. To what extent will it take advantage of and be reliant on operating system and software features?
18. Will prototyping be used to design this application?
19. Will on-line help be available?
20. Will the on-line help be context sensitive?
21. Will the user be provided with look-up capabilities for frequently used codes and field contents?
22. Will the application edit input data as it is received or will it be edited at some later time?
23. How will the application handle rejected entries?
24. Will CASE products be used to design the application and to generate its code?
25. Will standard, or reusable application components be used?
26. What GUI tool kit will be used to build the application?

Although the above issues are phrased in the future tense, implying systems yet to be developed, they apply equally to existing client/server systems.

Facilities Management and Outsourcing

Because of the vast array of products, development tools, languages, and machines, no single firm normally develop client server applications using in-house staff.  The existing personnel in most organizations were trained in the development and maintenance of mainframe systems and spend most of their time maintaining and enhancing those systems.  In most cases they have received no training to upgrade their skills to use new technologies.  As a result new systems built using the rapidly changing client/server technologies are left to external consultants many of whom specialize in these new and evolving products.

Consultants, or contractors, are normally hired to build the first client/server application.  A secondary, but no less important task is to bring specialized knowledge to the firm and transfer that knowledge to existing staff.

The analyst should assess the level of education and experience in developing client sever systems and well as the level to which any of the firm’s have sufficient knowledge to modify, trouble shoot (diagnose), and maintain client server software.  Even if the firm brings in outside staff or an outside firm to build this new system, can it be supported with internal resources.

In order to use the same staff to maintain both mainframe and client server systems, a firm must \provide extensive cross-training, which is expensive, time-consuming and of dubious value.  The tendency to view older systems (both mainframe and early client server systems) as legacy systems has cause many information systems personnel to view them with distaste, and as something to be avoided, if possible.  They are attracted instead to the newer, GUi-based, client server systems.  This desire top work on newer technology has also made it more difficult to hire qualified personnel.

In response to this, and as a result of cost cutting initiatives on the part of management, many firms are contracting with specialized, or general-purpose service firms to take over the operations and maintenance of their legacy systems, or in some cases all of their Information Systems activities.  These contracts take two basic forms, both of which have an impact on existing personnel.  These forms are known as “Facilities Management” and “Outsourcing”

A Definition

“Outsourcing” is the process whereby one firm (the contracting firm) enters into a fixed length contract with another (the contractor) where the contractor agrees to operate and maintain the contracting firm’s information systems.  The Contractor firm agrees to buy all or a specified part of the contracting firms Information Systems equipment and supplies, and to hire as their own employees all or a specified part of the contracting firm’s Information Systems employees.

In some cases the contracting firm’s equipment may sold by the contractor and the work is processed on centrally operated and centrally maintained machines.  In other cases the contractor will integrate the contracting firm’s equipment into its own inventory.  The contractor agrees to operate and maintain the contracting firm’s systems, and normally charges the contracting firm for each transaction processed.  Maintenance and (in some cases) enhancement of the systems being outsourced become the responsibility of the contractor.  All operational software costs are assumed by the contractor, however the ownership of the contracting firm’s application software and it’s documentation remain the property of the contracting firm.

Normally the contracting firm retains the right to review and approve all requirements, specifications and designs for new or enhanced systems, and retains the right to refuse delivery of any such system that does not meet with their approval.  Aside from this limited review and approval the contracting firm forgoes all rights of oversight over and management participation in any decisions regarding the outsourced work.

These contracts normally provide for the contractor to provide the contracting firm with sufficient materials and updated software at the end of the contact period such that the contracting firm can transfer their applications to another contractor if necessary. 

The contracts also call for the contractor to assume responsibility for transfer and impose penalties for non-performance, slipped schedules, missed deliveries, etc.

A Definition

“Facilities Management” is the process whereby one firm (the contracting firm) enters into a fixed length contract with another (the contractor) where the contractor agrees to operate and maintain the contracting firm’s information systems.  The Contracting firm normally agrees to provide all or a specified part of the necessary Information Systems equipment and supplies, and the contractor provides its own employees and management.  The contractor operates the contracting firm’s equipment, on the contracting firm’s premises.  Some or all of the contractor’s employees may be located on the contracting firm’s premises.

In some cases the contractor may be required to provide some or all of the equipment and supplies that its employees.  The contractor agrees to operate and maintain the contracting firm’s equipment and supplies.

Facilities Management contractors may be paid for time and materials used (e.g. operating the contracting firm’s computing equipment, or operating and staffing a help desk), plus a management fee (profit) or they may be paid by the task (e.g. enhance a specific program or system, develop a new application, install and test a new piece of equipment or a new piece of software.).  In the former case maintenance and enhancement of the systems being managed become the responsibility of the contractor, but with oversight, advice and guidance and review by personnel from the contracting firm.  All operational software costs are managed by the contractor, but are paid for by the contracting firm, on an as-incurred basis.   Ownership of the contracting firm’s equipment, supplies, application software and it’s documentation remain the property of the contracting firm.

These contracts normally provide for the contractor to provide the contracting firm with sufficient materials and updated software at the end of the contact period such that the contracting firm can transfer responsibility for their applications and systems operations and support to another contractor if necessary.

The contracts also normally call for the contractor to assume responsibility for transfer and impose penalties for non-performance, slipped schedules, missed deliveries, etc.

In the outsourcing example, the contracting firm’s remaining employees are free to develop new systems, and the contracting firm has substantially reduced or eliminated many of its Information Systems personnel and equipment costs.

In the Facilities Management example, certain costs have been reduced, and a few have been eliminated.  The firm must till remain heavily involved in its Information Systems operations, and its won personnel may or may not work alongside those of the contractor on certain tasks, although for contractual reasons most  tasks assigned to the contractor are staffed and managed by the contractor.

It is very difficult for either the outsourcing or facilities management approach to address client server systems development, operations and maintenance, since they neither the data nor the processing are easily separable from end user applications and end user systems.  Since client server applications reside on the firm’s network servers and are interconnected with, and intercommunicate with the firm’s other servers and workstations, it is almost impossible to assign responsibility for them to an outside firm.