flatlands and failures of curation

As a counterpoint to my last post on the rise of the verticals, I've been thinking about the importance of horizontal library collections. On the one hand if a library wants to make a difference in the web environment, they should develop unique vertical collections that focus in on particular subject areas and are of interest globally.

But what of the notion that libraries, particularly college libraries like my own, should provide their users with a strong general collection in line with their institution's curriculum? In the long tail, hybrid print/digital environment of the early 21rst century, this idea of a broad and shallow local collection perhaps doesn't make as much sense. As we try to expand our patron's information universe with consortial borrowing and large aggregations of e content, not to mention awareness of what's out there on the web, the idea of a limited general book collection seems quaint, like your neighborhood book store.

Somehow, we still want our patrons to be able to be able to identify the most important works in a subject area without getting overloaded with choices. One might argue that Google's success is based on doing something like this for the web as a whole. Google is able to reliably pull up the most popular and trusted websites on a given topic.

Our discovery systems need to do a better job of giving some relief to the information landscape. Our users should be able to tell if some titles are more popular, more widely cited, etc. than others. If a text is a classic work of literature or a classic in the field, it should be obvious s in search results.

Ranking search results based partly on the number of holding libraries like WorldCat.org does is a step in the right direction: the collective intelligence of collection development work, if you will. FRBRization is another one. Use of citation analysis could be another. Folksonomies and recommendation engines another. Human curation also has a role.

The commercial world is getting good at using these techniques. Libraries really have a chance to lead in the FRBRizaton arena, I think. This is something the commercial world hasn't figured out, as Mike Shatzkin points out out here:

Recommendation engines aside (”based on what you bought before, have we got a book for you!”), online book retailers have a long way to go to enable the customized curation that seems both possible and desireable in the digital age. Even as sophisticated a retailer at Barnes & Noble will present multiple duplicate entries of a public domain scan from Google to an ebook search for a Shakespeare play. And even as sophisticated a retailer as Amazon will sell you a Kindle ebook that is a self-published tome in a way that is indistinguishable from a book from a legitimate publisher. These are failures of curation.

Economist on Google Books

The Economist has a leader supporting the Google Books Deal, and an interview with Paul Courant, Dean of Libraries at Univ. of Michigan.



He talks some about the product that Google will be offering to libraries with this deal.

I have to wonder if this product will be the watershed moment for e books in academic libraries. If Google's library of books is big and broad enough to serve as a general library on its own, Google's platform for e books could become the place to do research in books.

Much of its success will depend on how much current content is in their index, and this is really dependent on Google doing deals with thousands of publishers. If Google's index is largely made up of older scanned books, it'll be a useful research tool, but not compelling as place for general research.

Google might become the place to do research in books, whereas recreational e book reading will happen through other vendors like Amazon.

Middlemen

Nick Carr has an interesting take on Google as the "middleman", how it has sort of stolen that role from the newspapers. Funny, I was just talking about newspapers and libraries as "middleman" organizations threatened by the Internet in a recent post.

I'm not sure I agree with his prescription for the news business.

thinking more about OneBoxing WorldCat Local

I just checked with our implementation guy at OCLC about including some code in the header of our WorldCat Local instance that would allow us to add customized widgets into WorldCat Local search result screens. Sounds like it's a no go for now. WorldCat Local has a refreshingly simple branding customization options compared to what we're used to with Innovative's OPAC. But that simplicity will keep us from inserting some magic Javascript to achieve the OneBox effect.

I'm not sure if I was clear enough about what I'm interested in. Another way of looking at this is analagous to Google Ads. Google has established that placing context sensitive ads alongside search engine results is an effective way to drive traffic to advertiser websites.

If WorldCat Local becomes our library's search engine, shouldn't our library be able to put context sensitive "ads" next to results? These "ads" (or OneBoxes) would appear based on the search term and offer things like:

• links to library created research guides that seem relevant to search at hand
  
• links to course reserves if a prof's name is searched
• results from a site search of our library's site
• image results from ARTstor (ala Google images)
  
• results (if any) from the library's digital collections

To offer something like this, OCLC wouldn't need to do anything unprecedented. Lots of web applications (including this one I'm using right now, Blogger) allow you to embed bits of HTML. Javascript widgets inside OPACs have been around for awhile too, a prime example being LibraryThing for Libraries. If OCLC put the search results data into some nicely formated JSON and allowed Javascript to be inserted in various places, it wouldn't be hard for libraries or third parties to build these little things.

