DEIMOS Information Systems Component

Human Resources and Policy Implications

$Id: human.html,v 1.4 1996/03/12 19:34:37 de Exp de $
The specifications and requirements listed above for hardware, software, and functionality imply further requirements for, or impacts upon, staff time and policy. This document will attempt to outline reasonable limits or guidelines for these kinds of costs.

The specifications call for

  1. one database server in the computer room (primary)
  2. one database server off the Mountain (secondary)
  3. one WWW server off the Mountain (talks to #2)
  4. a fairly large number of meta data items which require human key entry (cannot be captured via telemetry) -- but update is very infrequent for these items
  5. an extensive event and condition logging system which might be applicable to Keck-II more generally than just for DEIMOS support
  6. date-sensitive access control to acquired data
  7. observer control over the archiving of certain kinds of data

System and Service Management

The existence of three information servers, two RDBMS and one Webserver, implies management and maintenance of each of those servers (and hosts) by qualified people.

The local (primary) database server is integral to the observing process; observing can proceed in its absence, but quick-look reduction might be less automated or slower than with the database functioning properly. Loss of engineering information for one or more nights could impede our efforts to diagnose or even describe instrument problems.

The maintenance and management of this host and the database software are critical to the perceived success of the instrument. The obvious question that arises is, "Who (which institution, Lick/CARA/Keck) will provide the qualified staff to handle this?"

The secondary DB server and WWW server, though having no impact at all on the observing process, need competent management and maintenance to preserve continuous access to the published body of data. Unavailability or corrupted data will make a bad impression impairing the public image of Lick and Keck. If astronomers come to rely on the availability of these data for their research, then research efforts might also be obstructed or delayed if these machines and software engines are not kept in good shape. Some institution must commit to doing so.

The current design calls for many meta-data points which are not accessible via telemetry. We must discover whether any of these are logged to (e.g.) Keck's existing "Remedy" system, from which they could be automatically incorporated into the DEIMOS logs. If not, we must consider the staff time and degree of cooperation needed if Keck personnel are to enter reliable, accurate data. Typical of this class of meta-data are mirror re-aluminizing dates/times, optical alignment date/times, etc.

If Keck personnel are assigned to support the logging system by key entry of critical maintenance and repair events, then Keck (the institution) may well feel that this system should serve interests more general than "just DEIMOS". In that case, the logging/monitoring component of the DEIMOS software might be running every night, not just when DEIMOS was in use, and other instrument systems might want to retrieve/store data using the server. Issues of access control, security, and authority immediately arise: whose software, under what circumstances, is to have which kinds of access to which tables when?

In general, information services flourish best when a single individual is personally responsible for the server. (A deputy is of course required during that person's absences). Joint management is rarely successful, unless the joint managers work exceptionally well together and/or share an office (or are otherwise conveniently accessible to one another). Joint management usually results, over time, in inconsistent interpretations of policy and other forms of "tripping over each other" which can have serious impacts on the service provided.

Close cooperation is also required between the systems (OS) management personnel of these 3 machines and the info services managers/maintainers.

In summary of these points: One identifiable, well qualified individual should be responsible for each of the information service "nexi" posited in the project requirements. One person could conceivably manage all three (2 DBs and a WWW). However, three people should not manage one nexus. There should be very close cooperation between these managers and the system management of each machine, if indeed they are not the same person. Disorganization or incompetence in this matter could be expensive and/or very visible.

Access Control and Observer Preferences

Not all issues of configuration and data access can reside with software engineers. Issues of confidentiality (which involves slit mask designs, spectral and image frames, and even possible guider frames) can only be determined by the individual observer.

There is some implication beyond the design of software to permit the observer appropriate choices for publication of data; someone, probably the manager of the information service, is responsible for maintaining and periodically testing access control. Observers should feel confident that unauthorized access is prohibited, and that shareable central data archives are not a threat to their research programs.

It seems sensible to propose, as a solution to the first set of human resource requirements, that Lick should take responsibility for the information management system for some number of months or years after commissioning of the instrument -- the same number of months or years for which Lick is responsible for repairs, design adjustments, and other direct support of DEIMOS. After the end of this period, either Keck/CARA provides the staff resources to continue the information management program, or Lick continues it for Lick's own purposes, or it is allowed to wither and written off as part of the instrument commissioning and engineering process, now obsolete.

An inherent contradiction lurks in the support plan vs the implementation schedule for the science data archive. Most data taken with DEIMOS will be considered private by the observers until some period, probably about 2 years, has elapsed. Not until that time will the publishing of DEIMOS science data begin; in other words, the moment when the data archive finally starts to become valuable and visible is about the same moment when Lick support for the instrument has faded away and the info management system is at most risk of being discontinued.

If there is any commitment to the archiving and public offering of data taken with DEIMOS, then that commitment must include some staff time allocated to handling, labelling and transport of CDROM media, and librarian/operator functions for the large jukebox system, as well as the system/database management functions described above. Some agreement should be worked out between the institutions involved, as to who will meet this minor but long-term cost.
De Clarke
UCO/Lick Observatory
University of California