Technology Proof of Concept (Sample)

An example of documentation prepared to support an architectural assessment completed for a

small system. This document is a good example of how the methodology can be employed on a
project of any scale. Due to the small scale of this project, three documents were combined into
this document: Current Situation Assessment, Requirements Definition, and the Proof of
Concept evaluation.

EXECUTIVE SUMMARY

The Technical Proof of Concept phase is concluded with the presentation of this document.

The results of this phase are clear: The consultants feel that Clipper is a viable tool for
development of the new AAA system which will replace the current AAA application at the
XYZ Company. This opinion has been reached after a two-week investigative process which
involved a five-day site visit to the XYZ, followed by consultation with industry experts in the
areas of systems development, networking, and database management systems.

The only major inhibitor to using Clipper is its performance when providing on-line update
access to large files. The volume of data for tracking ‘movements’ is very large. However the
performance impact can be minimized by transferring data to off-line read only files for report
generation.

Development in Clipper offers a clear advantage in terms of maintainability. Clipper is an easy to

use language which is known by many developers. Increased maintainability results in greater
opportunity for evolution of both the application and its use by the XYZ. Since Clipper uses an
industry standard X-base file structure, the XYZ is strategically positioned to take advantage of
other development tools in the future while maintaining their investment in existing data bases.

1. INTRODUCTION
The XYZ Company’s (XYZ) current AAA system (AAA), in production since July of 1990, was
originally intended to enable a reduced staff in the Administration Section to efficiently and
effectively process a large volume of claims; this goal has not been achieved. In addition, the
current AAA lacks important functionality, and does not provide effective use by multiple
departments.
The current AAA was developed in an environment, ZIM, which is not familiar to many
computer specialists. As a result, enhancements to the existing system are not easily
accomplished and in many cases have been abandoned.

In April of 1993, the XYZ issued a request for proposal (RFP) for development of a new AAA to
meet its requirements. They identified a development environment using Clipper to ease
implementation of any future requirements.

With extensive experience in the Clipper environment, the consultants were concerned that a
solution developed with Clipper would not support a mission critical application such as the
XYZ AAA.

In response to the RFP, the consultants proposed a technical proof of concept as the first step
leading to development of the new AAA system.

1.1 Purpose of this Document

This document details the findings of the XYZ Company AAA System Technical Proof of
Concept phase.

The technical proof of concept is the first phase in development of a new AAA system for the
XYZ. The primary objective of this phase is to evaluate the viability of a Clipper solution.

The preparation of this document followed an on-site technical investigation of the XYZ
environment, the current AAA, and requirements for the replacement system.

1.2 Factors Considered in Evaluation of Clipper

The following factors were considered in the evaluation of Clipper as a suitable development
tool for the AAA System:

XYZ’s hardware and software environment;

XYZ development standards;
requirements for the new AAA System;
current and anticipated data volumes;
system performance requirements;
access requirements for system users;
application maintainability.

1.3 Document Structure

This document is organized in the following sections:

Section 2: SUMMARY OF CURRENT ENVIRONMENT

This section addresses issues including internal and external systems interfaces, the technical
environment, and operational standards and policies in describing the current XYZ AAA.

Section 3: EVALUATION OF CURRENT ENVIRONMENT

This section evaluates the current environment in terms of its strengths, weaknesses, and
opportunities for improvement.

Section 4: REQUIREMENTS FOR NEW AAA SYSTEM

This section describes issues surrounding development of the replacement AAA system,
addressing existing technical problems and new technical requirements .

Section 5: EVALUATION OF PROPOSED DEVELOPMENT ENVIRONMENT

This section discusses an evaluation of Clipper as a tool for development of the new AAA.

2. SUMMARY OF CURRENT
ENVIRONMENT
2.1 Existing Applications Environment
2.1.1 Overview

The XYZ Company (XYZ) administers the Assistance Program (AP). This program is designed
to provide assistance to shippers and manufacturers located in the Region, by reimbursing
carriers for reductions in rates.

The program divides carriers into four major groups:

The Rail Program

