Lorcan Dempsey has a blog post about ‘stitching costs’ that gives me some useful language to plug Umlaut some more.
Libraries are also familiar with high ‘integration’ costs: perhaps these might be called stitching costs. This means that it may be costly developing higher level services based on integration of various lower level services.
Umlaut is in part intended to deal with ‘stitching costs’ for one class of services: “known item services”. And also with where ‘stitching’ and ‘switching’ intersect — once you’ve integrated a bunch of your services in a rube goldbergesque contraption, then part of the cost of switching one of the underlying services out becomes the ‘stitching’ of the new one into your overall aggregate system. An issue more and more libraries will probably start running into, as more have developed such ball-and-twine systems of integration over the past few years, possibly in such a way that the first time one of the underlying components need to be switched, it’s going to be painful.
The idea of Umlaut is that it’s a platform that you can easily write plugins for to consult various internal and external sources of data on ‘known items’ (catalog, link resolver knowledge base, worldcat, Scopus, whatever). The platform is there for you so you can just focus on the source-specific logic in the plugin, is the idea. Then Umlaut vends the aggregated information collected through both an HTML web page, but also several APIs designed to be as easy to use as possible, so you can embed the aggregated information in whatever other services or web pages you want.
There is a full api (delivering in XML or json), as well as an API that delivers a collection of HTML snippet sections ready to be dropped in as-is on a foreign web page. Both APIs provide incremental results with information on what services are still fetching data, for polling. (As fetching data from various external services can end up being slow).
So theoretically, once set up, this should decrease both the ‘switching’ and ‘stitching’ costs of individual elements in your infrastructure. Switch out a source of known item data? No problem, just write an Umlaut plugin for the new one. Switch out a service that consumes known item info from Umlaut and delivers it to users? No problem, the new service just needs to access Umlaut’s easy to use APIs.
Now, in practice, it is admittedly not necessarily quite so simple as I mkae it sound, as writing both writing an Umlaut plugin and making a new product access and deliver info from Umlaut’s APIs can be significant tasks — but I’m convinced that this architecture significantly lowers stitching costs, and switching costs due to stitching costs, in the long run.
As a chief example, it should theoretically allow us to consider ‘link resolvers’ just in terms of quality of knowledge base, without worrying about the link resolvers own interface. As Umlaut accesses the link resolver knowledge base via api and provides it’s own (html and api) interfaces, if we decide that there’s a better product for it’s knowledge base, we should be able to write an Umlaut plugin for the better one (as long as it has an api), switch it out, and not only will our user experience be mostly unaffected, all existing ‘stitched’ services will not have to be touched a bit, they’re still talking to Umlaut, which just has a new plugin data source. This depends on the desired new link resolver having an PI which is sufficiently robust and performant for Umlaut’s needs, but not on any of the desired link resolvers own presentation features.