Software as a Service (SaaS) is becoming increasingly common. Software, particularly for large systems such as library management or discovery systems, has in the past been commonly acquired through a single large purchase and then installed, configured, and managed on library-owned computer hardware by library-employed technology specialists. Most of the time there would be some training and setup work available from the vendor as well as some type of maintenance agreement where for an annual fee the vendor would provide technical support and also make available patches and upgrades to the software. However, the majority of the technical work required to have and maintain the use of the software was always the responsibility of the purchaser.
SaaS shifts a lot of this burden from libraries to their vendors. With SaaS, libraries pay a subscription fee, usually annually, to the vendor in exchange for their installing, configuring, and managing the software on their own hardware at their own locations. Libraries connect to and use the software over the Internet. Is this a good option for libraries? Clearly it is attractive as libraries are increasingly taking advantage of this option, my own included. Like anything, however, there are pros and cons that need to be examined carefully.
The pros of SaaS for libraries include:
- There is no hardware infrastructure for libraries to purchase and maintain.
- The time library technical staff would have spent managing a local hardware infrastructure can be spent on other work.
- Startup costs are much lower.
- Startup occurs much more quickly.
- Long-term costs are more transparent, predictable, and spread evenly over time.
- Software up time is frequently better and more predictable.
- Patches and updates are included and are performed in a timely manner by the SaaS technical staff.
- The product is available to more libraries, including those with limited or no technical staff of their own.
- Software can be accessed via any web-accessible computer, including mobile devices, regardless of where they are located (providing they have a good Internet connection not restricted by a firewall).
- The installation is easily scalable when the number of users, the number of computers needing access to the software, and the amount of data increases.
The cons of SaaS for libraries include:
- The library is dependent on the vendor staying in business and continuing support for the product.
- The vendor could add undesirable, or remove desirable, product features.
- SaaS does not allow for much, if any, customization.
- The purchaser must ascertain the security of the product and any data accessible through it.
- The customer must ascertain and ensure regulatory standards compliance.
- Libraries are dependent upon the SaaS vendor to correct any problems that may occur.
- Long-term costs can potentially be greater.
- Moving to a different SaaS vendor could be more difficult.
- A slow or unreliable Internet connection will result in slow or unreliable SaaS performance.
- Performance could be slower than with locally hosted and managed software.
Of these, I would be most concerned about the cons relating to security, regulatory compliance, and performance. This is nothing unique to SaaS, as these questions should always be at the top of the list with any software product, but they require special attention with SaaS because of having to trust an outside organization to provide for them. It will probably require a little extra work to be sure an SaaS product fully meets all aspects of these needs (especially for security and regulatory compliance, which are not as immediately obvious as product performance) both at startup and over the lifetime of the use of the product. A big part of this extra work is going to be developing trust in the SaaS vendor. It is critical to know they take these matters as seriously as their customers and will always take every step possible to ensure they are attended to according to customer needs and expectations.
The cons regarding the limitations on doing few if any customizations and of having to rely on a SaaS vendor to correct problems are not necessarily as much of a con as they seem. Customizations ARE nice, but the work that goes into making and maintaining them is often a lot considering the small gain the customization provides. The idea of diminishing returns definitely applies here. When it comes to relying on a SaaS vendor to take care of problems, it can be a big relief and time and effort saver to have that responsibility rest on someone else’s shoulders.
There is a lot for libraries to like about SaaS. It is not perfect and will not be the best solution all the time for all situations in all libraries. As is usually true of any technology decision, it is best to evaluate on a case-by-case basis, but based on my experience it is a great option libraries should always examine closely. I am certain it will be frequently judged the best solution.