The Basic Westbound Program
The Selective Westbound Program
The Intra Program

Before becoming eligible for assistance, participants make application to the Company. Upon
authorization, the participant is added to the list of authorized carriers, and claims may be
processed.

Claims are received by the Company for carriers requesting reimbursement under the program.
Before claims are approved for payment they must be verified. This verification will ensure that
the claim is correct, and that the movements and commodities meet the requirements of the
specific program group.
Once claims have been verified and approved for payment, the Finance and Administration
section carries out the payment process through the Payment System (PS).

Based on information gathered during the claim verification process, a carrier may be audited.
Results of the field audit may be fed back into AAA in the form of comments regarding a
specific carrier.

2.1.2 Major Data Stores

Volume of data is one of the major factors which will influence the viability of a system
developed with Clipper. The following table summarizes the volume contribution of the data
stores which provide the greatest volumes of data to the current AAA.

CURRENT SYSTEM: VOLUMES IN MAJOR DATA STORES

Entity Size (bytes per Number of records Data Volume
record) (MB)
Participant 247 8301 1.96
Carrier 60 8120 0.46
Application 2066 8192 16.14
Certificate 2025 7959 15.37
License 2116 39,795[1] 80.31
Claim 154 71,655 10.52
Payment 128 71,019 8.67
Total 133.43

Participants: All organizations involved in the program. These organizations include carriers
(authorized and pending authorization), agents, and banking institutions, among others.

Carriers: All carriers that have been authorized to participate in the program.

Applications: All applications for participation in the program that have been received by the
XYZ.

Certificates: All certificates that have been issued to authorized carriers.

Licenses: License information for every carrier.

Claims: All claims that have been received by the XYZ.

Movements: Contains information on the movements which make up each claim. This data store
is not used by the current system.

Payments: All claim payments.

2.1.3 Internal System Interfaces

Payment System (PS): Payment data is exported from the current system, producing a text file
which is imported into PS by XYZ staff.

Audit Control Language System (ACLS): Various data necessary to perform a field audit on
randomly-selected carriers is exported from AAA, producing a text file which is subsequently
imported into ACLS by XYZ staff.

Payment at Year End Process (PAYE): Special payment “commitment” and “financial code”
numbers are specified in AAA. These numbers will indicate, following payment import into PS,
that payments should be made according to the PAYE.

2.1.4 External System Interfaces

Carriers: Carrier information is currently received in hard-copy and input into AAA by data-
entry staff.

SUMMARY OF CURRENT USERS

Business Group User Type and Description Number of
Users
Administration Certification: Data entry and verification of 1
applications, certificates, and licenses.
Claim Control: Claim data entry. 1
Verification: On-line claim verification 14
(“desk audit”) via ad-hoc query.
General: Modification and Reporting. 1
Supervision: On-line claim authorization, 2
ad-hoc query access.
Management: Payment authorization, ad-hoc 3
query access.
Field Audit Field Audit: Field audit of carriers using data 4
imported into ACLS, AAA query
Supervision: AAA query 1
Management: AAA query 1
Finance Generation of payments and PS import. 2

2.1.5 Current Users

The following table will summarize the current AAA user distribution at the XYZ.

2.2 Existing Technical Environment

2.2.1 Hardware Platforms
At XYZ, all machines are Intel-based and vary in configuration and capacity from 1 MB 286/12s
to 16 MB 486/66s, as described in the following table:

Purpose Make and Model Configuration Quantity

File Server DTK 486 DX2/66i 16/1.2 GB 1
mirrored
(server OFFICE) KEEN-3334
3 x 16-bit NIC
Application/Database ALR 486 DX/50e 16/2 GB 1
Server
Business VEISA mirrored
(server Head Office)
3 x 16-bit NIC
Application/Database Zenith 386 SX/33e 8/300 MB 1
Server
Z-386/33E mirrored
(server REGION)
2 x 16-bit NIC
Communications Server Tandon 286/12MHz 1

2 x 9600 bps modem

Mail Gateway Epson Equity III+ 286/12MHz 1
Remote Access Gateway Epson Equity III+ 286/12MHz 2