The WorldCat API is nice and all, but who (besides Terry Reese) wants to build an entire interface from scratch using it?

Click on the image above for an illustration of the WorldCat Local OneBox concept.

moving into to the cloud with Google Analytics

My experience with web statistics applications provides a good example of the move to cloud computing. Back in 2001, I recall painstakingly configuring our $900 copy of WebTrends desktop app and having to remember to download log files once a month. Then in the mid-2000s, we switched to the open source Webalizer, which conveniently is web-based and resided on our Linux server. Still, there was plenty of monkeying around with log files and cron jobs to get it to record the right data.

About a year ago, I got turned onto Google Analytics. It's powerful, super easy to configure and customize. It resides in the cloud. And its "free".


The usage pattern for the Watzek Library web site goes in pretty consistent waves, with troughs as the weekend approaches and and crests as the week starts.

Every hit on our website now gets registered on a Google server. So many sites are using Analytics now, it's amazing how much traffic and data Google is digesting. With "utility" services like Analytics, they are truly making themselves part of the basic infrastructure of the Internet. Their offer to host popular Javascript libraries fits into this as well.

virtual bookshelves, shared bibliographies

L.D. has some commentary today on Google's patent application for a virtual bookshelf, covered in the SEO By the Sea blog.

In the last few years we really have seen quite a few online applications emerge for organizing "intellectual resources", be they websites, articles, books, etc. On the Web 2.0 end of things, del.icio.us comes to mind as well as LibraryThing . On the academic side, there's Zotero and Connotea, and CiteULike, among others.

Our Environmental Studies program here at Lewis & Clark is really trying to develop interdisciplinary student research. Part of the vision is, over the years, to develop a collection of research resources and data that students can draw and build upon as they do their research. Some of these resources would be primary, that is work generated by the students, and some would be secondary.

So far they've been using Moodle's out-of-the box build your own database feature to put this shared collection together. This presentation, from NITLE's Scholarly Collaboration workshop at Pomona last January, explains the system.



But they're looking to move to something different, something more flexible and social with tagging capabilities, but also with some ability to add structure to metadata. The problem is, most of the above mentioned apps are geared towards personal collections, not group collections. Some have a group feature or a sharing feature, but none really support a robust collaborative bibliography feature. For example, RefWorks supports publishing bibliographies to a shared campus wide web page, but its a really primitive feature.

My read is that it could really be useful to develop software that supports creating fairly sophisticated shared bibiliographies. Such software could offer multiple ways to organize resources, including concept maps and perhaps various other visual approaches. Integration with library resource management systems like link resolvers and catalogs would be key as well as integration with the personal bibliography software. This kind of software could enable an academic department, a group of scholars, or a whole college or university to collaborate more across disciplines and enable student research that better acknowledges and builds on research that was done before. If it was done right, it could be a really attractive resource for students as they do research and find themselves curious about what others have done.

how could Google help search in academic libraries?

John Wilkin has an interesting post about various ways Google Scholar could add functionality that would help academic library patrons get to the specialized databases provided by academic libraries. Interestingly, he brings Anurag Acharya, the guy who created Google Scholar, in on the discussion. The ideas generally have to do with learning about the user's needs and then pointing them to the more specialized resources. The post really addresses the problem of metasearch, that is, finding a way to give users a simple, single search box and get them from there to some of the richer, more powerful databases produced for academic research.

But what about once a library patron is in a research database like MLA Bibliography, Historical Abstracts, or Psychinfo? Many of these resources are fairly primitive when it comes to the search functionality and content that they cover. Often you get to search the citations, abstracts, sometimes the fulltext of academic articles. Sure, sometimes more is less, but typically, they don't cover the increasing amount of scholarly material that is out there on the open web. They also certainly don't offer the fulltext of books.

If Google (or another big search vendor) offered a platform that database vendors could mount their systems on, those vendors could make so much better products. Services available to the vendor could include:

• access to Google search software
• ability to create an continually updated index of portions of the web alongside proprietary data
• ability to provide advanced search functionality and data analysis specific to the needs of a particular discipline
  
• access to Google Books index

Google already sort of offers some of this functionality with its APIs, which could allow mixing results from things like Google Custom Search and Google Books into results from an external resource. But I'm thinking here of an even deeper level of integration. Imagine Historical Abstracts if it also included high quality history websites (including digital archives) and the full text of books in its results.

I suspect that it wouldn't be worth it to Google to design a product for the library research sector. This would need to be an infrastructure product that could span proprietary search needs of multiple industries.

