Stitching costs - retread

I am on vacation and traveling this week, and so am taking the opportunity to air again an entry of a couple of years ago on what I called ‘stitching costs’ ….
We are familiar with switching costs, the costs of changing a supplier. I may decide not to change my phone or email arrangements, for example, because I do not want to incur the effort of notifying all my contacts. Libraries are very familiar with switching costs given the range of data migration issues involved in changing library systems. Indeed, high switching costs are one reason that libraries often stay with the same vendor for long periods.
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.
Think for example of the website integration issues libraries have where they want to provide unified access to the catalog, to licensed resources, to repositories and so on. The intermittent levels of integration we see are because the ‘stitching costs’ are high.
This is largely because they are providing a thin layer over two sets of heterogeneous resources. One is the set of legacy and emerging systems, developed independently rather than as part of an overall library experience, with different fulfillment options, different metadata models, and so on (integrated library system, resolver, knowledge base, repositories, …). Another is the set of legacy database and repository boundaries that map more to historically evolved publisher configurations and business decisions than to user needs or behaviors (for example, metadata, e-Journals, eBooks, and other types of content, which may be difficult to slice and dice in useful ways).
Or think of higher level federation across library services. We have few compelling federated services, whether these are based on metadata harvesting, metasearch, or other approaches. Again, this is partly because of high stitching costs. I cited Jerry McDonough’s article the other day about how abstraction and optionality in library standards design creates unhelpful variation in implementation which in turn is a barrier to efficient interoperability.
Things are changing, as it becomes more important to effectively stitch library resources into other environments and as lighter-weight approaches get adopted. However, it is useful to bear stitching costs in mind when there is discussion of approaches based on federation and interoperability. These costs may be to do with technical issues (interfaces, metadata, …), or policy issues (ILL policies in a resource sharing system, for example), or higher level organizational and resource allocation issues (who will run the federation service, etc). And they are very real.
[This entry first appeared on October 8, 2008.]