9600 bps modem

AAA Workstation Tandon 286/12MHz 1/No HD 37

8-bit NIC
Field Audit NCP 386 SX/25 4/120 6

and General W/S 8-bit NIC

Personnel DTK 386 SX/25 8/120 2

and RIMS W/S 8-bit NIC

Payment Workstation digital 486 DX/33 4/120 2

DECpc LPv 433d 16-bit NIC

Field Audit Laptop Toshiba 386 SX/25 1/120 3

T3200 8-bit NIC

PS Workstation Clone 486 SX/33 4/120 2

16-bit NIC

9600 bps modem[2]

 Purpose Make and Model Configuration Quantity
Field Audit Laptop Toshiba 486 DX/33 4/120 2

T4100 Xircom Pocket Ethernet

Network Admin digital 486 DX2/66 12/250 1
Workstation
DECpc LPx 466d2 16-bit NIC

2.2.2 System Software

The XYZ computing environment features a Novell LAN with DOS-based workstations.

Machine Operating System Application Software

Server OFFICE Microsoft MSDOS AAA
6.0
WordPerfect 5.1, WordPerfect Office 3.1,

Lotus 1-2-3 (2.2, 2.4, 3.1), dBase III+,

Novell Netware 3.11 TimeLine 5.0, R&R Report Writer 4.0,
(100 users)
Hotel Directory System,

Harvard Graphics (2.3 and 3.0)

Server Head Office Microsoft MSDOS
5.0
Off-line access to AAA data.

Novell Netware 3.11

(100 users)
Server REGION Microsoft MSDOS ACL, RIMS
5.0

Novell Netware 3.11

(100 users)
Communications Server Microsoft MSDOS Netware Asynchronous Communication
5.0 Services
Mail Gateway Microsoft MSDOS WordPerfect Office
6.0
“Connection Server”
Remote Access Gateway Microsoft MSDOS Carbon Copy
6.0
Remote Access Gateway Microsoft MSDOS PC Anywhere
 Machine Operating System Application Software
6.0
AAA Workstation Microsoft MSDOS
5.0

Microsoft MSDOS
6.0
Field Audit Microsoft MSDOS
6.0
and General W/S
Personnel Microsoft MSDOS
6.0
and RIMS W/S
Payment Workstation Microsoft MSDOS
6.2
PS Workstation Microsoft MSDOS DSS Communication package.
6.0
Field Audit Laptop Microsoft MSDOS WordPerfect 5.1, Lotus 1-2-3 2.2
6.2
Network Admin Microsoft MSDOS Microsoft Windows 3.1
Workstation 6.2

2.2.3 Communications

The XYZ internal environment consists of a Netware 3.11 segmented ethernet LAN. LAN
communication is via Novell’s SPX/IPX protocol over thin ethernet (10Base2 thin coaxial
cable).

A communications server provides remote dial-in to corporate systems via two dedicated
modems.

Access to corporate e-mail is provided by a WordPerfect Office Mail Server and dedicated
modem.

Remote connection to the network is via a Carbon Copy Gateway and a PCAnywhere Gateway,
each with a dedicated modem.

Connection to PS for corporate financials is via dedicated modem shared by the PS workstations.

2.2.4 Peripherals

All modems communicate at 9600 bps.

Network printers are workstation-attached laser printers from Hewlett Packard (HP): LaserJet,
LaserJet III, and LaserJet IIId.

Individual printers include laser printers: HP DeskJet, HP LaserJet, HP LaserJet IIp; and impact
printers: Panasonic KX-P1592, and Star NX-1000.

The following diagram provides a conceptual view of the current XYZ computing environment.

2.3 Organizational Standards and Policies

This section describes the technical standards and policies currently in place at the XYZ.

2.3.1 Technical Standards

Network
Novell Netware 3.11
SPX/IPX protocol
10Base2 Ethernet

Application Development
Clipper 5.0
Paradox
dBase III+

Server
Minimum: 386 DX/33 8 MB RAM, 300 MB mirrored disk
Preferred: 486 DX2/66 16 MB RAM, 1.2 GB mirrored disk

