- Email: [email protected]
Environmental databases for management decisions: Alaska
0198-9715~13~~040315-13~03.00~0
Pcrg:imon Press Ltd
ENVIRONMENTAL
DATABASES FOR MANAGEMENT DECISIONS: ALASKA
KENNETH
BERKUN
and THOMAS JUHASZ
SCS Engineers, 1008 140th Ave. NE, Bellevue. WA 98005. U.S.A Abstract-The Alaska Department of Environmental Conservation has completed a conceptual design for an environmental database to support the entire department in monitoring, tracking and reporting functions. SCS Engineers has performed an evaluation of the design. This paper presents the results of that evaluation. Special emphasis is placed on the problems of designing and implementing such a system, and proposed solutions to those problems. Particularly important are methodologies for allowing the data to be shared among multiple users within the department. This paper discusses several techniques designed to allow maximum utility of the system.
INTRODUCTION THE DEVELOPMENT
of an environmental quality information system is a significant step for any environmental management agency. It demands a committment of time and resources that must be carefully weighed against priorities and resource allocations for a variety of programs. A computerized data management system such as is being envisioned by the Alaska Department of Environmental Conservation (ADEC) can be a quantum step forward in the evolution of decision-making capability. Today, more than ever, effective technical and administrative decision-making increasingly requires large amounts of data evaluation. This data not only comes from a variety of sources, but also differs markedly in format, content, and use. A well designed system for data management and evaluation will increase the reliability of the information used. It will also increase the speed at which it can be made available, thus increasing operational efficiency. ADEC developed a conceptual design for an automated water quality data system, named VWQ. The design has since grown into an integrated environmental database. This database would support the entire department in storing, tracking and reporting environmental data. SCS Engineers was asked to perform an evaluation of the original conceptual design, and recommend changes, additions, and an implementation schedule. This paper presents the results of the evaluation, plus insights into the process of system design. and the necessary properties of a good system. A key element in the process of system design and evaluation is an assessment of the major functions and data needs of proposed users. The goal of a thoughtfully developed system is to satisfy the wants and needs of a particular user community. The users of the proposed system should be clearly identified and their data needs well defined. Particular attention has been paid in this study to differentiating between needs and wants. SCS has conducted a thorough census of these needs and wants. This information has been carefully evaluated to define necessary system parameters and overall constraints. From that analysis we have been able to structure the perceived major capabilities desired in the proposed system. SCS evaluated the system design proposal from the standpoint of candidate software and hardware and resultant implementation costs. Existing hardware and software which would meet the needs of the proposed system have been evaluated. The conceptual design was used as a starting point for this process. Part of this process involved an evaluation of the State of Alaska’s Department of Data Processing’s (DDP) resources to determine both current and anticipated availability. Other potential resources have also been examined. Hardware and software have been evaluated in relation to existing resources within the DDP to obtain a better perspective on system needs versus existing 315
KFNNETH BEKKUN and THOMAS JUHASZ
316
resources. The objective was to define a set of key system capabilities that could be focused on for first stage system implementation. KS’s evaluation of the proposal system proceeded in a well defined manner. Portions of the proposed design were isolated and evaluated for other possible design considerations. In this way it was felt that two isolated views of the design could be taken and the best from each could be combined. A large number of alternatives could be examined and the bias toward preconception was minimized. The cost of the ADEC design proposal was evaluated with an eye toward the basic advantages and disadvantages of each element. A key area addressed in the evaluation process was interagency coordination. SCS Engineers viewed this as a critical design/implementation component if the system was to be truly viable. Coordination is viewed not only as a series of agreements to utilize a system; but more importantly a resource and data sharing agreement. A number of data-oriented users cannot successfully use a system until they are first willing to provide for unrestricted flow of data among themselves. Further, it is necessary that some standardization of that data be attempted to minimize costly data translation efforts. Effective interagency coordination efforts focus on realistic consideration of agency data needs and agency objectives as related to other agencies. Operation and management of the proposed system was seen as another critical area of system design. Successful system operation demands an understanding by users as well as operators of the objective, function, capabilities, and limitations of the system. It also demands a clear management structure that has well defined lines of communication and authority within the larger structure of which it will be a part. This also means responsibilities and a formal process for the allocation of resources to carry out those responsibilities must be clearly defined. First stage system implementation has been evaluated from several perspectives. A realistic schedule has been proposed for bringing the first key elements of a proposed system on-line. An overall strategy was formulated by examining those system capabilities that were most desired and weighing them against those capabilities which are seen as easiest to provide. SCS has attempted, where possible, to prioritize the components deemed as candidates for first phase implementation. As part of the process we have provided ADEC with estimates of required manpower for implementation and initial data entry and have projected an ongoing cost/manpower/priority schedule for the system.
IDENTIFICATION
OF USER NEEDS
Through interviews with key personnel SCS developed a list of all the sections within ADEC, and each of the functions performed by these sections. This list is presented below. Monitoring
and Lab Support
The major (1) (2) (3) (4)
functions
Section
of this section
are:
Development of monitoring strategies Analysis of samples used for enforcement Measurement of ambient air quality Establishment of water quality baseline information
Permits
Coordination
Section
The Permits Coordination Section has the responsibility for coordinating the permitting process for all the required permits any activity may generate. In addition the section also tracks all ADEC permits from application through to final disposition. Three main functions are assigned to the Permits Coordination Section.
Environmental
databases
for management
(1) Track all ADEC permits (2) Provide information centers to a clearing process (3) Administer the Master Permit application Water Quality Munagement
decisions
house for information
317
on the permitting
process
Section
The Water Quality Management Section has the primary responsibility for determining what constitutes a water quality problem, locating the problems and then regulating activities to solve and prevent these problems. The Management Section directs the collection of data, but is not a primary data collector. Data from many sources must be analysed to generate useful information, thus the management section must have analysis capabilities available to it. The activities of the Water Quality Management Section can be divided into 5 major functional areas: (1) (2) (3) (4) (5)
Water quality management Standards and regulation issuance Drinking water program planning and administration Oil spill response, enforcement and contingency planning Hazardous substances management
Management
und Technical
There are 3 major (1) Provide (2) Propose (3) Provide Regional
Assistance
functions
Section (MTA)
of this section:
aid to special task forces procedures for streamlining permitting technical assistance in specialty areas
ofices
The regional offices carry out in the field ADEC’s laws, regulations, programs and policies. In addition to enforcement, the regional offices perform plan reviews and monitoring and provide technical assistance. These functions are enumerated below: (1) (2) (3) (4)
Environmental enforcement Plan review Monitoring Technical assistance
Sanitary
Section
This section is responsible for assuring that public facilities do not pose a health threat to the public. This section has the responsibility for food-related activities, recreational activities, public accommodations, and public institutions. There are 4 major areas of responsibility affecting this section: (1) (2) (3) (4)
Inspections Permit issuance Complaint investigation Epidemiologic studies
Air and Solid Waste Management
Section
The Air and Solid Waste Management Section, although not involved directly with water quality does have some responsibilities that require similar kinds of information, so it’s needs are discussed below. There are 3 major program areas that this section is, involved in : (1) Air quality (2) Solid waste (3) Pesticides
318
O&e
K~XNETH
and
THOMAS
JIJHASI.
qf Al~imcll md Seqfood Imprctior~s
The Office of Animal bility : (1) (2) (3) (4) (5) (6)
BERKU~
and Seafood
Inspections
has the following
Inspection of seafood processing plants Inspection of meat processors Dairy sanitation inspection Inspection of clam and mussel beaches Sale of animal vaccines Issuance of animal health certificates for animals merce
ANALYSIS
OF
USER
transported
areas
of responsi-
in interstate
com-
NEEDS
The functions that were identified were analysed to determine how they will be accommodated by the system. Data needs are analysed by determining the number of users requiring particular data, the source of the data, the volume of data, its current format, availability and the value of the data to ADEC. The analysis done to date is based on limited knowledge of the data. The resources available for the study did not allow a thorough examination of the data, therefore the recommendations made at this point are somewhat general. Before the system is designed a thorough study of the data needed should be carried out. SCS is currently engaged in this study. The analysis made at this point is useful, however, because it determines the general size of the system and helps to define the basic structure. The list shown above presents an outline of the section functions. Figure 1 is a matrix which relates the users functional areas to the data needed by the users. The matrix shows the number of areas where a particular type of data can be used. Examination of the matrix reveals that certain types of data are required by many users. The data that is required by many users should be stored in a common location so that all the users have access to the same data. The matrix also shows that there are several users who require many of the data types. This data should be kept in a common system so that these users can easily access all the data they require. Virtually all the data shown in the matrix is shared, which suggests that all the data should be stored in a common system.
SYSTEM
OVERVIEW-REQUIRED
SYSTEM
CAPABILITIES
The information needs of ADEC are met by manipulating raw data to a form where it becomes useful. The system capabilities are the functions required to perform the manipulations. The major system capabilities are outlined below. For any of the data which relates to activities that can be reasonably represented as points (stations, facilities), the capability to maintain accurate identifiers is absolutely necessary. All the information ADEC has about an activity, i.e. NPDES permit, air permit, SPCC plan etc. should be easily relatable. The easiest way to relate all the information is to assign a unique identifier for each facility. The location of all activities needs to be maintained in the system. The absolute location should be available, i.e. latitude/longitude and for any activities related to water, the location relative to the hydrologic system must also be available. To be able to relate data to the river systems a scheme must be used that allows stations to be assigned quickly and maintains the distances and the upstream and downstream relations. Coding the Alaskan river networks and maintaining the structure in the proposed system would provide the basis for the required capability. Another basic capability of the system is to allow the storage and retrieval of environmental quality monitoring station data. In addition to maintaining station identifiers, the time the sample was taken, the sample type and the parameter values must also be
Environmental
databases
for management
decisions
319
maintained. The capability of adding new data, changing values and deleting data must all be available. A capability for which there is a high demand is the ability to keep track of permit issuance. The need exists for recording the dates of actions made on a permit and then easily retrieving them. The system should also automatically produce a list of key dates for each permit by using the permit issuance requirements. These key dates should be used to automatically warn an agency, so that required action can be taken before the deadline. The system could use the data on permits required by activity to automatically initiate and track the Master Permit process. The requirements could also be used to automatically find facilities not having the required permits. Much of the data required by ADEC relates to what can be termed facility inventory data. For instance data describing water dischargers, like type of activity and average flows, are needed. Inventories of important information relating to the following types of activities should be maintained:
320
Ke.
(1) (2) (3) (4) (5) (6) (7) (8)
GETH B~RKUN and THOMAS JLIHASZ
Waste water dischargers Public water supplies Air permitted facilities Oil storage and handling facilities Solid waste dump sites Hazardous waste facilities (generation Sanitary facilities Seafood and animal processors
and disposal)
These inventories should give general descriptive information about the activities which could be used for plan reviews, monitoring strategies, enforcement actions etc. The capability must exist to update and retrieve the facility data by many keys. The basic concept of the ADEC design of the system is excellent. As noted in the Introduction, the system has been expanded to include all of the environmental quality data with which ADEC is involved. This was a natural evolution, made as people became aware of the potential of the system. The VWQ system envisioned as a phased implementation network of interrelated areas is a sound concept. ALTERNATIVES
FOR
COMPUTER
RESOURCES
Throughout the ADEC conceptual design document it was assumed that the state’s data processing installation at Juneau and the ADABAS database management system (DBMS) would be used. It was also assumed that the state’s computer network would be used for data communication. The above combination may be a very valid way to proceed, however it is not the only way. SCS has determined that another feasible alternative would be to implement a dedicated minicomputer at the Juneau ADEC facility, along with a new communications network. This network could be implemented by a commercial networking company such as Tymnet or Telenet for a very cost competitive price. At this point SCS is not recommending one alternative over the other. There are other solutions available. For instance, a dedicated minicomputer tied into the state’s data communications network. But this is too expensive, patchwork and less reliable, and thus is not considered advisable. SCS developed an extensive list of advantages and disadvantages of the two computer resource alternatives, which follows. State
system
and network
(1) Advantages Existing installation with trained staff Existing communications network Full support of ADABAS DBMS as an acceptable, Full subsystem support (2) Disadvantages History of overloading Data communication problems Batch oriented Programming complexity Expensive system to run Dedicated
minicomputer
and network
(1) Advantages Complete computer control by ADEC Dedicated to VWQ system Availability of numerous DBMS’s Rapidly falling price structure Effective control over billing system
supported
system
Environmental
databases
for management
State-of-the-art networking capabilities User oriented Meets special implementation requirements
321
decisions
of VWQ
(2) Disadvantages Capital outlay for hardware and network Lack of transfer capability from mainframe Retraining of personnel INTERAGENCY
REQUIREMENTS
AND RESOLUTIONS
ADEC has exercised foresight in realizing that a large proportion of its efforts will be spent working between agencies. This is one reason why data formats must be compatible. For each agency an evaluation should be made of its data dependency on ADEC. The following questions must be answered in detail, for each of the system functional elements. This should be done at the time of design for each of the areas to spread the effort and the costs out, and to make sure the information will be accurate and up to date. It also insures that work will not be wasted providing information that will not be used, because a particular function is not going to be implemented. The following information is seen as requiring further research and evaluation:
(1) What data is ADEC interested (2) What data will it really use?
in?
What data will it provide in return? What is the volume of data? How often will this data be provided (each way)? What physical format is best? (e.g. tape, phone lines, cards, etc.) What is the logical data format (field type, length, etc.)? Who has control of the data? Must approval be granted by someone, if so, who? Who else might be interested in this data‘? (Answering this question will make work easier for later studies.) processing must be done on this data? (11) What particular (12) How is it used? Why? (13) Is there another source of data? Do they conflict? Which is better?
(3) (4) (5) (6) (7) (8) (9) (10)
In addition to interacting among agencies, VWQ will interact with other databases. It is imperative that VWQ be able to communicate with these databases in a simple straightforward and timely basis. The following databases were listed in the conceptual design: ALARS, WATSTORE, and STORET*. In addition it is desirable to communicate with other EPA (Environmental Protection Agency) databases, such as PCS and IFD. It will also be necessary to interface smoothly with the Anchorage data center. SCS Engineers has identified the Assessor’s data and the Water Rights data in ALARS as being of particular interest. Data coordination Attention must be paid to the organizational structure supporting the proposed system. It is stated in the ADEC conceptual design that the DBMS would allow control of the data (entry, updates, etc.) by those who use it most. This requires a good organizational structure to insure that: (1) the data that is supposed to be entered or modified is properly treated, (2) the data that should be left alone, is, and (3) data security is preserved. Although it sounds good to say that each user (organization) has control over its own data, in actuality this could become a point of contention. At some point a decision must be made about who has final, absolute, control. This decision must be enforceable. The * In fact users find the latter two databases cumbersome. Since Alaskan have generated locally, they might be better served with a local system.
agencies
primarily
use data
they
KENNETHBERKUN and THOMASJUHASZ
322
proposed structure gives the department data manager final control, which is a good solution. However, there must be a structure underneath the manager to provide support. Since the ADEC sections’ data requirements overlap extensively it is difficult to say who can do what to which data elements. Basically there are 4 functions which must be controlled (with variations): (1) (2) (3) (4)
Entry of data Modifying or updating Deletion of data Reading of data
Policy,fornzulution
data
and decision-making
One possible organization structure is shown in Fig. 2. Here the ADEC management is in ultimate control, but the actual operation of the system is in the hands of the department data manager. This person may also be referred to as the database administrator (DBA). The DBA has actual authority to make decisions regarding design. security, and day to day use of the system. Reporting to the DBA is the control board made up of representatives of the various groups and agencies using the system. This board should contain about six members, to ensure efficient operation. Not every group can be represented, but a variety of them should be on the board at any one time, and all the organizations should be rotated through. The control board makes most of the actual operation and production decisions that are needed on a close to daily basis. The DBA has an obligation to follow the board’s instructions, but must be free to act in emergencies on his/her own. Separate from the control board is the policy group. The policy group is apart in function, as discussed in the next section. The policy group would be responsible for long range decisions and overall guidance. These functions have been divided on purpose. Too often one gets so overburdened in running the operation that no time is left to plan ahead. The policy group need not be concerned with grievances. questions of data base
Fig. 2. Organizational
structure.
Environmental
databases
for management
decisions
32 3
access, except on a design basis, or trouble shooting the network. The control board must make their results and problems known to the policy group, who can then take these into account when making long term decisions. The policy board is concerned with implementation, not day-to-day operation. It must make the decisions about specifications, equipment, authority, and so on. Operation of the policy board and the control group will overlap. This will happen after part of the system is up and running, and a later part is still being designed. But the two groups do not overlap in function. The control group is concerned with day-to-day operations, the policy board is not. Obviously it behooves the two to be in good communication. Next in the hierearchy are the actual users. These are both agencies and individuals. They can petition the control board for changes, or with grievances. Every effort must be made to listen to the users. It is the users that can make or break a system. It is not as important that the design specifications be met, as it is that the users be kept happy. If the users are not happy the system will not be used. If the system is not used, then time and money have been wasted, and the job will not get done. The DBA must have good formal and informal communication channels with the users. Sysfer77
desiyr7
The complexity and size of the proposed system makes it difficult to approach. Should it be discussed from the data structure viewpoint, or the functional description? Either way there is a large amount of interaction between different elements. SCS Engineers has decided to treat structure and function together at this stage. As final design is approached the structure and the functions will separate. It is important to obtain an overview of the system, and it is impossible to do this if the parts are separated. The elements of the system breakdown as follows: (1) Stationing (2) Environmental quality monitoring (a) Water quality monitoring (b) Air quality monitoring (c) Clam and mussel monitoring (3) Permitting (4) Facility inventory (a) Water (b) Air (c) Oil and gas (d) Solid waste dumps (e) Hazardous waste sites (f) Sanitary (g) Seafood and animal processors (5) Hazardous waste manifest system (6) Operator certification (7) Construction grants (8) Oil spills (9) Sanitary, seafood and animal inspections (10) Area data subsystem (11) Animal subsystem ( 12) Communications subsystem (a) STORET, WATSTORE, ALARS (b) State Data Processing Department, Anchorage (c) Regional and Field Station (13) Utilities/support (a) Database support (b) Mailing list (c) Report writer The basic data structure
to support
the elements
is shown
in Fig. 3.
_2?!zzL--
mussel
Cidrnmd
Water qualiry monitoring data
monitoring data
Fig. 3. Data structure.
Permit tracking data LI
I Permits required by activity
I
data
-
Animal
J
pernuts
Pesticide
Environmental
databases
for management
decisions
325
Note that at each level additional elements can be added. Only those categories are shown which are known for certain to exist. One of the features of this organization is the ease with which phased implementation may be used. Any of the major categories may simply be deferred until resources are available. Within each category each subcategory may be deferred. By establishing a methodology for storage each additional item can be easily accommodated. The following organizational scheme is proposed. Data to be included in the system should be classified and organized by its spatial properties. The majority of the data can be represented reasonably as points. This includes all facilities and stations. The location of point data will be maintained by the stationing element in several ways. (1) Geographic location; latitude, longitude (2) Political location; address, county, district (3) Hydrologic location; river reach, mileage Some of the data cannot be represented as points because it has an undefined or poorly defined location. For instance operator certification data and animal vaccine sales data refer primarily to people, not places. Data not having spatial properties will not be included as stations, but may be linked to stations as shown in Fig. 3. The other class of data that will need to be accommodated in the database is data that represents area values. Area data will not be included as stations, but will exist in separate data structures appropriate for area data. The links between the area and point data, which are very important, can be developed by a geoprocessing system. System
input, update,
retrieval
and report facilities
The ability to do interactive or large batch retrievals is one of the most powerful features of a DBMS. It is important when designing the system to develop the most powerful, flexible, yet easy to use, system that resources will allow. Of these requirements the most important one is ease of use. The system’s success will be based on people’s responses. They either like the system or do not like it. Only if the system is usable and allows them to accomplish what they wish to accomplish will they like it. It is no good to design a system that allows the user to do anything, if the user is unable to figure out how to do it. There are certain techniques that can be employed to insure usability. These include: use of menus, simple English commands, good documentation, user training, and intensive testing of the system. It should be made a point to have non-computer-oriented people test the system at each stage and give ideas for improving it. Do not rely only on programmer input to determine whether the system is usable or not. There is no programmer who will approach the computer the same as a lay person. This is extremely important. Reading of the data will occur primarily in 4 different ways. These are: (1) (2) (3) (4)
Standard interactive retrievals Emergency interactive retrievals Standard reports Special case reports
IlnplerllerltLltiorz
If a system exists only on paper, it will be of no use to the agency, or business. Therefore, one of the most important tasks during analysis and design, is to plan for implementation. This includes cost estimates, planning of computer requirements, manpower estimates, time plans, and scheduling. As part of the evaluation of the design, SCS was asked to provide an implementation plan. As might be expected, a project of this scope is a major undertaking. Although the estimates are still rough at this point, the total length of the implementation may take 3-5 years. SCS estimates the manpower requirements to be at least 170 man months.
326
KENNETHBEKKLJNand THOMASJUHASZ
In order to implement the system in a structured, phased manner, SCS proposed a project team consisting of at least 7 professionals: 2 analysts, 2 high level programmers/ designers. 2 programmer/coders, and 1 technical writer. Having a full time writer available helps ensure th.tt proper documentation is generated throughout the duration of the project. In addition, a support staff of skilled labor would be needed, such as typists, data-entry personnel, graphic artists, etc. The proposed implementation plan includes 9 broad phases: (1) Evaluation of conceptual design (completed) (2) Evaluation and decisions on system parameters-machine, mentation schedule (in progress) (3) Detailed design (4) Specification and ordering of special hardware (5) Programming (including documentation, debugging, etc.) (6) Data collection (7) User training (8) Formation control board (9) Production (maintenance)
scope, prioritized
imple-
It is important to note that each of these phases has been broken down into subtasks for actual implementation. In addition, SCS has recommended a prioritized order of implementation for the system. This is based on a variety of factors, including amount of support within ADEC, amount of existing data, success of the current methodology, and possibilities of obtaining funding. Other asprcts
Usability has been mentioned several times in this paper. It is so important that we bring it up again. Usability can make or break a system. IBM systems have a certain disadvantage when it comes to usability. Due to their primitive design (cu. 1965) they are much harder to learn and to use on a regular basis. This gives an advantage to using a minicomputer. There are techniques which can be employed to increase usability. Some of these are: Structured programming (top-down design, modular programs, etc.) Testing on non-computer-oriented people Menus for interactive programs Ability to back out of any section easily Use of good defaults for answers Attention to user complaints Simple English commands On-line testing for legal values Good screen design (enhanced fields, etc.) Ability to rapidly access the needed data Note that it is often desirable to limit the power of the user in order to make use simpler. Above all. listen to the user. Get analysts or designers who can deal well with non-computer-oriented people. Take a look at the overall picture.
SUMMARY SCS Engineer’s evaluation of the proposed ADEC system has been oriented around an approach that had as a key element an assessment of the proposed user community and its perceived information needs. SCS’s analysis has led to the conclusion as might be expected that the responsibilities and concommitant information needs of the various functional areas within the ADEC are greatly varied. However, it was also obvious, once the assessment was completed that there also exists a great deal of shared information needs within the ADEC.
Environmental
databases
for management
decisions
317
The resources available for this study did not allow for a thorough examination of actual data specifics. Therefore the recommendations at that point are somewhat general. The evaluation did, however, get into a fair amount of detail as to users and perceived needs. The matrix (Fig. 1) of users and functions presents a fairly clear picture of needs variance at this stage of the assessment. The major conclusion that the matrix itself points to is that all the data areas presented are shared. This strongly suggests that all data should be stored in a common system. ADEC is aware of the advantages of using a database management system (DBMS) to achieve this commonality. However, it is still crucial to code the data in a standard and general purpose way. This means developing a good practical data and key structure. This has been addressed in the evaluation of the conceptual design, although the final structure will not be decided upon until the actual DBMS has been selected. Another major concern addressed in this study, was the usability of the system. If ADEC staff members and the public cannot easily use the system, it will not be used at all. In order to avoid having the entire effort wasted, a number of proposals were made to ensure usability. These include selection of a “friendly” computer and a variety of good programming techniques. ADEC is being very foresightful by electing to implement an integrated data system for the department. The potential to save money, time, and to accomplish things previously impossible, is great. However, there are a number of pitfalls, and the decisions yet to be made are numerous. SCS is pleased to have played a role in this pioneering system, and looks forward to a continued working relationship with ADEC. Currently, SCS and ADEC are engaged in a detailed data needs survey, expanding the initial work done in the evaluation, and SCS is conducting a study of the required computer resources for this project. This includes selection of the hardware, database system, and telecommunications subsystem. When this is complete, the stage will be set for development of the detailed design, and finally, implementation. A~lirro~~/rc/r~e~~~rnt.~-SCS would like to thank Michael Angelo, project coordinator, and the entire staff of the Alaska Department of Environmental Conservation. for their help-and cooperation in this study. During the study. SCS interviewed a large number of ADEC personnel. all of them were very friendly and helpful. We would like to extend our appreciation to all of them.
Pcrg:imon Press Ltd
ENVIRONMENTAL
DATABASES FOR MANAGEMENT DECISIONS: ALASKA
KENNETH
BERKUN
and THOMAS JUHASZ
SCS Engineers, 1008 140th Ave. NE, Bellevue. WA 98005. U.S.A Abstract-The Alaska Department of Environmental Conservation has completed a conceptual design for an environmental database to support the entire department in monitoring, tracking and reporting functions. SCS Engineers has performed an evaluation of the design. This paper presents the results of that evaluation. Special emphasis is placed on the problems of designing and implementing such a system, and proposed solutions to those problems. Particularly important are methodologies for allowing the data to be shared among multiple users within the department. This paper discusses several techniques designed to allow maximum utility of the system.
INTRODUCTION THE DEVELOPMENT
of an environmental quality information system is a significant step for any environmental management agency. It demands a committment of time and resources that must be carefully weighed against priorities and resource allocations for a variety of programs. A computerized data management system such as is being envisioned by the Alaska Department of Environmental Conservation (ADEC) can be a quantum step forward in the evolution of decision-making capability. Today, more than ever, effective technical and administrative decision-making increasingly requires large amounts of data evaluation. This data not only comes from a variety of sources, but also differs markedly in format, content, and use. A well designed system for data management and evaluation will increase the reliability of the information used. It will also increase the speed at which it can be made available, thus increasing operational efficiency. ADEC developed a conceptual design for an automated water quality data system, named VWQ. The design has since grown into an integrated environmental database. This database would support the entire department in storing, tracking and reporting environmental data. SCS Engineers was asked to perform an evaluation of the original conceptual design, and recommend changes, additions, and an implementation schedule. This paper presents the results of the evaluation, plus insights into the process of system design. and the necessary properties of a good system. A key element in the process of system design and evaluation is an assessment of the major functions and data needs of proposed users. The goal of a thoughtfully developed system is to satisfy the wants and needs of a particular user community. The users of the proposed system should be clearly identified and their data needs well defined. Particular attention has been paid in this study to differentiating between needs and wants. SCS has conducted a thorough census of these needs and wants. This information has been carefully evaluated to define necessary system parameters and overall constraints. From that analysis we have been able to structure the perceived major capabilities desired in the proposed system. SCS evaluated the system design proposal from the standpoint of candidate software and hardware and resultant implementation costs. Existing hardware and software which would meet the needs of the proposed system have been evaluated. The conceptual design was used as a starting point for this process. Part of this process involved an evaluation of the State of Alaska’s Department of Data Processing’s (DDP) resources to determine both current and anticipated availability. Other potential resources have also been examined. Hardware and software have been evaluated in relation to existing resources within the DDP to obtain a better perspective on system needs versus existing 315
KFNNETH BEKKUN and THOMAS JUHASZ
316
resources. The objective was to define a set of key system capabilities that could be focused on for first stage system implementation. KS’s evaluation of the proposal system proceeded in a well defined manner. Portions of the proposed design were isolated and evaluated for other possible design considerations. In this way it was felt that two isolated views of the design could be taken and the best from each could be combined. A large number of alternatives could be examined and the bias toward preconception was minimized. The cost of the ADEC design proposal was evaluated with an eye toward the basic advantages and disadvantages of each element. A key area addressed in the evaluation process was interagency coordination. SCS Engineers viewed this as a critical design/implementation component if the system was to be truly viable. Coordination is viewed not only as a series of agreements to utilize a system; but more importantly a resource and data sharing agreement. A number of data-oriented users cannot successfully use a system until they are first willing to provide for unrestricted flow of data among themselves. Further, it is necessary that some standardization of that data be attempted to minimize costly data translation efforts. Effective interagency coordination efforts focus on realistic consideration of agency data needs and agency objectives as related to other agencies. Operation and management of the proposed system was seen as another critical area of system design. Successful system operation demands an understanding by users as well as operators of the objective, function, capabilities, and limitations of the system. It also demands a clear management structure that has well defined lines of communication and authority within the larger structure of which it will be a part. This also means responsibilities and a formal process for the allocation of resources to carry out those responsibilities must be clearly defined. First stage system implementation has been evaluated from several perspectives. A realistic schedule has been proposed for bringing the first key elements of a proposed system on-line. An overall strategy was formulated by examining those system capabilities that were most desired and weighing them against those capabilities which are seen as easiest to provide. SCS has attempted, where possible, to prioritize the components deemed as candidates for first phase implementation. As part of the process we have provided ADEC with estimates of required manpower for implementation and initial data entry and have projected an ongoing cost/manpower/priority schedule for the system.
IDENTIFICATION
OF USER NEEDS
Through interviews with key personnel SCS developed a list of all the sections within ADEC, and each of the functions performed by these sections. This list is presented below. Monitoring
and Lab Support
The major (1) (2) (3) (4)
functions
Section
of this section
are:
Development of monitoring strategies Analysis of samples used for enforcement Measurement of ambient air quality Establishment of water quality baseline information
Permits
Coordination
Section
The Permits Coordination Section has the responsibility for coordinating the permitting process for all the required permits any activity may generate. In addition the section also tracks all ADEC permits from application through to final disposition. Three main functions are assigned to the Permits Coordination Section.
Environmental
databases
for management
(1) Track all ADEC permits (2) Provide information centers to a clearing process (3) Administer the Master Permit application Water Quality Munagement
decisions
house for information
317
on the permitting
process
Section
The Water Quality Management Section has the primary responsibility for determining what constitutes a water quality problem, locating the problems and then regulating activities to solve and prevent these problems. The Management Section directs the collection of data, but is not a primary data collector. Data from many sources must be analysed to generate useful information, thus the management section must have analysis capabilities available to it. The activities of the Water Quality Management Section can be divided into 5 major functional areas: (1) (2) (3) (4) (5)
Water quality management Standards and regulation issuance Drinking water program planning and administration Oil spill response, enforcement and contingency planning Hazardous substances management
Management
und Technical
There are 3 major (1) Provide (2) Propose (3) Provide Regional
Assistance
functions
Section (MTA)
of this section:
aid to special task forces procedures for streamlining permitting technical assistance in specialty areas
ofices
The regional offices carry out in the field ADEC’s laws, regulations, programs and policies. In addition to enforcement, the regional offices perform plan reviews and monitoring and provide technical assistance. These functions are enumerated below: (1) (2) (3) (4)
Environmental enforcement Plan review Monitoring Technical assistance
Sanitary
Section
This section is responsible for assuring that public facilities do not pose a health threat to the public. This section has the responsibility for food-related activities, recreational activities, public accommodations, and public institutions. There are 4 major areas of responsibility affecting this section: (1) (2) (3) (4)
Inspections Permit issuance Complaint investigation Epidemiologic studies
Air and Solid Waste Management
Section
The Air and Solid Waste Management Section, although not involved directly with water quality does have some responsibilities that require similar kinds of information, so it’s needs are discussed below. There are 3 major program areas that this section is, involved in : (1) Air quality (2) Solid waste (3) Pesticides
318
O&e
K~XNETH
and
THOMAS
JIJHASI.
qf Al~imcll md Seqfood Imprctior~s
The Office of Animal bility : (1) (2) (3) (4) (5) (6)
BERKU~
and Seafood
Inspections
has the following
Inspection of seafood processing plants Inspection of meat processors Dairy sanitation inspection Inspection of clam and mussel beaches Sale of animal vaccines Issuance of animal health certificates for animals merce
ANALYSIS
OF
USER
transported
areas
of responsi-
in interstate
com-
NEEDS
The functions that were identified were analysed to determine how they will be accommodated by the system. Data needs are analysed by determining the number of users requiring particular data, the source of the data, the volume of data, its current format, availability and the value of the data to ADEC. The analysis done to date is based on limited knowledge of the data. The resources available for the study did not allow a thorough examination of the data, therefore the recommendations made at this point are somewhat general. Before the system is designed a thorough study of the data needed should be carried out. SCS is currently engaged in this study. The analysis made at this point is useful, however, because it determines the general size of the system and helps to define the basic structure. The list shown above presents an outline of the section functions. Figure 1 is a matrix which relates the users functional areas to the data needed by the users. The matrix shows the number of areas where a particular type of data can be used. Examination of the matrix reveals that certain types of data are required by many users. The data that is required by many users should be stored in a common location so that all the users have access to the same data. The matrix also shows that there are several users who require many of the data types. This data should be kept in a common system so that these users can easily access all the data they require. Virtually all the data shown in the matrix is shared, which suggests that all the data should be stored in a common system.
SYSTEM
OVERVIEW-REQUIRED
SYSTEM
CAPABILITIES
The information needs of ADEC are met by manipulating raw data to a form where it becomes useful. The system capabilities are the functions required to perform the manipulations. The major system capabilities are outlined below. For any of the data which relates to activities that can be reasonably represented as points (stations, facilities), the capability to maintain accurate identifiers is absolutely necessary. All the information ADEC has about an activity, i.e. NPDES permit, air permit, SPCC plan etc. should be easily relatable. The easiest way to relate all the information is to assign a unique identifier for each facility. The location of all activities needs to be maintained in the system. The absolute location should be available, i.e. latitude/longitude and for any activities related to water, the location relative to the hydrologic system must also be available. To be able to relate data to the river systems a scheme must be used that allows stations to be assigned quickly and maintains the distances and the upstream and downstream relations. Coding the Alaskan river networks and maintaining the structure in the proposed system would provide the basis for the required capability. Another basic capability of the system is to allow the storage and retrieval of environmental quality monitoring station data. In addition to maintaining station identifiers, the time the sample was taken, the sample type and the parameter values must also be
Environmental
databases
for management
decisions
319
maintained. The capability of adding new data, changing values and deleting data must all be available. A capability for which there is a high demand is the ability to keep track of permit issuance. The need exists for recording the dates of actions made on a permit and then easily retrieving them. The system should also automatically produce a list of key dates for each permit by using the permit issuance requirements. These key dates should be used to automatically warn an agency, so that required action can be taken before the deadline. The system could use the data on permits required by activity to automatically initiate and track the Master Permit process. The requirements could also be used to automatically find facilities not having the required permits. Much of the data required by ADEC relates to what can be termed facility inventory data. For instance data describing water dischargers, like type of activity and average flows, are needed. Inventories of important information relating to the following types of activities should be maintained:
320
Ke.
(1) (2) (3) (4) (5) (6) (7) (8)
GETH B~RKUN and THOMAS JLIHASZ
Waste water dischargers Public water supplies Air permitted facilities Oil storage and handling facilities Solid waste dump sites Hazardous waste facilities (generation Sanitary facilities Seafood and animal processors
and disposal)
These inventories should give general descriptive information about the activities which could be used for plan reviews, monitoring strategies, enforcement actions etc. The capability must exist to update and retrieve the facility data by many keys. The basic concept of the ADEC design of the system is excellent. As noted in the Introduction, the system has been expanded to include all of the environmental quality data with which ADEC is involved. This was a natural evolution, made as people became aware of the potential of the system. The VWQ system envisioned as a phased implementation network of interrelated areas is a sound concept. ALTERNATIVES
FOR
COMPUTER
RESOURCES
Throughout the ADEC conceptual design document it was assumed that the state’s data processing installation at Juneau and the ADABAS database management system (DBMS) would be used. It was also assumed that the state’s computer network would be used for data communication. The above combination may be a very valid way to proceed, however it is not the only way. SCS has determined that another feasible alternative would be to implement a dedicated minicomputer at the Juneau ADEC facility, along with a new communications network. This network could be implemented by a commercial networking company such as Tymnet or Telenet for a very cost competitive price. At this point SCS is not recommending one alternative over the other. There are other solutions available. For instance, a dedicated minicomputer tied into the state’s data communications network. But this is too expensive, patchwork and less reliable, and thus is not considered advisable. SCS developed an extensive list of advantages and disadvantages of the two computer resource alternatives, which follows. State
system
and network
(1) Advantages Existing installation with trained staff Existing communications network Full support of ADABAS DBMS as an acceptable, Full subsystem support (2) Disadvantages History of overloading Data communication problems Batch oriented Programming complexity Expensive system to run Dedicated
minicomputer
and network
(1) Advantages Complete computer control by ADEC Dedicated to VWQ system Availability of numerous DBMS’s Rapidly falling price structure Effective control over billing system
supported
system
Environmental
databases
for management
State-of-the-art networking capabilities User oriented Meets special implementation requirements
321
decisions
of VWQ
(2) Disadvantages Capital outlay for hardware and network Lack of transfer capability from mainframe Retraining of personnel INTERAGENCY
REQUIREMENTS
AND RESOLUTIONS
ADEC has exercised foresight in realizing that a large proportion of its efforts will be spent working between agencies. This is one reason why data formats must be compatible. For each agency an evaluation should be made of its data dependency on ADEC. The following questions must be answered in detail, for each of the system functional elements. This should be done at the time of design for each of the areas to spread the effort and the costs out, and to make sure the information will be accurate and up to date. It also insures that work will not be wasted providing information that will not be used, because a particular function is not going to be implemented. The following information is seen as requiring further research and evaluation:
(1) What data is ADEC interested (2) What data will it really use?
in?
What data will it provide in return? What is the volume of data? How often will this data be provided (each way)? What physical format is best? (e.g. tape, phone lines, cards, etc.) What is the logical data format (field type, length, etc.)? Who has control of the data? Must approval be granted by someone, if so, who? Who else might be interested in this data‘? (Answering this question will make work easier for later studies.) processing must be done on this data? (11) What particular (12) How is it used? Why? (13) Is there another source of data? Do they conflict? Which is better?
(3) (4) (5) (6) (7) (8) (9) (10)
In addition to interacting among agencies, VWQ will interact with other databases. It is imperative that VWQ be able to communicate with these databases in a simple straightforward and timely basis. The following databases were listed in the conceptual design: ALARS, WATSTORE, and STORET*. In addition it is desirable to communicate with other EPA (Environmental Protection Agency) databases, such as PCS and IFD. It will also be necessary to interface smoothly with the Anchorage data center. SCS Engineers has identified the Assessor’s data and the Water Rights data in ALARS as being of particular interest. Data coordination Attention must be paid to the organizational structure supporting the proposed system. It is stated in the ADEC conceptual design that the DBMS would allow control of the data (entry, updates, etc.) by those who use it most. This requires a good organizational structure to insure that: (1) the data that is supposed to be entered or modified is properly treated, (2) the data that should be left alone, is, and (3) data security is preserved. Although it sounds good to say that each user (organization) has control over its own data, in actuality this could become a point of contention. At some point a decision must be made about who has final, absolute, control. This decision must be enforceable. The * In fact users find the latter two databases cumbersome. Since Alaskan have generated locally, they might be better served with a local system.
agencies
primarily
use data
they
KENNETHBERKUN and THOMASJUHASZ
322
proposed structure gives the department data manager final control, which is a good solution. However, there must be a structure underneath the manager to provide support. Since the ADEC sections’ data requirements overlap extensively it is difficult to say who can do what to which data elements. Basically there are 4 functions which must be controlled (with variations): (1) (2) (3) (4)
Entry of data Modifying or updating Deletion of data Reading of data
Policy,fornzulution
data
and decision-making
One possible organization structure is shown in Fig. 2. Here the ADEC management is in ultimate control, but the actual operation of the system is in the hands of the department data manager. This person may also be referred to as the database administrator (DBA). The DBA has actual authority to make decisions regarding design. security, and day to day use of the system. Reporting to the DBA is the control board made up of representatives of the various groups and agencies using the system. This board should contain about six members, to ensure efficient operation. Not every group can be represented, but a variety of them should be on the board at any one time, and all the organizations should be rotated through. The control board makes most of the actual operation and production decisions that are needed on a close to daily basis. The DBA has an obligation to follow the board’s instructions, but must be free to act in emergencies on his/her own. Separate from the control board is the policy group. The policy group is apart in function, as discussed in the next section. The policy group would be responsible for long range decisions and overall guidance. These functions have been divided on purpose. Too often one gets so overburdened in running the operation that no time is left to plan ahead. The policy group need not be concerned with grievances. questions of data base
Fig. 2. Organizational
structure.
Environmental
databases
for management
decisions
32 3
access, except on a design basis, or trouble shooting the network. The control board must make their results and problems known to the policy group, who can then take these into account when making long term decisions. The policy board is concerned with implementation, not day-to-day operation. It must make the decisions about specifications, equipment, authority, and so on. Operation of the policy board and the control group will overlap. This will happen after part of the system is up and running, and a later part is still being designed. But the two groups do not overlap in function. The control group is concerned with day-to-day operations, the policy board is not. Obviously it behooves the two to be in good communication. Next in the hierearchy are the actual users. These are both agencies and individuals. They can petition the control board for changes, or with grievances. Every effort must be made to listen to the users. It is the users that can make or break a system. It is not as important that the design specifications be met, as it is that the users be kept happy. If the users are not happy the system will not be used. If the system is not used, then time and money have been wasted, and the job will not get done. The DBA must have good formal and informal communication channels with the users. Sysfer77
desiyr7
The complexity and size of the proposed system makes it difficult to approach. Should it be discussed from the data structure viewpoint, or the functional description? Either way there is a large amount of interaction between different elements. SCS Engineers has decided to treat structure and function together at this stage. As final design is approached the structure and the functions will separate. It is important to obtain an overview of the system, and it is impossible to do this if the parts are separated. The elements of the system breakdown as follows: (1) Stationing (2) Environmental quality monitoring (a) Water quality monitoring (b) Air quality monitoring (c) Clam and mussel monitoring (3) Permitting (4) Facility inventory (a) Water (b) Air (c) Oil and gas (d) Solid waste dumps (e) Hazardous waste sites (f) Sanitary (g) Seafood and animal processors (5) Hazardous waste manifest system (6) Operator certification (7) Construction grants (8) Oil spills (9) Sanitary, seafood and animal inspections (10) Area data subsystem (11) Animal subsystem ( 12) Communications subsystem (a) STORET, WATSTORE, ALARS (b) State Data Processing Department, Anchorage (c) Regional and Field Station (13) Utilities/support (a) Database support (b) Mailing list (c) Report writer The basic data structure
to support
the elements
is shown
in Fig. 3.
_2?!zzL--
mussel
Cidrnmd
Water qualiry monitoring data
monitoring data
Fig. 3. Data structure.
Permit tracking data LI
I Permits required by activity
I
data
-
Animal
J
pernuts
Pesticide
Environmental
databases
for management
decisions
325
Note that at each level additional elements can be added. Only those categories are shown which are known for certain to exist. One of the features of this organization is the ease with which phased implementation may be used. Any of the major categories may simply be deferred until resources are available. Within each category each subcategory may be deferred. By establishing a methodology for storage each additional item can be easily accommodated. The following organizational scheme is proposed. Data to be included in the system should be classified and organized by its spatial properties. The majority of the data can be represented reasonably as points. This includes all facilities and stations. The location of point data will be maintained by the stationing element in several ways. (1) Geographic location; latitude, longitude (2) Political location; address, county, district (3) Hydrologic location; river reach, mileage Some of the data cannot be represented as points because it has an undefined or poorly defined location. For instance operator certification data and animal vaccine sales data refer primarily to people, not places. Data not having spatial properties will not be included as stations, but may be linked to stations as shown in Fig. 3. The other class of data that will need to be accommodated in the database is data that represents area values. Area data will not be included as stations, but will exist in separate data structures appropriate for area data. The links between the area and point data, which are very important, can be developed by a geoprocessing system. System
input, update,
retrieval
and report facilities
The ability to do interactive or large batch retrievals is one of the most powerful features of a DBMS. It is important when designing the system to develop the most powerful, flexible, yet easy to use, system that resources will allow. Of these requirements the most important one is ease of use. The system’s success will be based on people’s responses. They either like the system or do not like it. Only if the system is usable and allows them to accomplish what they wish to accomplish will they like it. It is no good to design a system that allows the user to do anything, if the user is unable to figure out how to do it. There are certain techniques that can be employed to insure usability. These include: use of menus, simple English commands, good documentation, user training, and intensive testing of the system. It should be made a point to have non-computer-oriented people test the system at each stage and give ideas for improving it. Do not rely only on programmer input to determine whether the system is usable or not. There is no programmer who will approach the computer the same as a lay person. This is extremely important. Reading of the data will occur primarily in 4 different ways. These are: (1) (2) (3) (4)
Standard interactive retrievals Emergency interactive retrievals Standard reports Special case reports
IlnplerllerltLltiorz
If a system exists only on paper, it will be of no use to the agency, or business. Therefore, one of the most important tasks during analysis and design, is to plan for implementation. This includes cost estimates, planning of computer requirements, manpower estimates, time plans, and scheduling. As part of the evaluation of the design, SCS was asked to provide an implementation plan. As might be expected, a project of this scope is a major undertaking. Although the estimates are still rough at this point, the total length of the implementation may take 3-5 years. SCS estimates the manpower requirements to be at least 170 man months.
326
KENNETHBEKKLJNand THOMASJUHASZ
In order to implement the system in a structured, phased manner, SCS proposed a project team consisting of at least 7 professionals: 2 analysts, 2 high level programmers/ designers. 2 programmer/coders, and 1 technical writer. Having a full time writer available helps ensure th.tt proper documentation is generated throughout the duration of the project. In addition, a support staff of skilled labor would be needed, such as typists, data-entry personnel, graphic artists, etc. The proposed implementation plan includes 9 broad phases: (1) Evaluation of conceptual design (completed) (2) Evaluation and decisions on system parameters-machine, mentation schedule (in progress) (3) Detailed design (4) Specification and ordering of special hardware (5) Programming (including documentation, debugging, etc.) (6) Data collection (7) User training (8) Formation control board (9) Production (maintenance)
scope, prioritized
imple-
It is important to note that each of these phases has been broken down into subtasks for actual implementation. In addition, SCS has recommended a prioritized order of implementation for the system. This is based on a variety of factors, including amount of support within ADEC, amount of existing data, success of the current methodology, and possibilities of obtaining funding. Other asprcts
Usability has been mentioned several times in this paper. It is so important that we bring it up again. Usability can make or break a system. IBM systems have a certain disadvantage when it comes to usability. Due to their primitive design (cu. 1965) they are much harder to learn and to use on a regular basis. This gives an advantage to using a minicomputer. There are techniques which can be employed to increase usability. Some of these are: Structured programming (top-down design, modular programs, etc.) Testing on non-computer-oriented people Menus for interactive programs Ability to back out of any section easily Use of good defaults for answers Attention to user complaints Simple English commands On-line testing for legal values Good screen design (enhanced fields, etc.) Ability to rapidly access the needed data Note that it is often desirable to limit the power of the user in order to make use simpler. Above all. listen to the user. Get analysts or designers who can deal well with non-computer-oriented people. Take a look at the overall picture.
SUMMARY SCS Engineer’s evaluation of the proposed ADEC system has been oriented around an approach that had as a key element an assessment of the proposed user community and its perceived information needs. SCS’s analysis has led to the conclusion as might be expected that the responsibilities and concommitant information needs of the various functional areas within the ADEC are greatly varied. However, it was also obvious, once the assessment was completed that there also exists a great deal of shared information needs within the ADEC.
Environmental
databases
for management
decisions
317
The resources available for this study did not allow for a thorough examination of actual data specifics. Therefore the recommendations at that point are somewhat general. The evaluation did, however, get into a fair amount of detail as to users and perceived needs. The matrix (Fig. 1) of users and functions presents a fairly clear picture of needs variance at this stage of the assessment. The major conclusion that the matrix itself points to is that all the data areas presented are shared. This strongly suggests that all data should be stored in a common system. ADEC is aware of the advantages of using a database management system (DBMS) to achieve this commonality. However, it is still crucial to code the data in a standard and general purpose way. This means developing a good practical data and key structure. This has been addressed in the evaluation of the conceptual design, although the final structure will not be decided upon until the actual DBMS has been selected. Another major concern addressed in this study, was the usability of the system. If ADEC staff members and the public cannot easily use the system, it will not be used at all. In order to avoid having the entire effort wasted, a number of proposals were made to ensure usability. These include selection of a “friendly” computer and a variety of good programming techniques. ADEC is being very foresightful by electing to implement an integrated data system for the department. The potential to save money, time, and to accomplish things previously impossible, is great. However, there are a number of pitfalls, and the decisions yet to be made are numerous. SCS is pleased to have played a role in this pioneering system, and looks forward to a continued working relationship with ADEC. Currently, SCS and ADEC are engaged in a detailed data needs survey, expanding the initial work done in the evaluation, and SCS is conducting a study of the required computer resources for this project. This includes selection of the hardware, database system, and telecommunications subsystem. When this is complete, the stage will be set for development of the detailed design, and finally, implementation. A~lirro~~/rc/r~e~~~rnt.~-SCS would like to thank Michael Angelo, project coordinator, and the entire staff of the Alaska Department of Environmental Conservation. for their help-and cooperation in this study. During the study. SCS interviewed a large number of ADEC personnel. all of them were very friendly and helpful. We would like to extend our appreciation to all of them.