Using IDEAS to Create an Innovative Library

I have been reading The Game Changer by A.G. Lafley and Ram Charan. The book provides a different way of thinking about management processes to make innovation a central driver of a business. It draws upon the authors experience at Proctor and Gamble. There, they made building an innovative culture a fundamental part of the organizational strategy by using the concept of IDEAS.

Inclusive - the benefits of diverse thinking and ideas

Decisive - eliminating organizational debate and overanalysis to enable faster innovation development

External - being in touch with customers

Agile - able to react quickly to changing customer and market conditions and taking calculated risks

Simple - ongoing streamlining and simplification of structures and processes.

I think that libraries do the inclusive and external parts very well. However, we have a lot of work to on being decisive, agile, and simple.

In fact, we tend to have very specific processes and procedures (committees; task forces) to encourage debate and overanalysis (all areas must be represented) which prevents us from being agile (12-18 month development cycle).

The book also reinforces two other characteristics of innovation that I have learned. First, innovation is not about the end product. It is not about the widget produced. Instead, innovation is all about the new interpersonal connections and the intersection of ideas which emerge.

Second, leadership plays a very important role. Leadership does not mean the administrative organization. Instead, it is about building a pipeline of leaders which allow a culture of innovation to grow and be sustained. These leaders can exist at any level of an organization. They must be given opportunities to lead and learn.

To the Moon on 72Kb

As a child of the 60's, I continue to be interested in space. Specifically, the technology of space. This week, the Science Channel is running a series this week called Moon Machines during their Space Week 2008.

The episode I just watch is called "Navigation."It details the creation of the Apollo command module guidance computer (AGC) by the MIT Instrumentation Lab.

Apollo Guidance Computer Specifications:
Instruction Set: Approximately 20 instructions;
100 noun-verb pairs, data up to triple-precision
Word Length: 16 bits (14 bits + sign + parity)
Memory: ROM (rope core) 36K words; RAM (core) 2K words
Disk: None
Performance: approx. Add time - 20us
Basic machine cycle: 2.048 MHz
Technology: RTL bipolar logic (flat pack)
Size: 24" x 12.5" x 6" (HWD)
Weight: 70 lbs;
Number produced: 75
Cost: Unknown.
Power consumption: Operating: 70W @ 28VDC; Standby 15.0 watts 

There were a few bits of information I thought were interesting:

At the time they were building the AGC the 'integrated chip' was just being developed. It's a frequently cited that the space program and perhaps the AGC more than any other single part of this program that drove IC development, an observation Eldon Hall makes in his book Journey to the Moon. At one point NASA was consuming 60% of all chips being manufactured. They would weight them, then immerse them in a bath of freon. If they weighed even a few micrograms greater they would toss the entire batch away since there had to be some flaw which absorbed some of the freon.

It is common to hear that many of our devices are more powerful than the Apollo guidance computer, but I never heard what the total was until now - 72kb. A $100 MP3 player has 50,000 times more storage space then the computer that got Apollo to the Moon. I think back to the Commodore 64 I had and even it was pretty close to the processing AGC power (I wonder if the MIT guys "peeked and poked")

The programs were literally hardwired and "weaved" together using rope memory.

The computer's other error codes included error 00404, which was shorthand for "IMU orientation unknown." This has been compared to the HTTP 404 "browser navigation" error code, although the later was not based on it.

(If one is really into this stuff feel free to download the GNU Virtual AGC or build a real one in your basement. The original schematics are available.)

8 Drugs Doctors Would Never Take

As a health sciences librarian for almost 20 years, I have many issues with the coverage of medical topics in such popular literature. The latest to get me going is a Men's Health article entitled 8 Drugs Doctors Would Never Take.

Sadly, this article is filled with overgeneralized statements such as "Unfortunately, it seems some doctors rarely pull the PDR off the shelf. Or if they do crack it open, they don't stay versed on emerging research that may suddenly make a once-trusted treatment one to avoid"

Well, for one, I would question how up to date an MD was if they were still using a 'print' PDR. Second, the reader is supposed to trust a popular magazine article that relies upon a single source article and/or the comment of a single health professional to supports the author's argument for placing a drug on the list.

The author, Morgan Lord, doesn't even appear on the Men's Health list of "experts," which include a bartender and "smart New Yorker, who isn't afraid to tell guys what women really want." He doesn't have an MD or even a PhD after his name. Just try to find more information on his credentials as a medical writer. He also writes for Women's Health magazine and is listed simply as an Assistant Editor on this Rodale Internation publication.