Workstation
Minimum: 386 SX/25 4 MB RAM, 120 MB HD, MS-DOS 5.0
Preferred: 486 DX/33 8 MB RAM, 175 MB HD, MS-DOS 6.2

Applications
WordPerfect
WordPerfect Office
Lotus 1-2-3
TimeLine
Harvard Graphics
Hotel Directory System

2.3.2 Technical Policies

Some operations which impact other on-line users (such as selection of carriers for audit) are
now done against a copy of AAA data, resident on another server.

Index regeneration is performed when indices become corrupted (possibly due to workstation
crashes, etc.)

All servers are backed-up nightly from the LAN Administration Workstation. Tapes are stored
off-site with a four-week rotation.

2.4 Operational Organization

2.4.1 System Support and Maintenance

Network management, software support, and preliminary hardware support is provided by the
XYZ Systems Administrator.

Additional hardware support is provided by local service organizations.

Support of the current AAA is provided by the XYZ systems administrator, and by XYZ
corporate IT staff via one of the remote access gateways.
2.4.2 System Operation

In terms of AAA usage, the XYZ organization consists of three sections:

Administration: This section is responsible for carrier certification, and claim control and
verification.

Field Audit: This section is responsible for field audit. AAA usage is limited to data extraction
and on-line query.

Finance and Administration: This section is responsible for generating payments and importing
those payments into PS.

3. EVALUATION OF CURRENT
ENVIRONMENT
3.1 Introduction
The current system has some strengths, omissions, and many problems which concern all users,
and which have highlighted the need for a replacement system.

This section will discuss the problems, strengths, and opportunities for improvement of the
current system. The issues discussed in this section are a combination of observations made
during the technical proof of concept site visit and interviews, and of issues raised in the Request
for Proposal Terms of Reference and supporting documentation.

3.2 Observations
3.2.1 System Usage Issues

From a user perspective, the primary problems with the current system involve response time
and system availability. By far the worst problem is the fact that when payments are being run,
no other AAA users may access the system; other problems include

Response time of up to seven minutes for claim deletion,

Year-end report completion time of seven days,
Noticeable system response degradation during report generation.

3.2.2 Operational Issues

From an organizational perspective, the primary problems with the current system involve the
omission of key data, and the inability to provide system enhancements. Specifically, the
problems are:
Claim movements are not tracked,
No automatic claim verification is performed,
Existing reports are limited and generation time is unacceptable,
Required reports are not available from the system and cannot be developed,
Ad-hoc requests for information cannot usually be fulfilled,
Interfaces to internal and external systems are inefficient and subject to human error,
Lack of expertise with ZIM internally and locally makes system enhancement and extension very
difficult and risky,
System is no faster than the manual method, and expected reductions in staff have not occurred.

3.2.3 Strengths

The single strength of the current system is in the area of claims control. The system provides
acceptable tracking of carriers and their claims throughout the certification, claim, and payment
processes.

3.3 Conclusion
The desire to replace the current AAA system has been expressed and supported throughout all
phases of this project to date, beginning with the XYZ project initiation report in March of 1992.

A replacement system would offer improvement in each of the following areas:

Accessibility,
Performance,
Maintainability,
Unfulfilled Requirements;

All of the problems experienced with the current AAA fall within one of these areas.

3.3.1 Accessibility

Accessibility in the current system is impacted as users perform database-wide access through
payment generation. Essentially, all tables are subjected to a file-lock which overrides and
disallows all other attempts at locking at any level.

3.3.2 Performance

AAA performance problems are evident in unacceptable response times, and are a function of
workstation capability, ineffective use of workstation memory by AAA, database design and
distribution, and network performance.

3.3.3 Maintainability
Maintainability problems are caused by the environment under which the current system was
developed (ZIM); this development environment is not supported locally or internally by the
XYZ. This has impacted the ability of the XYZ to make corrections and enhancements to the
system.

3.3.4 Unfulfilled Requirements

Data capture and tracking problems are a symptom of requirements which have not been fulfilled
by the current AAA. Essentially, development of the current AAA was never completed, so
required functionality is not available.

