Editor’s Note: Today’s post is by Andreas Mace. Andreas is a Systems Librarian at the National Library of Sweden.
In the first part of this guest blog post, the limitations of the unified vision for library systems were explored and critiqued. Here we look more towards the other side of the spectrum, at loosely coupled software and services, that together create a modular library systems landscape. But what are the merits, and flaws, of such an approach and what can libraries (and technology providers) do to remedy some of the less desired effects of such strategies?
Merits and Flaws of a Modular Library Systems Landscape
The main advantages of a modular system would be that libraries could pick and choose as they like, considering the needs of their patrons and the workflows of their library and implement software that meets those needs. The use of software with a more limited scope also makes it easier to change them when user behavior, library workflows or data models change. Focusing on local needs and workflows should be more apparent in a modular systems landscape, taking advantage of UX and local knowledge of how a specific library’s users behave and the needs of its staff.
The drawbacks of a such an approach should be equally obvious as its advantages: a multitude of specialized software (and different user interfaces) for library staff and patrons to use, limited interoperability between systems, and having workflows and data exchange that span across several systems (increasing the risk of replicating work in different systems).
The question of a multitude of systems or services to work with seems to me as the issue of least consequence, even if it is often brought up as one of the key factors for proposing the use of monoliths. As previously mentioned, today’s digital landscape is filled with various user interfaces, software and applications. Staff and patrons should be used to various setups, and not all staff work with the same parts of these systems anyway. Diversifying is not an issue in this affect, even if it could be a hurdle for specific individuals.
Workflows and data exchange is, however, a major obstacle: interoperability between systems and services is here the key. What you do not want in a modular systems landscape are closed circuit systems that do not communicate well with each other, demanding that staff replicate work and manually copy data between several systems (or simply does not do this extra work, leaving the systems out of sync). Or, even worse, to put it into a research perspective: that researchers are forced to duplicate work in various systems, because of something as redundant as a lack of data exchange and workflow management. In case the systems do not link together well it also creates obstacles for the very workflows that a modular systems landscape should enable. Let’s be frank, this is a major stumbling block for all those looking for an alternative to the unified system, and a big reason why the unified vision is still so strong. In itself, this has a lock-in effect.
Issues of Seamlessness, Innovation and Collaboration
There is seemingly a contradiction between integrating decoupled software or services into a seamless “whole” on one hand, and vendor lock-in on the other. This ongoing trend is apparent in the examples provided in the first part of this guest blog post, but also clearly shown in software for scholarly publishing and researcher workflows, exemplified by the strategy shown by Elsevier of acquiring new products and tightly integrating them. The key thing to notice should be that although there is integration between software, it is limited to a specific set of software – provided by one (parent) company or technology provider. I would argue that this is rather an extension of the unified vision than a modular systems landscape, as it lacks key attributes of this strategy such as choice, adaptability and diversity of services.
Moving from closed proprietary software towards open software built around collaboration might be the path forward to mitigate lock-in effects of both the unified vision and vendor lock-in strategies. But there is also a need of strong will from key stakeholders in the library community to negotiate with the large companies that are active in the academic sphere, when procuring new software or adding new products to our portfolios, requiring openness to integration across suites of software.
If a modular library systems landscape hampers or enhances innovation is another delicate question. At its core, the increased flexibility and opportunity to quickly replace components as new interesting dynamic software evolves is a boon to innovation. Also, the ability to work out of local contexts allows for innovation on a smaller scale, closer to actual library workflows and processes and how these evolve. On a larger scale, the image becomes blurrier. Firstly, the disparity of software and services can act as a blocker towards innovation, where each piece is run separately, making innovation across workflows difficult since there might be totally different organizations or providers responsible for the various involved parts. How the micro- and macroscale of a modular software strategy for libraries interact in regard to key aspects of agility, innovation and collaboration is a topic that needs to be explored further in the future.
Implementing a Modular Library Systems Landscape!
So far, a more theoretical framework has been discussed, with pros and cons of a strategy of more modularity in library (and academic) software and services. But how can such a strategy be practically implemented? What can be done to break the domination of the unified vision in libraries?
First of all, we need to make sure that the software we build or procure are created to integrate well with other systems; they should be built upon open APIs, have data models based on established standards, should be able to handle that data in the system can originate from outside the software, and that the data should be easy to extract again (caching data or separating internal “master” data from external data, for instance). Larger libraries can then use staff (developers) to create integrations that suit their user needs. But what of mid- and smaller libraries, with limited or no possibilities of employing their own developers? Is the modular systems landscape only a unique possibility for a select few, large libraries?
It shouldn’t be! Apart from requiring that software should be created in a way that enables integration, libraries should also demand that software have prebuilt, plug-and-play, integration with other industry standard software. Major discovery systems, link servers and Inter-Library Loan (ILL) software should have established integrations with all major Integrated Library Systems (ILS) or Library Service Platforms (LSPs), for example. Also, we should demand integrations, or at least good integration possibilities, with other relevant systems in the academic landscape, not just limiting our focus to the library domain – while making sure newcomers are easy to connect with what is already in place. So what the library needs to focus on is integrating smaller, more unique pieces of software, or creating their own integrations based on their needs rather than use a more generic setup (remember that this is where the modular systems landscape excels, after all, creating such opportunities to enhance local workflows and innovation!). Smaller and mid-size libraries without their own developers can make use, and should demand it upon procurements, that their support companies/system providers perform such integration work, if it is not already established!
This requires a lot from library technology providers and support companies, but it is something that the library community should demand of them – after all, they are there to support libraries, not the other way around! If this is a general requirement from a large number of libraries, vendors and support companies will adapt and create viable business models for this (other than only using cloud-based Software as a Service offerings, with small or no opportunities for local adaptation or integration). Using open-source software where possible is also an opportunity, where support providers to a larger extent are used to, and capable of, performing integration work on behalf of their clients.
We shouldn’t stop there, but should also explore better ways in which our software can integrate and interconnect. One such way could be to establish better standards for data exchange and create more “exchange-ready” data models – especially around BIBFRAME, and more web-oriented standards such as schema.org. New models for data exchange should also be addressed and explored, for example working with activity streams. Another way forward is to establish more industry standards in the form of more generic “integration engines”, which are fairly common outside of the library space. Perhaps it is time to engage in creating a library-specific (or academic?) integration toolkit, which could be supported and integrated by various technology providers and libraries alike? Meta frameworks like those seen in scholarly publishing might also be looked at as ways to help facilitate interoperability and sustainability of a modular systems landscape.
But the most fruitful option would likely be to build platforms that can help integrate the various modules and systems, that then require small efforts to integrate, rather than large unified systems. FOLIO could be such an option, but the LSP is still struggling with whether it should be a platform that enables modules or apps built on top of it, or a more unified system – easy to brand and promote. If and when FOLIO is built more as a platform and interacts well with, say, other established open-source software such as Koha and CORAL ERM, so that libraries can decide upon use based on local needs and software functionalities, rather than being limited by system boundaries, then we would be close to a modular systems landscape as a truly viable option to the unified system.
To summarize, the modular library systems landscape is possible already today (although with some limitations), and several academic libraries use software in this fashion, more or less based on a strategic vision as outlined in this text. But with more work dedicated to allow the possibility of modularity, and increasing awareness of such an option as opposed to the unified vision, I am hopeful that more libraries can invest in such a choice, and put pressure on technology providers and vendors to further enhance such possibilities. This would lessen the strain on libraries that the consolidation of library technology and the overarching vision of a unified system has brought. And with this, more choices will become available to libraries: offering opportunities to have systems that support local needs while simultaneously allowing innovation based upon those needs. I am hopeful that libraries together can create such a change!
2 Thoughts on "Guest Post — Do Libraries Still Dream Unified Dreams? Part 2"
It’d be great to read details re: “several academic libraries use software in this fashion” … maybe a future guest post?
I’d be happy to write a follow-up!