Posted by s.hettrick on 17 April 2012 - 10:22am

In this post, Avrum Goodblatt discusses the Catalysers project, which promotes people who have both domain knowledge and skills in design and communication. This concept of linking domain knowledge with other skills is something that the Software Sustainability Institute believes would be highly beneficial to a number of research projects so we are very interested in the Catalysers project (and indeed, one of our staff, Simon Hettrick, is a member of the steering committee).

By Avrum Goodblatt.

Dynamic systems are those whose design can evolve quickly with changes in research approaches and opportunities. Whether software is developed by lab staff, IT staff, consultants, from open source or from a commercial product, this dynamism must be maintained, managed and even encouraged. It is a key component of successful research.

It is rare for Prinicipal Investigators or their staff to have the time for ongoing design. Instead, it becomes the developer's responsibility to ferret out the researcher's needs over the life-cycle of the system. The real cost of management and design of a system is therefore hidden in the general cost of software development. Moreover, many developers are unsuited to this kind of requirements gathering, because they lack the deep domain knowledge of the researcher.

The problem here is similar to that of pair-programming (see The Social Dynamics of Pair Programming). It is considered too expensive to provide the additional staff needed for the programming process - both by budgeting for the expertise needed in domain and business process design, and by freeing up the time of the lab staff who are critical to the understanding of the system’s requirements. Rather than seeing this approach as a way to ensure that the results of development are robust and usable, pair-programming is considered a duplicative expense for a process that it is believed could just as well be carried out by developers alone. This fallacy is especially true in academic biomedical research, where funding continues to decline and computer costs continue to climb.

When a commercial company gathers domain knowledge, it will often make that knowledge proprietary. This means that each institution that needs the knowledge must replicate the effort of gaining it from scratch - a needless expense. What’s more, the proprietary approach means that the improvements that result from sharing knowledge cannot be attained. The design of experiments, clinical trials, biobanking and suchlike is domain knowledge that must be shared – it is an extension of the corpus of experimental research.

Software can be developed or customised much more effectively with the help of catalysers. These are research staff who have domain knowledge as well as skills in process design and communication (which includes the ability to listen). The catalyser’s primary knowledge is not Java or Perl – or any specific programming language - but instead an experience of programming that helps translate designs into actual systems. Catalysers can also promote the sharing of tools, skills, and designs between institutions.

Both commercial and open-source projects can benefit from the existence of catalysers by helping to effectively focus development and support efforts. Common definitions, libraries, API's and web services are a natural outgrowth of this effort.

There are drawbacks to overcome. Chief Information Officers (CIOs), or their equivalents, might not see the need to budget for the extra expense of employing a catalyser. But this is due to a focus on short-term costs, rather than the savings that result from effective and robust system design in the long run. Both open-source initiatives and companies can move the field forward by educating CIO's on these issues. Means by which to monitor the quality of system design are needed, but standards of exposition and peer review could help.

While transparency in the area of systems design might be considered financially unwise by some, an organisation that can master this area can stay ahead by achieving quick results for their researchers. Agile research may be harder to implement than agile programming, but the rewards to those that do it could be large.

Thanks to Chris Morris for discussions which helped lead to this article. I suggest looking at his post, Why Don't Scientists Use Limselns?, to see a different but related take on these issues.