3.3.5 Architectural Issues

The current AAA application does not make effective use of workstation memory. As a result,
increased memory capacity does not improve performance of the application, and does not allow
for installation of additional software components such as virus protection software.

The network has limited bandwidth, to the point that large volume transactions are likely to have
a significant impact on overall performance. Further, the network segmentation is such that
cable lengths are at their maximum.

Novell-recommended procedures aimed at ensuring network performance and stability have not
been implemented. A procedure should be established to cycle (cold boot) each server at least
every 30 days. At the time of writing the Office server had been operational for 131 days and the
Region server had been operational for 53 days.

A procedure should be implemented to regularly purge deleted data to free up disk storage.

At the time of writing, the CACHE BUFFER for the Region server was at 42%. Any number
below 50% should be investigated because running too low can lead to a system crash. Another
couple of MB of memory on the Region server may be warranted.

Archival of data does not take place. The database design and apparent table-wide techniques of
some processes in addition to the retention of historical data contribute to the unacceptable
response time of some processes.

4. REQUIREMENTS FOR NEW AAA

SYSTEM
4.1 Introduction
Assessment of Clipper as an environment under which a replacement system could be developed
must take into consideration the current and future system requirements and issues.
Issues such as changes in usage and data growth, as well as requirements reflecting availability
and accessibility are described in this section.

SUMMARY OF USERS AT REPLACEMENT SYSTEM START UP DATE

Business Group User Type and Description Number of
Users
Administration Customer 3

Service: Carrier certification and

maintenance of carrier data.
Claim 4

Data Entry: Data entry of non-machine-

readable claims.

Control and input of machine-readable

claims for verification.
Post Audit: Verification of sampled 4
machine-readable claims following
verification and payment.
Verification: Resolution of problems with 4
machine-readable claims. Carrier assistance
with machine-readable submissions.
Supervision: On-line claim authorization, 4
ad-hoc query access.
Management: Payment authorization, ad-hoc 1
query access.
Field Audit Field Audit: Field audit of carriers using data 4
imported into ACLS, ad-hoc query
Supervision: Ad-hoc query 1
Management: Ad-hoc query 1
Finance Generation of payments and import into PS. 2

4.2 System Usage Requirements

4.2.1 User Identification

SUMMARY OF USERS AT SYSTEM MATURITY

Business Group User Type and Description Number of
Users
Administration Customer 4

Service: Carrier certification and

maintenance of carrier data.
 SUMMARY OF USERS AT SYSTEM MATURITY
Business Group User Type and Description Number of
Users
Claim 4

Data Entry: Data entry of non-machine-

readable claims.

Control and input of machine-readable

claims for verification.
Post Audit: Verification of sampled 6
machine-readable claims following
verification and payment.
Verification: Resolution of problems with 2
machine-readable claims. Carrier assistance
with machine-readable submissions.
Supervision: On-line claim authorization, 3
ad-hoc query access.
Management: Payment authorization, ad-hoc 1
query access.
Field Audit Field Audit: Field audit of carriers using data 4
imported into ACLS, AAA query
Supervision: AAA query 1
Management: AAA query 1
Finance Generation of payments and import into PS. 2

4.2.2 Accessibility and Usage

Access to data and system functions should be controlled on a per user basis. This will avoid
inadvertent changes to data, and lead to higher productivity as users are not presented with
options for which they do not have permission.

4.2.3 Performance

XYZ studies have suggested that a clerk can capture up to 100 movements per day. Performance
must be such that this expectation is met.

With the exception of movement data entry, performance requirements have not been specified.
However, the general requirement is that performance must be improved when compared with
the current system.

4.2.4 Growth Trends

The AAA user community is not expected to grow. Rather, use will grow within each user
group as efforts are refocused, and business requirements change.
4.2.5 Policy and Regulatory

New policies at the XYZ have set a maximum delay in claim payment of 20 days following
claim receipt.

Claim movements must be tracked in order to measure the effectiveness of the program.

4.3 Operational Requirements

4.3.1 Availability