When we got a Search Appliance here at Lewis & Clark, I have to admit, I was kind of disappointed playing around with the admin interface, that you couldn't easily mix in parts of Google's web index with your own proprietary stuff. Guess this is sort of what I'm asking for here.

Scirus is sort of a development in this direction, that is a hybrid of the research database and search engine. Another sort-of-related idea: Dan Cohen has called for Google Books to open up its APIs for scholarly inquiry.

Some folks will no doubt be horrified that I'm suggesting putting more of our eggs in Google's basket. But the idea really is about bringing web scale infrastructure to the service of more specialized, niche needs. Not giving ourselves over to Google, but rather using their data and software as a platform on which to accomplish bigger things.

Open Source and the Cloud

Lately, I've been thinking about how the cloud computing model of providing software intersects with the open source model.

We've all gotten pretty comfortable with supporting Open Source apps that utilize a LAMP stack, Wordpress being a good case in point. This model works very well, generally speaking, but there are a couple problems with it, from the perspective of cloud computing.

• First of all, if you use something like Wordpress, you regularly need to update your code and you need to deal with various compatibilities as you migrate systems. I really like applications that just kind of upgrade themselves over time, like GMail.
  
• Second, applications that are installed as single instances on multiple servers can't leverage Web 2.0 style network effects like single installation, web scale applications can (eg Flickr, YouTube, WorldCat.org (what, did, I just call an OCLC product Web 2.o?), etc.).

The recently released Omeka product got a lot of things right, I think. It's really a Web 2.0 digital collections system that allows for TWO-WAY interactions with collections.

We're eager to try it out here at Lewis & Clark. To get it up and running on our server, I had to upgrade MySQL from 4 to 5. This broke our compiled version of PHP. A newly downloaded version of PHP fixed things, but that broke a couple other components on our web site. A few hours later, all was well, but the point is, loading and running something like Omeka does still require some "heavy lifting" on a sysadmin's part.

The other element lacking in Omeka is the fact that its data isn't part of a larger system. Sure it's harvestable and can be syndicated through RSS, but it's not part of a greater, two-way information ecosystem.

So how should Open Source projects be done in this cloud computing environment? Code should be shared and improved by a community and those improvements should be tested and then applied to a centralized running instance of the application.

Google has just released a platform that would work well for this sort of model, called "Google App Engine."

Google Sites

As mentioned previously in this blog, as former JotSpot users, we've been eagerly awaiting Google's re-release of the JotSpot wiki technology. Well, it just happened with the release of Google Sites.

Google is only releasing Sites as part of their Google Apps for Enterprise suite, so it was a little hard for us to access it, being a department in a larger organization. Our IT sysadmin had signed us up for Google Apps for Education (just to trial it), so I had to contact him to enable access, which fortunately wasn't a problem.

We may try out sites for our departmental intranet, which serves to manage policies, procedures, etc. for the library.

Sites is a fairly nice, easy to use wiki, definitely up a level from early wiki software. It allows for very modular page layout with easy insertion of widgets like Google Gadgets or spreadsheets, documents, and presentations from Google Docs.

The feature set strikes me as fairly basic however. It really does not aspire to be the "programmable wiki" that JotSpot did. With JotSpot, you could basically create these little database-backed applications with some pseudo-programming.

Another thing that's a little disappointing is the lack of integration with Google Docs...it's easy to post a Google Doc or spreadsheet on your page, but you have to copy the url to it and it can't be edited right there within the page if you want it to.

The access control options are pretty limited, too. We have parts of our intranet that we'd like to wall off from the rest of the world and parts we'd like to show off. With sites, access is controlled at the level of the whole web site. We thought that we might work around this with access control on individual Google Docs.

There are plenty of up-and-coming wiki options out there like Wet Paint, but I have a feeling we may go with Google Sites because we're enjoying Google Docs so much and it's nice to have things in the same ecosystem. Funny, Google is managing to make this web-ecosystem application tie-in that might be called similar to Microsoft's desktop and Office strategy. And it seems to be sort of working.

Currently we use an old fashioned static web site with Macromedia Contribute editing software for our staff web site/intranet. I'm thinking the advantages of Google Sites would be:

• moduler - we can drop dynamic elements like RSS feeds from basecamp project mangement right into our pages
• easier to edit - wiki style, no filesystem confusion
  
• search is included
• integrated with Google Docs
• access management may be easier than what we use now (Apache .htaccess)

