|
|
 |
Interim Report #1
[This was the only report produced by this taskforce]
On August 11, 1997, a Task Force was formed to address issues regarding the electronic management of data in the North American Bird Banding Laboratory (BBL). Brett Hoover was appointed chair of the Task Force. Other members assigned to the Task Force were: William Bauer, Robert Munro, Phil Koscheka, Fred Fiehrer, Judy Hildenbrand, John Tautin, Paul Geissler, B.H. Powell, William Kendall, John R. Sauer, Bruce Peterjohn, H. Randolph Perry, Peter Blancher, Regina Lanning, and Erum Welling (assigned Dec. 8, 1997).
Tasks: The Implementation Team (James Kushlan, Mike Ruggiero, Paul Schmidt) selected Electronic Data Management as one of two high priority action items. The Team requests that the Task Force recommend how to achieve the goal of complete electronic operations for BBL in as short a timeframe as possible. The Task Force's products (see below) will provide guidance to the managers charged with implementing the complex process of re-engineering BBL. The Task Force will provide evaluations and options for transitioning to a client-server based system for accepting and delivering banding information via internet, for developing user friendly connectivity, for electronic editing (in place of hand editing), for accomplishing this as economically as possible including not replacing the present mini computer if possible, for recommending additional hardware and software. The Task Force will also consider the feasibility of electronically linking BBL and the Canadian Bird Banding Office.
Operations: All interests and ideas are to be considered, but in its deliberations the Task Force's over riding consideration should be what is best for the North American Bird Banding Program. We recommend that the Task Force meet not less than weekly, and that the Task Force chairperson provide biweekly progress reports to the Implementation Team Chairperson (Kushlan). When the Task Force completes its tasks, it will be maintained as an advisory body guiding implementation of decisions made by the Implementation Team. Because decisions on data management depend much on the data to be managed. The Task Force will depend on the work of other Task Forces, whose Chairs will hold cross membership. These Task Forces will deal with Recapture/Resighting Data; Ancillary Data; Location Data; and Data Release Policy.
Expected Products: A comprehensive report evaluating options, recommending an operational model, and recommending hardware and software acquisitions. The report should include a diagram depicting the "architecture" and flow of the proposed system. The report will also include the expected products from the subtask forces.
The original completion goal date was December 31, 1997. However, this goal date was removed, and the Task Force was re-directed to be an on-going committee to review all aspects of electronic data management and to oversee implementation accepted changes. Thus it was decided that the Task Force would issue a series of interim reports which would address various aspects of electronic data management within the BBL. The following is the first such interim report.
The Task Force reviewed existing BBL data and data management procedures, reports from subsidiary Task Forces, the future needs of the BBL, and the direction computing technology was moving. Based on these discussions, the EDM Task Force recommends that the BBL develop a prototype client-server, SQL relational database system on a Windows NT network, for testing and evaluation. This new system will be a re-design of the current system.
BBL's database currently consists of approximately 44 million banding records with 1.2 million bandings added per year. The recovery records total 3.2 million with 76,000 added this year. This data use approximately 2Gb of electronic storage (not including indexes).
BBL predicts a 5% increase per year for the number of banding records. The newly established 1-800 phone line for reporting recoveries has increased the percentage of reporting records per year. BBL expects the the number of recoveries reported to drastically increase with the expansion of the 1-800 reporting line.
Following is a summary of the subsidary BBL Task Forces' recommendations regarding various data collection. The Location Data Task Force (Bruce Peterjohn - chair) recommends: (1) location data be recorded to the closest minute of latitude and longitude (more specific location coordinates will be accepted if collected); (2) additional data fields be collected to identify how location data obtained; identify accuracy of location data; and (3) course location data for species of concern. The Ancillary Data Task Force (John Sauer - chair) recommends the following ancillary data be included in the BBL database: how aged and how sexed codes, and individually coded (unique) auxiliary markers. The Ancillary Data Task Force also recommends flags for data verification be added to the database. The Data Release Policy Task Force (H. Randolph Perry - chair) recommends full disclosure of all banding data and that this data be made readily available in hard copy, electronically, and via the internet. The Recapture/Resighting Data Task Force has not yet released a final report.
Current BBL operations use a centralized computing model. Data is maintained on a Hewlett- Packard [HP] 947 mini computer running HP's proprietary operating system MPE (Multi Processing Environment). Users connect to the database using dumb terminals or by personal computers running software simulating dumb terminals. The BBL data are housed in a proprietary hierarchical database system known as IMAGE.
All database maintenance programs are written in the COBOL programming language and TRANSACT - a proprietary fourth generation language (4GL). (It was noted that the total functionality of all these programs is not known.)
The initial cost of the HP mini computer was $160,000. BBL currently oversees maintenance contracts for this system at a cost of approximately $21,000 per year ($11,000 software and $10,000 hardware). The cost of maintenance could be lowered by upgrading older hardware components.
The current HP mini computer can be upgraded both with hardware and software. The HP can also accept larger, faster disk and tape drives. The operating system can be converted from MPE to Unix. Some costs will be involved in upgrading hardware.
Web server software exists for the HP with connections to BBL's existing database management system [DBMS]. A software solution can be added so that the current hierarchical database appears as a relational database - although probably at a performance cost. RDBMSs are available for both MPE and Unix on the HP 947. BBL would have to purchase these software packages.
In addition, to the mini computing facilities, BBL currently has two Window NT 4.0 servers (50 user licenses). BBL also has available a copy of Microsoft SQL Server 6.5 with 40 client licenses for the NT servers.
In accordance with Patuxent's upgrade of the infrastructure, the majority of BBL personal computers will be networked Pentium class IBM compatible systems running Windows 95. The Gabrielson Building (where the BBL program is housed) will be upgraded to handle a 100Mb network also by 1998. PWRC has a T1 connection to the internet via its PBX.
Patuxent also has a Data Genera (DG) minicomputer running Unix and Oracle (version 7.X), which BBL could use to explore the capabilities of Oracle. Patuxent also maintains a Novell (4.X) local area network.
Two important trends in the future of data processing technology have been identified. The Web paradigm is driving the way businesses are developing solutions. The current focus is to make as much information as possible available through the internet. BBL should follow this model and use the internet for conducting as much business as possible, in effect developing an "intranet" for the bird banding community.
The second trend is for businesses to move their database applications to a client-server model on local area networks using Microsoft's Windows NT Advance Server networking and an SQL relational database system.
Current changes to BBL procedures should increase the amount of data reported to the BBL. The Canadian Wildlife Service is developing a computer program which will enable banders to record their banding records and create electronic files for submission to the BBL. BBL has received inquiries about when an interactive web site will be developed for reporting band recoveries. [The Recapture/Resighting task will recommend BBL collect recapture and resighting data, only if it is provided in electronic format.] BBL should be prepared to accept this data electronically, either by files sent to BBL on diskette or via the internet through user friendly interfaces.
The success of BBL's 1-800 number indicates a trend for reporting recoveries by phone. BBL must also be prepared to expand these capabilities quickly as demand for these services will likely increase.
The subsidiary Task Forces recommend BBL collect additional data and more detailed information for some data fields. However, this data will not be collected for all banding records. Recovery data, by nature, is not collected for all banding records. This scheme dictates a relational database structure. Although an hierarchical database system can also handle relations between tables, a relational database does not have a fixed structure. BBL needs the flexibility to adapt the database as required. Also the cost of hardware has decreased relative to the cost of programming, reducing the attractiveness of a very efficient hierarchical system relative to a flexible relational system that is less expensive to develop and maintain.
Moving to a client-server system will allow BBL the flexibility to expand and increase capabilities at minimal expense. The success of BBL's 1-800 reporting system will require that additional clients be added to the current database system for adding recovery data - including client connections from CWS. A solution needs to be developed which will allow BBL to add these client capabilities to their data management system as quickly and inexpensively as possible.
The current BBL data management system is proprietary in nature - using vendor specific software and hardware. Upgrades to the software and hardware have to be purchased from the vendor or from specialized third party vendors at an increased cost. Maintenance for these data processing components is also procured from specialized vendors at a higher cost. Open system alternatives (non-vendor specific) exist which BBL can use to develop and deploy a new system which would reduce maintenance costs.
BBL recently hired a computer specialist with client-server database design and implementation experience. Part of the design process is to review and evaluate the current system and procedures in place and to modify and re-design a system keeping the procedures which work well and replacing those which are inefficient. The task force believes that the specific details in designing a new database management system should be left to the expertise and experience of this computer specialist.
This Task Force does not want to make inflexible recommendations. Technology is constantly changing. What is state of the art today, may be old technology tomorrow. The Task Force wishes to make recommendations that provide direction to BBL, but which are flexible enough to allow for modification as technology warrants. These recommendations also need to provide goals which are obtainable by the year 2000.
The Task Force's recommendations basically reflect those as described in the Buckley Report: (1) BBL should move to a client/server model for data management; (2) BBL should strive to have near 100 percent electronic operations by the year 2000.
The Task Force's major recommendation is to advise the BBL to develop a prototype client/server relational database system and exhaustively test the system to further refine requirements. Part of the new system should also incorporate functionality for intranet/internet communications with the banding community.
In developing this prototype system, BBL should adhere to the following recommendations:
By following the above recommendations BBL will develop a new database management system which is flexible, easily upgradable, and reduce maintenance costs.
The following more specific guidelines which adhere to the above recommendations provide direction for BBL in developing a prototype system as cost-effective as possible. The Task Force recommends BBL make the funds available to procure these items and that they be purchased when required by the lead developer
BBL should procure a high-end Dual-Pentium class network server. This server should be loaded with Microsoft's NT server software and a SQL compliant database management system (such as Microsoft SQL Server). .
The task force recommends that the client tools be developed with object oriented, open programming tools such as Visual Basic, PowerBuilder, Delpi, etc. (The task force wishes to let the lead developer decide on the best programming tools.) Vendor specific client tools should not be procured unless absolutely necessary for performance reasons.
The Task Force notes that it will be necessary to continue to maintain the current database system (and possibly enhance its capabilities) while the prototype is being developed and tested. The Task Force therefore recommends that current maintenance contracts be maintained. However, upgrades for this system should not be sought unless this upgrade is required to maintain the system or to reduce maintenance costs.
Some members of the task force have concerns about the performance of the proposed system, however the Task Force could not identify specific performance requirements of a new database management system. (A future interim report from the Task Force will attempt to identify BBL's customers and their requirements.) Developing and testing the prototype will determine whether or not performance is acceptable. If the performance of the system is not sufficient, the task force, with the assistance of BBL computer specialists, will evaluate the possibility of different technology, including upgrading BBL's HP minicomputer. By following the above recommendations for an open and scalable system, such a upgrade can be accomplished quickly with no duplication of effort.
Although the Task Force has provided initial recommendations, we see a need for continuing consultations among the stakeholders represented on the Task Force. We suggest that this or a similar Task Force continue to meet during the development of the prototype and the re- engineering of BBL. It will take several years to complete the prototyping and re-engineering and during that time there will be rapid advances in technology and many new issues will be raised by the prototyping process.
The client/server model is defined by a client system interacting with a server system sharing processing resources. The client, an intelligent computer with processing capabilities (e.g., a PC), communicates with the server via a network. Servers are usually high performance computers which can efficiently handle multiple users and requests. The sharing of computational processes is the key benefit of the client/server model. Less expensive computers can be used, because one machine does not have to do all the computing.
A database management system (DBMS) is a software program which provides: a way to structure, input, and store data; languages for querying data; multiuser access; and data security. A relational database system is a DBMS which contains separate tables which relate to each other by key data elements.
Open systems (computer hardware and software) provide published specifications which encourage development of compatible products. Easily interconnected.
The currently accepted paradigm for application development in a client server environment is the three tiered model. Components of the system are separated into three service layers: user services, middle-tier (or business) services, and data services. These layers are not physical layers of the client/server system, rather they are a conceptual breakdown of processes which can be deployed where thought best in the client/server environment. The flexibility allowed in deployment of the services can aid in maintenance, maximizing performance, and better security management.
The user services layer is typically associated with the user interface. Services in this tier present the user with a consistent interface for gathering, viewing, and editing data. This layer is typically deployed locally on the users' personal computer (or workstation).
The middle tier (or business services) layer collects services which usually isolate the user from direct interface with the database. These services perform such tasks as checking data, computing values, and security checks prior to accessing or updating the database.
The data services layer is usually the database management system. This is the system which maintains the data, handles requests for data, and updates to the data.
The three tiered model is a logical deployment of services - not a physical one. This model could be deployed on a single computer, or it could be deployed on a network using numerous computers. The idea, that the three layers are logical grouping of services which can be maintained and managed independently of the other layers. Not only does this ease maintenance, but also provides for optimal scalability.
As an example, take a distribution center for some product. This business is just starting, so inventory is small. The company develops an inventory application which has all three layers deployed on a desktop computer. As the company and its inventory grows, the company decides it needs to move to a more powerful database management system (DBMS). The purchase a network server and relational DBMS. Assuming the application was designed and developed correctly and they used a DBMS with an open interface (same method for querying, updating,etc. their old system), they just move the old database to the new DBMS on the server. The user and business services remain on the desktop computer, and access the database as if it was still on the pc. (Of course, it is not this easy, but you get the point.)
Term used to refer to software which runs on a server or mainframe computer connected to clients via a local area network. The software is typically isolated from normal networking activities and accessed only when data is requested from a client (or another server).