Six weeks goes by fast. Yes, it’s been six weeks since OCLC announced WorldCat Local “quick start” as the first step toward a web-scale, cooperative library management service. Not only does that six weeks represent two full iterations of agile development for the three main web-scale components–circulation, print and licensed acquisitions, and license management–it’s also been several interviews, speaking engagements, and lots of pressing product management work.
That is, it’s completely web-accessible. Not browser-based; no massive plugin or extension downloads. It’s not “web-technology based.” It’s web-based.
Reduced Total Cost of Ownership (TCO) and increased efficiency through a unified management platform for all types of materials, regardless of format or method of acquisition
If we had it to do over again, would print and licensed acquisitions be so completely separate? Would vendors and licensors be separate lists? Would it be so hard to cross-train on library management systems?
A flexible and customizable workflow platform
I’ve complained before about all the “twiddly bits” that libraries like to tweak on local systems. I feel strongly that much of this customization replaces what libraries really want–a service that allows libraries to define and/or select the processes (made up of tasks and activities) that define their workflows.
Network effects by sharing applications and data between libraries
Cloud computing is essentially about sharing applications in a web-based scalable way. This is hardly new for libraries that subscribe to databases and ejournals. It is fairly new when it comes to running applications. But libraries also have another tool at their disposal–cooperation. Copy cataloging, resource sharing, and a strong ethos of cooperation position libraries to take advantage of cloud computing in ways that few other industries or organizations would embrace. The potential for building “cooperative intelligence” tools for libraries out of the shared data and shared ethos is nearly staggering. WorldCat Collection Analysis is a fantastic tool, but it is also just he tip of the iceberg.
Concentrated data registries and repositories
Web-scale is not only about high transaction rates. It’s about what Tim O’Reilly refers to as one of the major (missed) themes of Web 2.0–providing access to best-of-class data. Chris Anderson goes even further, writing, “The Web is all about scale, finding ways to attract the most users for centralized resources, spreading those costs over larger and larger audiences as the technology gets more and more capable.”
A Service-Oriented Architecture (SOA) for interoperability with local environments and 3rd party business process systems (e.g., financial management, HR systems, and course management)
The services are being developed with full cognizance that libraries and organizations must interact with business process systems other than library management systems. That is, not only does library software require interoperability with other library software (e.g., self-check, receipt printers, EDIFACT), it also requires interaction with other enterprise solutions like financial management and HR. A service-oriented approach to the development, in combination with the OCLC Developers’ Network empowers libraries to build, share, and maintain the interoperability they need.
I think overall this is a big step in the right direction but please don’t try to convince with the wrong buzzwords. Worldcat Local is not SOA. SOA means breaking your product into interchangeable, freely connected pieces. You only mentioned interfaces to other kinds of services. Can you easily replace parts of your universal worldcat local web application? Can you for instance put VuFind on top of it, upload records via Jangle and get circulation data via another interface? Unless you open the internals, it can be great software but it is not SOA.
It’s worth pointing out that though WorldCat Local and “quick start” represent a first step toward a more comprehensive set of back office applications for library management, they are indeed different applications. The Web-scale management services has adopted a Services Oriented Architecture (SOA) whereby the overall suite of services is decomposed into a set of cooperating, network-available services.
This decomposition:
Promotes re-use at the service level.
Allows horizontal scaling by the deployment of multiple copies of each service as necessary to cope with demand.
Increases robustness through the deployment of fail-over pools of equivalent services.
Promotes loose coupling.
Promotes encapsulation as the unit of sharing is the service interface.
That said, I think the main constraint is always going to (and should) be reason. The focus of the SOA architecture is for internal interoperability and external interoperability where is makes sense. I think interoperability with 3rd party business process systems (like financial systems or HR systems) make much more sense for libraries than creating a Frankenstein’s monster of interoperability. Just because something can be done does not mean it should be. The advantage of starting with SOA is that when we determine which things should be done, they can be.