Hatchery Information System
While I feel that the approach taken by the Hatchery Information System is the best one possible for managing fish hatchery data, the Rationale section should make it clear that I am deeply ambivalent as to whether a hatchery data management system is even a good idea. The design is certainly a fun one, and is one where widespread adoption of the principles would benefit everybody. If there were multiple parties writing plugins, the library of existing plugins would be an increasing benefit to all involved. However, there are two significant caveats to that future.
The first caveat is simply that time marches forwards and drags technology along with it. If hatchery data management projects are expensive in time and money, that time and money could end up being stranded if technology moves in such a direction that the project is no longer viable. Whether or not this is a gamble worth taking is entirely up to each party. For example, the Hatchery Information System was started in 2010 using .NET framework 4.0. It has since been advanced to framework 4.8, but Microsoft has moved to .NET Core. Moving the Hatchery Information System to .NET Core would not be terribly difficult, but would require a certain amount of effort. Whether or not that is warranted is hard to say.
The second caveat is that the Hatchery Information System is almost certainly not complete for almost anybody. This isn’t only because there might be plugins that they would like, but because there’s a whole second half to the project that is too individualized to write in a broadly useful fashion. The Hatchery Information System is a program for hatcheries to enter hatchery data into a hatchery database, but how do you get that data back out?
The expectation for the Hatchery Information System is that the data from any participating hatchery will likely be sent to some central repository. This would require a fairly simple plugin to be written, but security considerations will mean that this plugin may well be quite different from one user to the next. The second half of that transfer would be a receiver, which would be a small program, probably a web-based API, that would accept the data transfer from a hatchery and put it into some centralized database. This, too, would not be a particularly difficult thing to write, though it would also tend to be highly custom to the recipient.
The bigger question is what happens to the data once it is in a central repository? It will need to be exposed to end users by some means. Some groups who have attempted to expose hatchery data in a usable fashion have used web sites, others have used internal dashboards. Either of those could make use of the read only versions of the Rearing Unit Business Object, the Fish Business Object, and the Growth Core, but either one would also tend to be highly individualized. The goal of the Hatchery Information System was to make a fish hatchery data management system that would be of use to a wide range of people, the proprietary nature of transferring and disseminating data is not consistent with that goal.
Worse than the proprietary nature of the task is the simple fact that I am not familiar with any system that is particularly good at disseminating the data they have. At best, each system that I have seen offers up a few canned snapshots of certain aspects of the data, with new canned snapshots added as the needs are identified. These snapshots tend to be tabular, limited, and visually drab, which is a shame considering how rich the underlying dataset is. However, these limitations are likely to be a feature of the dataset itself, not a result of any lack of imagination on the part of the developers. For example, those who want to see numbers at release, won’t want to see growth up to that point, or perhaps the disease history of the fish in question. Those who want to see growth may not care much about the marks on the fish, or perhaps the genetic information for the various family groups involved. Some views of the data will overlap, others will not. The net result is that any view of the data will likely serve one specific use while being unsuited to other uses. With potentially hundreds of possible views, a line must be drawn somewhere as to what to leave in and what to leave out.
Therefore, while the Hatchery Information System solves the largest part of the total problem very well, and transferring the data is a relatively simple part, the other big part of the problem has no general solution. Anybody who wants to take on the Hatchery Information System has to be aware of that fact and have a plan as to how they want to address it. They will have the same problem with any comprehensive means to manage fish hatchery data, but the problem still exists for the Hatchery Information System, and therefore the project can never be truly complete.