warnings on Google

A few interesting posts recently that emphasize the danger that Google's size poses to innovation in the web/digital publishing environment:

Nick Carr makes the case that the massive amount of data Google is accumulating will give it a huge competitive advantage over other firms. Tim O'Reilly, points out that Google is hosting more and more of the content that it indexes, rather than indexing others' content for them. The Knol, is a move in this direction. This is akin to a financial firm trading for its own benefit rather than for its client's benefit. Peter Brantley discusses the issue in the context of research libraries.

In the late 1990s I was very anti-Microsoft and avidly favored the anti-trust litigation against them. For some reason, I just don't see Google in the same "Evil Empire" light. I guess I appreciate Google as an innovator. They have done a lot for search and the general move towards cloud computing. Their library project is bold in scale as well as legal approach in a way that never would have happened in the non-profit sector. Google's products are actually really good and cutting edge, whereas Microsoft's, by my experience, were always behind the curve and sort of sucked. (Microsoft, on the other hand, is a company to "admire" from a business perspective, not so much a technology perspective, because they've been able to rake so much money in for their mediocre products. )

Like Microsoft, Google will be unseated in due course. Skrenta is working on it. I do appreciate the skeptics out there keeping an eye on Google.

Knols

Talk of Google's Knols is spreading quickly across the blogosphere. This strikes me as a venture into online publishing, kind of on par with publishing a traditional encyclopedia that has entries published by paid "experts."

I see this as a welcome development that will compete with and compliment Wikipedia rather than subvert it. As a side effect, it also may further erode usage of the kinds of reference tools that libraries purchase and provide to users.

I'm sensing that there is kind of a backlash against Google from the Wikipedia community on this one. But I say let them have a go at it. This is just another experiment in a form of online publishing that may or may not catch on.

One might worry that Google will force this stuff on their search engine users. But supposedly "editorial integrity" of search engine results is one of their guiding principles, and that would mean that if a Wikipedia article was more relevant than a Knol, it would still rise to the top.

How in the world did I get to be so pro-Google?

Google Universal Search as federated search approach

The Google Operating System blog offers some thoughts on Google's evolving approach to Universal Search (where they group results together from various Google indexes--Web, Books, Images, News, etc.). Even though Google has direct control over its various search 'silos', they are not trying to mix results together in Universal Search. Whether this is due to technical limitations, usability, or a combination of both, we can't be sure.

Trying to intermix and collectively rank results from a wide variety of search systems never seemed like a good approach to me, but that's just what many libraries have been attempting to do with federated searching. If Google can have its silos, why can't we have ours?

Maybe the Google approach reflects the utility of searching for the same type of media: news stories, web sites, images, products, etc. within the same search. Following on this logic, should we stick with the idea of keeping article searches separate from books in library search offerings?

Our library is thinking through these questions as we attempt to package our major search options into a search widget for our website.

OCLC and network level services

OCLC is loading up on the big names in the digital library world. Of course, they've had Lorcan Dempsey for awhile. They recently picked up Roy Tennant and most recently, they hired Andrew Pace as Executive Director of Network Level Services. That job title makes me think that Dempsey had something to do with designing the job. An old OCLC hand out here in the Pacific Northwest recently referred to him as "Lorcan our prophet." Apparently he really does have a hand at shaping company strategy.

I know Andrew Pace some from the '06 Frye institute and offer my congratulations to him. I always used to see his columns in Computers in Libraries and think he was just another dork writing about library technology. At Frye, I discovered that he's a pretty enjoyable and interesting guy to listen to and in person is always dropping this funny, sometimes southern flavored aphorisms when describing various dilemmas and situations in the library world. I guess "lipstick on a pig" might be an example. I think he'll do a bang up job in this new position. As much as he's a thinker and observer, I know he's also a doer, as the NCSU catalog demonstrates.

In my humble opinion, OCLC has a lot of work to do on their "network-level" services. Here's a few areas where they could stand to improve:

• ILL: the current mish-mash of products for managing interlibrary loan is pretty lame and is a real time sucker for library systems people. In most situations, these include an ILL management system (Clio/Illiad) for workflow management and patron interaction, a system for sending and receiving documents (Ariel), and the OCLC resource sharing network. There's no reason that OCLC shouldn't be able to provide a comprehensive ILL management suite including document exchange, workflow, and patron interaction as an entirely web-based, hosted tool, and offer it as a basic part of their ILL service.
  
