Introduction
SOA is a systems design architecture approach / philosophy that has been around for a while, but one that has come of age. It is also a difficult concept to explain to non-developers and those without a technology orientation. The documentation for SOA is pretty thick and gos generally written for CIS professionals. It is an important concept that librarians need to be exposed to as often as possible.
The move towards SOA for library systems has the potential to improve the ROI by providing a better access to and aggregation of the information resources we license. For example, with SOA consortia libraries could work together to build systems sharing common bibliographic / resource data and then build customer interfaces and search systems which look and work quite differently. SOA can allow libraries to use and improve information resources contributed by others and customize its delivery to customers.
Marshall Breeding is one of several that have been discussing SOA approach for some time, as has OhioLinks' Peter Murray and CISTI's Richard Akerman.
The adoption of the SOA models can enable libraries to evolve into stronger organizations at the very moment in time that the use of libraries is becoming just another piece of the customer’s information seeking experience. All librarians, especially library leaders, need to understand SOA.
Traditional Library System Design
Most current (and legacy) library systems take on the structure depicted by the graphic below:

Each of the systems that libraries use are self-contained silos. Each has its own embedded database/data structure, built-in search tool, and presentation / interface layers. Each requires library customers to use its unique presentation and search tools to access its unique content. Each has a completely different look, feel, and functionality.
From the user experience perspective, this system design strategy is why it is so difficult for librarians, let alone library customers, to find Time. It is also why many libraries have spent a great deal of resources creating extensive educational programs to teach how each of our systems work.
The silo structure (or, as I also like to refer to it: monolithic structure) is also one reason why we have difficulty in getting our services integrated. For example, this structure almost requires libraries to purchase interlibrary loan management systems with integrated Internet document delivery tools. What if we do not like the built-in Internet document delivery tool? We are either stuck using a system we do not like or run two, three, even four different systems and build work flows around them!
Lastly, the data/content we create becomes fixed within each silo. The costs in real dollars and staff time, required to export, convert, and import are some times so significant that we hang onto our systems and rarely change. This results in a phenomenon called 'lock-in' which vendors are not only aware of - they build business models around it! It creates an effective library systems paradigm which libraries have not been able to break away from.
Modular Library System Design
SOA is essentially a modular software design philosophy which facilitates the flexibility and responsiveness required in a changing environment. Individual software pieces are build independently and can either be interchanged or repurposed. SOA utilizes 'loosely coupled' systems that expose their resources and content as independent 'services.' These services can be combined to create new systems and services. The most visible result of the SOA approach is the emergence of web mashups.
The best analogy I have found to get a handle on SOA is the early twentieth century automobile assembly line. It is also important that the concept of web services which is tioed to the concept of SOA not be confused with services available on the web. Web services in this context refer to a specific type of application built on an architecture that offers the promise of allowing any client to work with any server, anywhere in the world.
The graphic below depicts how just one library system, the ILS, could look like using the SOA approach. In this example, the bibliographic database, circulation, and authentication systems have been decoupled from the discovery tool and presentation layer (customer interface).
Each of the services (circulation, authentication) or the presentation layer could be replaced or updated with minimal impact on the overall system/service. For example, a library could create a social web interface to the ILS without touching the bibliographic, circulation, and authentication services. An SOA ILS would not have to rely upon a built-in circulation service, but could 'plug in' one from a commercial vendor or one that is built locally. The data collected could would not be embedded like a 'silo' ILS and could be maintained over generations regardless of the changes made to the other ILS modules.
Another advantage to the SOA approach is control over the bibliographic data. It is common for ILS vendors to 'lock' the bibliographic data into the 'silo' ILS using proprietary data systems and formats. The costs associated with the export and conversion of this data may be the single most significant reason libraries rarely switch ILS systems. With SOA, the local bibliographic database can be replaced by a web service. (This currently fictional web service could serve as the foundation for the next generation SOA ILS. Hint, hint, OCLC). The use of a bibliographic web service would not only remove the retro-conversion barrier, it eliminates the need to maintain a local bibliographic database all together!
Before the catalogers out there react to the previous paragraph, if the library wanted to create a localized database for special collections or supplemental information they could do so. They could create a database using common tools, expose it as a web service, and simply 'plug it in.' This new web service could be shared with consortia wishing to aggregate special collections resources or it can be 'mashed' together with other web services.
Changing the User Experience
An earlier graphic depicted the challenge with all of the various systems that our customers must navigate. The graphic below depicts the beauty, and complexity, of this approach.
With such a design, all the systems would be loosely coupled. Direct connections to each of our data sources would be available from any of our our web presences. The user experience is enhanced since they could gain access to any of the resources from any of the user interfaces. For example, one could search the course management system and receive results from the eJournals collection.
The graphic above also assumes that libraries would continue to need separate user interface sites. In theory, with SOA the library could create a single Facebook-like portal which would aggregate all networked resources. New library 'web services' could be built and simply plugged in by the customer.
This approach to the design of library systems represents a radical departure from what we have today. At the same time, it provides libraries with an unprecedented ability to create and maintain systems that can quickly adapt to the changing networked information infrastructure. It has the potential to get our resources out to where our customers are.
The web as we currently know it has been built using relatively simple technologies which have been proven to have scalability, efficiency and utility. The next generation web that is emerging will be an 'operating system' on which developers can create reusable and constantly updated information systems. Functionality that has been traditionally performed on systems installed and run on a local computer in a single application will be performed on the network involving many applications running on many computers.
The resulting information systems architecture is not the 'self-contained' single application structure that we have been used to. Instead, it is a Lego-like design of 'loosely coupled' systems referred to as service oriented architecture.
There is an agreement in the more general information systems world that the SOA approach is the way that applications need to be built. The adoption of SOA will not only make our library systems more flexible and agile, but will allow organizations to modernize their legacy applications.
Conclusion: Break Up the Silos
In the “Introduction” of the 2006 issue of Library Technology Reports entitled “Web Services and the Service-Oriented Architecture” Marshall Breeding writes:
In order for libraries to take advantage of the benefits of SOA, some things will have to change. First and foremost, our library leaders need to refocus their collective vision. We need to rethink the services our libraries now offer and how those services are delivered. We need to realign human and fiscal resources into the development of new systems that can change and adapt as fast as our environment."If, in the future, libraries want to be isolated islands in the ocean of content and information, they can ignore Web services. But because much of what libraries do centers on providing information to library clientele and because information is increasingly more electronic—which causes libraries to overlap with many other organizations in the information sphere—it is necessary for libraries to cooperate and interact with a broad set of other organizations and their technical infrastructures. Web services provide mechanisms that allow libraries to expand their services in many important ways"
Libraries in general also need to reduce our reliance on proprietary systems. Sure, libraries can still have vendors build our systems, but we need to demand that they adopt a more open and modular approach in their designs. Our library leadership and professional organizations need to begin demanding that vendors use open standards and open up their APIs. Our library leadership and professional organizations also need to begin viewing open / community source products not only as alternative solutions, but as leverage to force vendors to adopt SOA.
For libraries to retain their market share in the networked world we need to embrace the SOA information approach, now. If libraries do not begin to adopt SOA soon we will not only remain three to five years behind the technology curve, we may never catch up.
Resources
- Akerman, Richard. Library web services. ALA NetConnect. (July 17, 2007).
- Barry, Dounglas K. Web services and service-oriented architectures the savvy manager's guide. San Francisco : Morgan Kaufmann. 2003.
- Breeding, Marshall. Web services and the service-oriented architecture. Library Technology Reports. 42(3). Chicago : American Library Association. 2006.
- Cerami, Ethan. Web services essentials. Sebastopol, CA : O'Reilly. 2002.
- Dempsey, Lorcan. The network reconfigures the library systems environment. (July 6, 2007).
- Iverson, Will. Real world web services. Sebastopol : O'Reilly, 2004.
- Murray, Peter. Defining “service oriented architecture” by analogy. (Sept 18, 2006).
- van Veen, Theo. Serving services in web 2.0. Ariadne (April 2006) 47.
- Wallis, Richard. The future is in web services. Panlibus (July 18. 2007).








anfaan
Invite as author
good article!