The specifications call for
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.
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.
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@ucolick.org