• Digital collections software: ContentDM is a relic from the 1990s. It's a strange hodgepodge of C code and PHP, is clunky as hell, not to mention that it produces the ugliest looking URLs and no page titles, making it terrible for search engine crawling. Someone good at Ruby on Rails could build a better piece of software in a weekend. (Perhaps I'm just a little annoyed with it right now because I've been working on getting a Google Search Appliance to index our ContentDM collections) OCLC should be offering a fully hosted, web scale digital asset management system with web-based client software on par with somthing like Flickr. They could offer migration from ContentDM
  
• Semantic web strategy: OCLC needs to follow the Talis into the semantic web space. They need to be designing systems that share data in an open fashion.
  
• WorldCat Local: This is where OCLC has got it most right recently, in my opinion. If they add an API, and make the UI more customizable, and allow for localized versions of records, they'll be in business.
  
• Partnerships with large-scale players: OCLC is positions to make partnerships with big players in the information space like Google. They've found ways to bring library assets into Google's space, perhaps there are ways to bring Google assets like Scholar and Books into the library space (a Google Books/WorldCat Local integration?).
  
• Data exchange: if you've ever had to get your data up to OCLC in batch form, you've most likely experienced pain on par with visiting the dentist for a minor procedure. Their procedures for doing things like local data record uploading are horrendously slow and bureaucratic. WorldCat will never truly be a universal catalog for library assets if OCLC can't streamline methods for updating data in WorldCat.
  

The team at OCLC has their work cut out for them.

waiting for Google's JotSpot

At Watzek Library, we're using a combination of static web pages maintained with the Contribute/Dreamweaver suite, Basecamp project management, and Google Docs to create/maintain our intranet.

I've been wanting to move us off static web pages and on to a wiki for awhile, but
I'm waiting to see what Google does with the JotSpot wiki platform. The beauty of the JotSpot wiki platform is that you could build applications on it such as simple databases, project management systems, etc. Basecamp is nice, but isn't quite up to Google Docs in functionality. Combining that with Google Docs could be pretty powerful.

Haven't heard much news on this front for awhile.

Google Book Search Local

So here's an idea...

The Google AJAX search API makes it pretty darn easy to create a customized Google Book Search for your own web page. The API will return an identifier (which is typically an ISBN) for the book, among other metadata in results lists. Why not use a little JSON and JQuery to figure out whether or not your library holds the item and insert that information w/ link in the results? A database of your library and/or union catalog holdings would facilitate the task.

This would create a nicely localized version of Book Search for your library.

Google Digitization and the CIC

Well, I'm glad to hear that Google is moving quickly with the big consortium of university libraries in the Midwest to do more digitization. The ivory towers on the coasts can't have all the fun, right? My academic home, is of course, the University of Wisconsin-Madison, and I grew up in Minnesota, so I have a soft spot for this group of libraries.

This time around they are doing selective digitization, based on collection strengths. On their press release page, they offer a description of collection strengths, which I found interesting. Nortwestern U has a big collection of Africana, for example. I was a little nostalgic noting that one of University of Wisconsin's great strengths is European History and Social Sciences. The beauty of studying modern German history there was that if you were looking for any book on Germany published in US or Europe within a certain timeframe (the 1950s-1970s I think) you could practically count on it being there. The comprehensiveness of the collection seemed to diminish as you hit the eighties and tighter university budgets took effect.

One thing not to overlook here is that this goes far beyond English-language content; these books will be useful well-beyond the English speaking world. There is going to be tons and tons of non-English material in this collection. I can recall shelves and shelves of books in Polish, Chinese, Russian, German, French, etc. wandering Memorial Library stacks in Madison. I imagine that American university libraries are the most effective place to start for collections that span the world's corpus of written works.

Lorcan Dempsey sees this as a big step. He rightly points out that with this comprehensive data, Google is going to be able to build services that no one else can:

However, as we are beginning to see on Google Book Search, we are really going beyond 'retrieval as we have known it' in significant ways. Google is mining its assembled resources - in Scholar, in web pages, in books - to create relationships between items and to identify people and places. So we are seeing related editions pulled together, items associated with reviews, items associated with items to which they refer, and so on. As the mass of material grows and as approaches are refined this service will get better. And it will get better in ways that are very difficult for other parties to emulate.

By "other parties" I think we can read OCLC, who is doing their best to leverage all of the data in WorldCat to develop structured relationships between intellectual works, their authors, and subjects. Will Google learn to do FRBR before OCLC does?