I have no issue with Mr. Lord. He needs to support his family.

My major concern is that this content also is published on other site sites including MSNBC and MSN. This provides a false sense of credibility. DrV's comments really sums things up:

So, while I understand that Mr. Lord has as his job to report information that 'scares' people, I believe that he is remiss in not reporting why a person's Doctor may find important uses in these drugs or may even disagree with studies that are out there. If you've ever seen a patient die without a long term medicine to control their asthma, or you've seen someone whose life has been changed with the addition of a 'questionable' drug, then you will understand that blanket statements that a drug wouldn't be taken by your doctor may be dead wrong. Personally, I'd take this drug (or similar) if I had asthma, and I have family members on it as well. Please, Mr. Lord, do not make my job more difficult; patient compliance is hard enough already as it is.

Michael Schrage at ALA Friday 6/27 at 1:30p

If you are at ALA, make sure you attend the OCLC Symposium: The Mashed-Up Library at 1:30 on Friday 6/27 that includes a great keynote speaker and panel that will discuss developing new library services by mixing data and functionality from several sources.

The keynote speaker with Michael Schrage, author of Serious Play and Shared Minds—The New Technologies of Collaboration and columnist for CIO and MIT’s Technology Review.

The panel includes Susan Gibbons, Associate Dean, Public Services & Collection Development, University of Rochester (NY) River Campus Libraries David Lee King, Digital Branch & Services Manager, Topeka & Shawnee County (KS) Public Library, and Mary Beth Sancomb-Moran, Librarian, University of Minnesota, Rochester.

Any librarian that is concerned about how their organization can remain relevant in the time of technological change and how we can establish services where our customers are should attend.

Will the Next Generation of Library Systems be Customer Generated?

I have been lurking in on an OhioLink task force discussing "next generation" discovery layers. One of the latest postings to the group was by Peter Murray , who highlighted a report from the Next Generation Summit Search Interface Working Group of the Orbis/Cascade Alliance.

The report supports several concepts I have been pushing for a couple years now, including the idea of consortia to support library systems development. However, the more important concept is included in the report’s recommendations:

Regardless of who provides the Alliance’s next generation OPAC product, one of the deliverables that must be available as part of any solution is API or web services access to the catalog. Access at this level is important for two reasons:

... All major ILS vendors but III provide their customers a web services or HTTP REST API access to their systems, allowing for continued development around the catalog. Lacking such access, the Summit catalog will continue to be marginalized within the consortium’s academic campuses as tools and services are developed that take advantage of web service friendly applications.

... The Alliance should strive to create a resource that encourages users, libraries, and campuses to develop services around the Summit catalog. The library community has recognized that our patrons want social tools, which we tend to identify as tagging, commenting, etc. However, Web 2.0 applications like Flickr are popular because of the API access that they provide to their users as well. This access has enabled other web services, individuals, and organizations to develop different methods for exporting and utilizing the images placed within the Flickr photo archive. The Alliance should strive to make the Summit catalog open in this way, so that users and members alike are free to enhance Summit to meet individual, campus, or consortial needs.

Aha. Without using the geek terminology what they are describing is actually Service Oriented Architecture. However, what I am really excited to read is the desire on the part of the Alliance to break library culture and control over bibliographic information and to let the customers play with it. The number of applications that make use of the Google Maps shows how creative customers can be in seeing new connections between information sources.

I could see a customer building a new system in which leverages OPAC data in a weekend which could take a library organization a year to work through. Libraries should be building and licencing systems which exposes our content and data. Let the customers can play with it. Let them mash it up. Let them create systems that fit their immediate needs.

The challenge is that libraries do build systems and services with our (librarian) needs in mind. Our need for control. Our need for perfection. Our need for process. A library information system (or service) that uses a development process that does not meet our internal cultural needs is almost immediately classified as being a failure. We then focus way too much energy doing a post mortem on what went wrong in the development process in an effort to "do it right the next time."

It's no wonder that library systems of tomorrow are really just library systems of yesterday.

It seems to me that as a profession we are stuck in a bad relationship with our systems and vendors. We just can't figure out a way to get out of it. Are we happy that III will not give us APIs? Are we so insecure with our relationship with them that we are content to take what they give us? Do we feel we are that powerless?

The approach that the Alliance has outlined in their report is a extremely positive sign that some finally have had enough and are willing to make the hard decisions required for information system independence.

Photo: "REST eye for the SOA GUY" by psd. Creative Commons.