The system must be available to all users between the hours of 8:00 AM and 5:00 PM, with
minimal performance degradation caused by multi-user data access.

Maximum acceptable system downtime is seven hours.

4.3.2 Maintainability

It is expected that system software and related components will be maintained by local computer
professionals and XYZ systems staff.

4.3.3 System Management

XYZ systems staff will manage the system (backup, archival, etc.)

4.4 Internal Interfaces

The development environment must be flexible enough to allow enhancement of existing
interfaces and development of new interfaces, as these become necessary.

4.4.1 Corporate Financials (PS)

The interface between the replacement system and PS will not vary from the current interface;
the interface will remain a text file export from AAA and import into PS by XYZ staff.

4.4.2 Audit Control Language System (ACLS)

The method of selection of carriers is expected to change in the interface from the replacement
system. This selection will take the form of a flexible query, enabling the random selection of
carriers, based on various criteria.

The data interchange will not change from the existing AAA method, in which a text file
containing data for the selected carriers is exported from AAA and imported into the ALCS by
XYZ staff.
4.4.3 Payment at Year End Process (PAYE)

The interface to this system will remain the specification of special payment commitment and
financial coding numbers which will indicate, following payment import into PS, that payments
should be made according to the PAYE.

4.5 External Interfaces

The development environment must be flexible enough to allow enhancement of existing
interfaces and development of new interfaces, as these become necessary.

4.5.1 Carriers

It is expected that two methods will be used to receive carrier claims into the new AAA:

Data entry from hard copy submitted by carrier

Ext file import

The methods by which carriers will submit claims in electronic form for import into the
replacement system are:

Diskette
File transfer via modem (future requirement)

In order to facilitate preparation of claims by carriers, to be submitted electronically, a carrier

claim submission application must be developed. This system must have minimal requirements
in terms of additional components required for use by the carrier. The system must produce the
text file required for import into the replacement AAA system.

5. EVALUATION OF PROPOSED
ENVIRONMENT
5.1 Introduction
The replacement AAA System must provide all of the capabilities of the current AAA, in
addition to unfulfilled requirements of the XYZ, while providing enhanced availability,
performance, and maintainability.

This section will discuss the findings of the Technical Proof of Concept and the reasons for
concluding that Clipper is a viable tool for development of the replacement AAA system.

5.2 Approach for Evaluation

Throughout this evaluation process, the consultants are specialists in networking, systems
development, and database management systems have drawn upon their experiences and those of
the Project Advisor. Experts at Computer Associates and the consultants Technology Network
were also contacted.

The Technology Network (TNet) provides specialists in specific technology areas for work on
projects, world-wide. The TNet experts consulted in this evaluation effort specialize in systems
development environments (including Clipper) and database management systems.

The Project Advisor is a central repository of information relating to all projects, world-wide.
The project advisor provided information on projects using Clipper in an environment very
similar to that currently in place at the XYZ.

Computer Associates (CA) are the makers of Clipper (now called CA-Clipper). CA was
consulted regarding the capabilities of Clipper in an environment similar in volumes to that
currently in place at the XYZ. CA provided guidance on the performance bottlenecks to be
avoided in a system with such large data volumes.

5.3 Performance Constraints

The use of Clipper as a tool for developing the replacement AAA System is constrained by
performance factors.

Performance and availability is acceptable in systems which do not have large numbers of
distributed users accessing complex data bases. For large Clipper systems, however, a great deal
of attention must be paid to the data processing model in order to ensure acceptable levels of
performance.

5.4 Data Volumes and Retention

The volume of data that will be captured in the tracking of claim movements and its effect on
performance and availability has been a major focus in the Clipper assessment. As data volumes
increase, the amount of time required to add, update, query, and report on the data also increases.

In general, it is required that data be retained in an on-line state for one year, at which point the
data may be placed in a ready off-line state for two to three years. After three years, the data
may be archived for infrequent report access.
 REPLACEMENT SYSTEM: EXPECTED ANNUAL GROWTH IN MAJOR DATA
