Approaches to integration: build or buy?

Different institutions have adopted different routes to integrating research information, publications management systems and repositories. The repository team may be involved in the decision as to whether to buy or build and which system to buy if the decision goes that way, or at least be consulted as to the implications for the repository.

Factors influencing the choice to build or adapt in-house systems may include:

  • The prior existence of a central system for managing research information, which researchers and administrators have already become accustomed to using
  • Functionality and flexibility in existing systems which it is felt is not matched by what is on offer from external vendors
  • Requirements specified for upgrading or building a system which cannot be found in an externally available system
  • Some loss of control over quality of metadata
  • Full integration with existing repository may be difficult to engineer in a proprietary system
  • Reluctance to move from open source to proprietary software
  • Perceived lower risk (control over development)
  • Cost and timescale of implementation, customisation and maintenance
  • Not being able to determine the precise development path in future as it will be conditioned by the vendor’s commercial considerations and market demand from other clients

Factors influencing the choice to buy may include:

  • A straightforward, proven route to a central platform which synchronises with all the university’s management information systems (HR, student records, finance etc)
  • Interoperability with major external data sources e.g. Web of Science, PubMed, Scopus
  • Easier to ensure a place and a voice in the overall eco-system of funders, subject repositories, publishers
  • Other institutions have purchased the system and are satisfied with it
  • Collaboration may be facilitated by having the same system e.g. the choice of PURE (a CRIS) by several Scottish universities and the model offered in Norway and Denmark
  • Adherence to standards
  • Vendors will take responsibility for keeping up with technological developments, managing file formats etc
  • The opportunity to share future development costs with other universities
  • Perceived lower risk (sharing development, less dependency on individual developers relative to a bespoke solution)
  • Affordability

Quality of implementation

Whether the decision is made to build or buy in a system, the quality of the implementation will obviously be crucial. There may be very many obstacles to ensuring that the requirements gathered before the decision was made are effectively translated to a working system. Much of this is concerned with good project management practice, with processes in place for resolving problems and making certain that the interests of the end-users are properly represented within the project management team. But there may be particular issues associated with the different strategic choices:

  • Building a system in-house can particularly fall victim to internal politics and shifting priorities, and to loss of individual staff. It can lose momentum as a result, since no-one is contractually obliged to complete the project at a particular time. It can also be subject to ‘scope creep’ as it is possible to revisit and revise requirements in a way that is less likely to happen with an external supplier. That is good for flexibility but can lead to a situation where actual deployment stretches out into the future. Strong internal champions are needed to drive the project forward, make decisions about priorities, arbitrate firmly between stakeholders, and command the necessary resources.
  • Buying in a system means bringing in external people who do not know the institution and its particular ways of doing things, and of describing processes, departments and so on. A lot will need to be explained and ‘translated’.
No comments yet.

Leave a Reply