Services for intermediate consumers

Google, Yahoo!, Amazon …. For many these services are the first and last resort of research. They exercise a major gravitational pull on users [*]. We are rightly preoccupied with their impact on library services.
A major reason for this is because we recognize that increasingly these are the windows through which users see the web world: not to be in Google or Yahoo! is to be ‘off-web’, hidden behind yet another interface. To be ‘on-web’ is to be visible in a search engine result list. The search engines are a central part of people’s *-flow (workflow, learnflow, researchflow, musicflow, …) [*]. We want library collections and services to be available within those flows.
However searching on the open web is only one workflow, albeit a very important one. The learner may spend much of their time in a learning management system. The web-user may rely heavily on an RSS aggregator.
These workflows raises a major issue for library systems moving forward. Increasingly, users will be supported in their various workflows by various systems environments. And, it is the systems which support these workflows which becomes the consumer of library services. The model in which an end-user consumes library services at a human interface will continue; but the model in which library services are consumed by a system which supports a user workflow will become increasingly important. The learning management system, the enterprise portal, the RSS aggregator, the search engine: these are all intermediate consumers of library services.
So a major question for the library becomes: how do I expose services to a search engine? to a learning management system? to an RSS aggregator? And this really moves us to think quite seriously about the types of services we make available, and how we make them available.
Take the current example: the search engines are making us think much more seriously about the difference between discovery (identify what objects of interest exist), location (identify services on instances of those objects) and fulfilment (consume one of those services). So, we might discover that something exists in Google but then be passed to a variety of location and fulfilment services (buy from Amazon, buy from used bookseller, locate in a library near you through open worldcat, be directed to a local catalog by a resolver routing service).
Over the coming months, a major issue for libraries will be how to integrate the Google Scholar article discovery experience with the library location experience – in other words how will a user who discovers an article in Google Scholar, for example, be connected to a service which allows them access to a library copy they are authorized to use?
A couple of takeaways. This way of thinking moves us towards a more service-oriented perspecive: a modular approach which encourages flexibility of service building and exposing. However, there is a prior issue: What are the services that we should expose? How should a library be visible in a learning management system, in Yahoo! or Google, in an RSS aggregator, in a university portal?
We are moving beyond our shared sense of library services, encapsulated in the Integrated Library System and the organizational patterns of the last 15 years or so.
We need better ways of framing and naming our new environment so that we can clearly talk to these intermediate consumer communities about service and value.
* Hey, you can repeat yourself in a blog 😉