STORES
Entity Size (bytes per Growth (records per Growth (MB per
[3] [4]
record) [3] year) [4] year)
Participant 247 300 0.07
Carrier 122 300 0.06
Application 2060 300 0.59
Certificate 2025 300 0.58
License 2116 300 0.61
Claim 212 18,000 3.64
Movement 411 2,000,000 783.92
Payment 128 15,000 1.83
Total 791.30

5.5 Maintainability
As mentioned, several times in the request for proposal and supporting documentation, the
current AAA is not maintainable. There is no available pool of ZIM knowledge, and as a result
the XYZ has been forced to find “work-arounds” and return to manual processes wherever the
current AAA fails them.

Clipper has a well-known, intuitive programming language. This enhances the maintainability of
a system written in Clipper. Clipper is a local and corporate XYZ standard with many local and
XYZ internal experts available for application maintenance.

5.5 Critical Components of Proposed Environment

This section will describe the components critical to the success of developing a replacement
AAA system using Clipper.

5.6.1 Transaction/Archival Model

There will be approximately two million new movement records added to the database each
year. This is a large transaction volume no matter what database is in use. Adding records to
such a large data store could result in a significant response time degradation.

[3]

[4]
With this in mind, such updates to the database should not occur when other users may require
access. To allow for this, the application should be structured such that potentially lengthy
transaction updates are applied to the database in isolation from other types of access.

On-line query, report generation and ACLS extracts may be targeted directly at the off-line
database, keeping in mind that the latest transactional updates (e.g. movements entered today)
will not be available.

Retention of data for long periods will cause substantial performance degradation in all areas of
data access. For this reason, when data is no longer required for frequent access, it should be
placed in an off-line read-only area and finally archived.

5.6.2 Hardware Architecture

One of the largest factors impacting database performance under Clipper is the speed at which
the database indices are updated. Network communication rate, workstation processor speed,
and available memory are the most important factors in increasing the speed of index update.

These performance issues will become increasingly important as the system matures and the
volume of data continues to grow. To ensure that performance is maintained to acceptable levels.
Operators requiring update access to data should use fast 486 class PCs with at least 8 MB of
memory. Clipper developed programs are able to directly access Expanded memory on PCs. The
Architectural Issues identified in Section 3.3.5 should be addressed to generally improve network
performance.

5.7 Considerations for the Future

Clipper databases conform to a widely adopted industry standard definition called X-Base. This
means that there are many products available for managing future system growth and
enhancement. These include query and reporting tools, executive information systems, and other
development tools and environments.

Clipper applications may be extended with other, more powerful, programming languages such
as C. This provides the opportunity for seamless integration of new technologies with the
application.

5.8 Conclusions
Based on the detailed assessment of the XYZ’s technical environment and anticipated
requirements of the new system, SHL believes that Clipper will provide an adequate tool for
development of the new AAA System.

The main factors considered in this evaluation were the current technical environment, Clipper’s
suitability for development of AAA requirements and the ability to attain expected levels of
performance and system maintainability.
Clipper may not be an ideal development tool for large systems with complex database
structures, high data volumes and large numbers of distributed users. However it is well suited to
the new AAA System. The data base structure is fairly straight forward and data volumes for on-
line access can be kept low by transferring large transaction files to a read-only area for report
generation. Users of the new system are also centralized in a single office and will access the
new system with fast 486 class personal computers.

[1] On average, each carrier has five licenses.

[2] One modem is shared between both PS workstations.
[3] Record sizes are based on XYZ preliminary database design specifications.
[4] Participant Growth figures are not known for non-carrier participants.

Carrier: Each carrier may have a license, certificate, and application for both Intra and
Westbound programs.

Application: Applications that are not authorized are still stored on the system.

License: Licenses are renewed each year. This means that yearly license volumes grow by the
number indicated plus the number of current carriers.

Movement: The XYZ cost-benefit analysis states that 20% of movements are expected to be
submitted in non-electronic form and that of these 20%, only 23.5% will actually be entered into
the system. The resulting reduction in total number of movements (306,000) per year is not
reflected in this table.

Payment: Payment record growth assumes that all claims are paid