The libraries that are party to this deal get to keep the digitize texts and do their own things with it. Will this give these big universities a "strategic advantage" over some of their competitors? Does this mean that size still can matter in the networked environment? This reminds me a little of the NITLE initiative, the original intent of which was to overcome the disadvantage of small sized liberal arts Colleges in the information technology arena. Here's an example of an area in which us small folks can't compete--we just don't have much unique material in our libraries. But I guess the point is that everyone can access this stuff to some extent through Google.

tweaking Google search

NYT has a nice piece that goes inside Google's 'inner sanctum': the search quality department. It gives you some illustration of how worked-through search is in Google, and how far ahead of the competition that they are.

At one point, they discuss the impressions of a recent recruit from Amazon to the department:

When he arrived and began to look inside the company’s black boxes, he says, he was surprised that Google’s methods were so far ahead of those of academic researchers and corporate rivals.

“I spent the first three months saying, ‘I have an idea,’ ” he recalls. “And they’d say, ‘We’ve thought of that and it’s already in there,’ or ‘It doesn’t work.’ ”

I think the best thing that we can do in academic libraries is try to co-opt this technology for our more focused purposes. I hope Google can keep their systems open enough for us to do this.

One small way we're thinking about doing this is including Google Book Search results on our OPAC search results page using their AJAX search API. Here's hoping that they soon add Scholar support for the search API.

Google's API for their search appliance

Interestingly, Google says that it's releasing an API for their search appliance that will allow the appliance to tap into lots of external content stores. I wonder if this could be adapted to an ILS, digital collections system, or some other application in libraries.

Google Universal Search

Lorcan Dempsey points out that Google's just introduced a strategy to bring together results from many of their vertical search engines (books, images, web, video, etc.). It's called "universal search". This would have been a good thing to bring up at the presentation I did on federated searching at the Oregon Library Association conference. I was trying to make the case that search engines are really the future of federated searching, or at least worth looking at for important trends.

Unfortunately, they don't mention bringing Scholar on board universal search. I'm also wondering about the ability to integrate search appliance results with Google Search engine results. We're thinking of indexing some of our local content with an Appliance, and if we could mix results from the Appliance with Google Web and Scholar results, maybe we could put together something like federated searching with Google technology.

network apps and the demise of centralized IT

Some observations...

• We're seeing more and more powerful network based applications, available for free on the Internet: GMail, Google productivity apps, Flickr, etc.;
• Often, these applications are arguably, the best of breed in their class; they work better than anything you'd pay for and install on your desktop or on your network's local servers
  
• People can adopt these applications independently or in small communities within their organizations; no central coordination or IT support is necessary;
• They can be used across organizational boundaries--folks from different companies or universities can dive in an work together;
• They can, increasingly, be purchased and adapted to an organizational setting (see Google Apps)
  

As network-based applications mature and we see more of them become available in niche areas, a dramatically reduced role for centralized information technology support in organizations. Central IT used to be a necessity because of the infrastructure required to support systems. Technology support will gravitate to the edges of the organization, with the focus shifting to the rightful application of the technology rather than technology as infrastructure.

This, I suppose, will happen faster in loosely coupled organizations like universities. In the university environment, I can imagine administrative computing being done between the business office and the registrar, with relevant applications hosted off site in a salesforce.com style. The public web site designed and maintained by the communications office and hosted by an off site firm, including supporting back end databases, search services, etc. The communications systems (email, groupware, etc.) will be chosen and maintained by organizational development folks in HR. Academic technology will be applied in an ever diffuse fashion, with communities of practice developing across institutional boundaries, and institution-specific applications like CMSs maintained out of a Center for Teaching and Learning. Libraries have already seen a lot of the tools that they offer become remotely hosted web applications, and in some ways, they will lose more control. Their role will be facilitation and customization of these networked-applications.

IT will be there to support the plumbing: keeping up network and the relevant devices. Even some of the plumbing, especially data centers at smaller organizations, will go away. There will also be a persistent need for integration and standardization. But the strategic role of centralized IT will diminish, just like it did for those VP's of electricity in the last century according to Nick Carr.

A centralized IT operation was important in the past because you could aggregate software/hardware and knowledge in one place. But following that model was always dangerous as it removed those working on the IT from the parts of the organization that IT was designed to serve. As the support for equipment and software becomes more easily outsourced on the network, we'll see centrifugal tendencies accelerate.

The IT department that tries to maintain control too tightly will get "worked around" and just accelerate the phenomenon.