Checklists of functionality are typically used within Library system tendering processes to ensure that Mandatory / Optional functionality is met. We should recognise that this is useful as a safeguard against almost unexpected failing (as any short listed system unlikely to be missing any core functionality) and to capture local / national requirements (for example, relating to UK ILL/DD operations). The traditional UK Core Specification (UKCS) and recent Unified Library Resource Management Specification (ULRMS) – both referenced from the HE Library Technology wiki – serve precisely these purposes.

The checklists provided here have a somewhat different purpose in mind – to assist in defining the functional components, the boundaries and the critical areas for any systems or process development in the library space. The list extends far beyond the boundaries of what might be called the ‘local library management system’ and even the ‘library service platform, to enable service managers to:

  • Think out of the local and library boxes
  • Scope systems, related developments and change projects
  • Identify required and potential touch points with other institutional systems
  • Identify required and potential relationships with external services
  • Engage in clear constructive dialogue with suppliers, developers and service partners
  • Address matters arising in service road maps, contracts and project plans

We therefore hope this list act as a feeder in service design, ensuring above all things that solutions are not envisioned from the tunnel perspective of ‘Off The Shelf’ products (commercial or open source) outwards.

Checklist Structure

The LMS Change checklist is presented in eight columns, which can provide useful filters if the spreadsheet version is downloaded:

  • A – Category: divides the list into n broad functional areas
  • B – Element: represents the lowest level of our checklist, over 150 entries typically drawn from the standard headings in other checklists, such as UKCS, ULRMS, California Digital Library and Discovery
  • C – ULRMS: indicates whether this element is a heading in the Unified Library Resource Management Specification (2011)
  • D – UKCS: indicates whether this element is a heading in the UK Core Specification (2002)
  • E – LSP: suggests the importance of this element for a contemporary Library Service Platform scored from 1 (Essential), 3 (Important), 5 (Closely Related), 7 (Loosely related) to 9 (Not relevant)
  • F – Local library service:
  • G – Wider Institutional systems:
  • H – Global ecosystem services:

Columns F, G & H are marked with two values which indicate the relevance of the Element to that particular setting

  • y = definitely in scope (in typical academic libraries – though it may not be in your local requirement)
  • ? = possibly in scope though it might be covered elsewhere (as above)

Narrow and Wider Checklist Views

The LMS Change checklist is presented in three forms, to which you can add your own elements and classifications:

  • Complete checklist – Over 150 elements, of which c.140 are assessed as relevant to the local library service
  • Global Ecosystem checklist – The subset of elements relevant to the wider ecosystem of services and resources above and beyond the institution and the local library
  • Wider Institutional checklist – The subset of elements marked as relevant for institutional system consideration
  • Library Service checklist –The subset of elements marked as relevant to local library systems

The overlaps and intersections between these historically segmented areas are highly significant in the current climate and the emerging technological and operational environment. There is a convergence of pressures, ranging from local efficiencies to the pervasive influence of the web-scale services, to consider:

  • Identity Management – the key to CRM as well as security
  • Enterprise integration – where data and processes may be duplicated
  • Shared services – that improve quality and timeliness as well as saving time and effort
  • Analytics – the voice of big data, local and national, underpinned by consistent identifiers
  • Social networks – sticky services for both students and researchers, local and global glue

Given this context it seems unreasonable to take the Core Specification and the preferred vendor footprint for a Library Management System as the starting point for service definition, data lifecycle and workflow design. It would be logical to expect vendors (and implementers of open source systems) to join with the library in considering not only the footprint of a proposed library management system but also considerable variety in the way it might merge in to the local and above campus landscape – the LMS no longer assuming its position as fixed piece at the centre of a familiar jigsaw.

The required flexibility is illustrated by our Venn diagram, which shows the relationships between checklist columns F, G & H:

Venn diagram showing intersections of checklists

The key point is that of the 143 elements potentially covered by / required by local library systems, only 50 are assumed to be exclusively the interests of the library service:

  • 93 (65%) are possibly linked to other systems or services
  • 62 (over 40%) may involve systems and interests in the wider institution
  • 64 (over 40%) may are linked to the above-campus and global ecosystem
  • Of those 33 sit at the intersection of the institution and the wider ecosystem

The following table provides a more detailed breakdown of the relationships between the 153 elements, using the distinction in the checklist between elements that are ‘definitely’ in scope for a column (marked ‘Yes’) and those that are more questionable (marked ‘?’). The key point is that even the ‘Yes’ elements have considerable overlaps – as illustrated in the Local Library row.

Local LibraryYes962833
Local Library?463431
Wider InstitutionYes505924
Wider Institution?121310
Global EcosystemYes623363
Global Ecosystem?211