Archive for the ‘Evergreen’ Category

Who Stole Monday?

Thursday, September 4th, 2008

This Monday-less holiday week snuck up and stole my blog post. I tried, really I tried, but honestly, I was wrapping my brain around so many other things that every time I started a blog post, it skittered out of my brain. Now it’s Thursday, which to me many weeks feels frighteningly close to Monday again.

The temptation would be to pick up the loose threads on a progress report on Evergreen Release 1.4, which I do have in work. The developers met in August and have good things to report. We’re on track for a release candidate in September (and next week I’ll also explain what a release candidate is).

But I’d rather do this update justice next week, following the suggestion from a library director that we offer snackable introductions to each part of a release, to explain more clearly what the Evergreen developers fixed and what they developed.

Around the (Evergreen) world in fourteen days

Friday, July 25th, 2008

Hawkinsville Georgia So I went to Boise and Madison (the latter with Jason) to talk about open source and Evergreen, but before that week (8 flights, only one late! Not bad), I had a work week where I visited Tifton, drove to Norcross and worked there, then drove back and visited Hawkinsville.

(The picture is Stephen Whigham, from the Ocmulgee Regional Library in Eastman. The library is light and gorgeous, a wonderful information cathedral, and they’re creating a YA section highlighted with a cushy booth I just love.)

I like to talk to other librarians about the “haps” in their libraries. Common themes come up, and some common themes don’t come up — which is always a good sign, actually. It’s like realizing you don’t have a headache.Tifton Georgia

I have some great pictures from Tifton, but my favorite is a “read” bookmark Victoria Horst made for me. The guys at Equinox asked, “What did you DO in Tifton for two hours?” Well, we took pictures, and laughed, and posed with books, and talked and talked about library software… I had to pull myself away, I was having too much fun! (We spent a fair amount of time talking about future hold features. They’re also really looking forward to SOLINET providing training — you cannot get enough training in public libraries.)
I plan to get up a Flickr set just for Evergreen-related pictures Real Soon Now. It hasn’t happened yet because I have a plan of attack that has a few steps in it I need to implement before I throw that switch.

Updates in Evergreen 1.4

Wednesday, July 16th, 2008

Over on the Evergreen project blog you can find a preview of what’s coming out in version 1.4.

I happen to be a particularly big fan of “pre-overdue notices” — the notices that tell me my books will soon be due. They don’t actually change my behavior; I read the notices, I think I am going to click on the link to renew the books, and then I forget to do it… then the overdue notice arrives, and I think, “Oh… right.” But I feel so much better about the library for sending them — and I know that a lot of people can and do respond to pre-overdues. They save libraries time and money, to start with, because every overdue brings its own overhead.

There’s lots more happening with 1.4, of course, but when it’s “your” feature, it makes it feel like they baked a cake Just For You.

Dogs, Kennels, Open Source, and Community Librarians

Monday, July 14th, 2008

Last month at the American Library Association annual conference I participated in LITA’s “Ultimate Debate,” and one of my contentions was that we in LibraryLand need to “shoot the dogma” — that is, as much as possible, our decision-making needs to be rational and evidence-based. (For those who find that a bit violent, I said at the very least we need to put the dogma in the kennel.)

This explains my job title: Community Librarian. When I took this job at Equinox Software I thought very carefully about what my title should be and how it would relate to this position. There are some “kewl job titles” out there, and more power to you if you have one. But after some head-scratching, I settled on “Community Librarian” because I am a librarian and I do serve a community (as do most librarians). The title felt correct but prosaic (perhaps — like me?).

After the Ultimate Debate, I felt warmer toward being a “Community Librarian.” Open source for me is not a fad, a mantra, or a personal religion: it’s a rational choice made very carefully after long years of suffering the slings and arrows of outrageous software — the kind of choice made by informed decisions, which is what librarians help people make. The open source model takes many things off the table — skulduggery, nondisclosure agreements, dubious back-room deals, exorbitant licensing fees based on false promises, and vendor abandonment, to list just a few issues — and replaces it with a startlingly rational model that leverages something we librarians do extremely well, which is share and collaborate. (More about that in future posts.)

Open source also attracts both a fair amount of woo-woo advocacy and an incredible amount of FUD (Fear, Uncertainty, and Doubt). But there are reasons open source makes sense, and part of my job is to help you understand these reasons logically, the way you understand arithmetic or gravity. In other words, I’m a librarian functioning in one of the core tasks of librarianship, which is to share information so that people can make decisions.

I don’t know how many times I have put a book in a patron’s hand or shared a website (or, bless my old bones, a gopher address) and later learned that this person made a decision they were happy with — from an ice cream recipe they particularly liked to a college they had never heard of and would now be attending. Deep down, I always want them to pick my choice, when I have one, and sometimes they do (with pleasure reading, I’m a far more vocal advocate, though that’s a bit different).

But more than that, the librarian in me wants to help people make an informed decision, and may we all take a moment to thank every librarian who has ever helped anyone do that.

I do believe in I am willing to believe in things unseen in other parts in my life — spiritual and political, for example. I take a lot of things on faith, and I also delegate many decisions. I buy my fruit and vegetables at the local farmer’s market because I believe that Farmer Herman and Miss Louise of Turkey Hill Farm practice farming by more sustainable methods than Big Agro. I haven’t been to their farm; I take their word for it. Then again, I’m also steeped in the literature of national food policy, so perhaps my decision is more rational it appears.

But there’s a difference between purchasing lettuce and selecting software that will impact the lives of hundreds of thousands or even millions of people — which is true of library software, because when it’s good, it helps connect users with books and other materials (which is the “duh factor” of library software; if it can’t do that, call that an automatic “FAIL”). For that, we can’t go on faith. We need facts, and we need to use these facts to make rational decisions.

I would rather you not choose my company’s services than make a decision based on dogma or bad information. I want you to understand how open source works, understand how Evergreen works, and then, if you’re convinced, embrace the right choice. Yes, deep down, I always want you to pick our services, but as a librarian — your Community Librarian — I want you to keep the dogma in the kennel and come by your decision with as much information as possible.

– Karen

Starting from scratch

Wednesday, July 9th, 2008

“Baby don’t you cry, gonna make a pie, gonna make a pie with a heart in the middle.” Jenna, in the movie, Waitress

Over at Hectic Pace, Andrew Pace writes about software development and “starting from scratch,” saying, “I think one must make a really, really good case for starting over… I fear starting from scratch because I think that if you rebuild things from the ground up, you wind up with something that looks exactly the same.”

He then goes on to quote me (Karen) on something I’ve said about reinventing very large organizations, which is that eventually you end up the same place you were before.

However, what is true for creating 100-year-old 65,000-member organizations is not true for software, or for that matter, apple pie. Let me start with the latter, which I know something a few things about.

As a pretty-good home baker, I know that part of the joy of baking pies is the satisfaction that comes from getting pie right: selecting good ingredients, knowing where your fruit came from, pampering the dough (this is no trivial issue; I was taught to cut the fat into the flour with two knives, and that’s how I do it), preheating the oven, guarding the pie’s edge so it doesn’t burn, and monitoring its baking. Even the cooling method makes a difference.

But before you even get that far, if you are any kind of pie baker, you ask, can I do this pie differently? Not just a tiny bit differently — a pinch more cinnamon, a little less sugar — but can I rethink it, so even when I bring a perfectly ordinary-looking pie to the table, what you actually experience is a wonderful new experience?

From ground-up re-architecting have come some of the great pies of the world. Someone had to learn that pecans would be particularly toothsome on a caramel filling. Someone else had to discover that berries, in a two-layer crust, become intensely flavorful. I have even invented my own pies on the spot, like a pear-apple-raisin-crumbtop pie I made while visiting my mother in New Mexico one Christmas in the mid-1980s (I remember it because it was that good), and a version of chocolate pecan pie that everyone except me likes.

In the same vein, in the last decade a lot of developers and idea people have come up with some great new ideas for library software. Regardless of Andrew’s fear of reinventing the wheel, many of these ideas have been something quite different. I remember seeing Libraryfind for the first time and thinking, “They finally got metasearch right.” Then I watched projects like Vufind and Blackight and SOPAC and Scriblio — projects that began with the idea that you begin with a cannister of flour and a stick of butter and begin dreaming.

Meanwhile, I kept my eyes on the Evergreen project for a couple of years and watched them build software that was really deliciously powerful and different — not the half-frozen, burnt PopTarts that for too long have been popping out of the same old toasters.

Time and again, I look at these library software projects, and what I see is what I know from baking (and quite frankly, writing): innovation begins from the willingness — and daring — to bake from scratch.

Not every idea has gained traction. Some fail due to bad timing, lack of community interest, or life changes. Many of these ideas weren’t even bad; but like my pear-apple-raisin-crumbtop pie, they needed timing and TLC to go mainstream. Plus to take an idea through the long haul from ideation through realization you have to be visionary, and stubborn, and earnestly sold on your idea. I can almost imagine believing in my pear-apple-raisin-crumbtop pie enough to stick with it (though I like to work with pastry dough — the tightwire of the baking world — I actually have more of a salt tooth than a sweet tooth), but that chocolate pecan pie would drive me crazy pretty quickly.

So what makes an idea survive? A really good idea for library software gains traction in part because it answers a question: can we do this completely better? Can we make a new pie?

Usually that question comes out of a growing frustration with our off-the-shelf, “turnkey” pies. We know good pie when we taste it, even when we’ve never encountered it before. But we’re told, no, that’s not our job; leave the pie-development and the pie-baking to the experts. So we dream of really great pie — pie that is different than anything else — but we end up gnawing on gluey, flat-flavored, cardboard-crust grocery-store pies (for which all too often we have paid boutique-bakery fees). We don’t know what’s in them; they taste terrible; many of them are really stale; sometimes we cut into them, after a long, long time waiting to be served, only to find nothing at all.

“But this isn’t even pie,” we complain.

“No, no!” we’re told. “This is GREAT pie. You LOVE our pie. Besides, you don’t know anything about pie. Leave it to us,” say the experts (who oddly enough don’t work in bakeries). “Besides, you’ll just end up reinventing our pie anyway.”

But often we really do know something about pie, and not only that, we know that new ideas don’t come from being afraid of starting from scratch. New ideas come from standing in a kitchen, looking at a pie pan and asking yourself, “If I could make a really great pie, what would it be like? Can I forget everything else I know about pie, and start over with something quite different (even though because it fits in a 9″ pie pan it will appear a lot like pies of yore)?” Then these ideas survive because we don’t ever want to go back to PopTarts again. It’s our kitchen, and darn it, we’re not leaving.

We know you’re hungry. We know that in your head, in your dreaming mind, you can taste great pie — pie with “a heart in the middle.” Put on the apron, get out the flour, and join us.

Sometimes a great notion

Tuesday, July 8th, 2008

This morning I finished writing an article about open source, and for a call-out box on the side of the article began listing just the most significant library-originated open source projects from the last five years. It surprised me how long the list was. Then I saw a blog post from Ross Singer of Talis, who in writing about Jangle, observed,

Five years ago I sat in a conference room at Emory’s main library while Brad LaJeunesse and Jason Etheridge (this predated PINES hiring Mike Rylander and Bill Erickson) told us that they were ditching Unicorn and building their own system. I, like the others in the room, Selden Deemer, Martin Halbert, smiled and nodded and when they left I (Mr. Library Technology Polyanna) turned to the others and said that I liked their moxie, but it was never going to work.

What strikes me is how we have come full circle. In the earliest days of library automation, we designed our own systems. (I’m glad I had professors who when I went to library school back in the early 1990s shared their fond memories of those days. Go Illini!) Now, again, we are designing our own systems. With the debut of Evergreen, we came back to a place of innovation and stewardship we once commanded quite well.

Evergreen in Your Pocket

Monday, July 7th, 2008

Evergreen Slimpac I find myself doing everything on my Blackberry these days — not just email and texting (and, oh yeah, phone calls), but replying to friends on Facebook, looking up addresses on the Web, and yes, checking the library catalog. Evergreen has a special plain-text version that works well on a variety of mobile interfaces.

(Quietly checking the library catalog during an argument about “who wrote that book” is one of those sly librarian tricks we pull out of our hats!)

— Karen, Equinox Community Librarian

Generations

Monday, April 21st, 2008

ILSs have evolved over time. What started as as a way to manage the printing of catalog cards (1950s and 1960s) eventually morphed into a system for tracking inventory, and then finally into a full-lifecycle management system for general library operations. None of this is news, of course.

What is news is that Evergreen is the first and only ILS to go into production that does not suffer from decisions made 20, 30 or even 40 years ago. Too often I see quotes from respected luminaries in the library world suggesting that Evergreen is simply duplicating what has been done for the last 30 years of ILS design. That means two things, actually:

  1. We’ve done a very good job of creating an interface to the Evergreen ILS that feels like what librarians are used to using. This means a shorter training cycle for front-line staff, greater ROI and lower TCO.
  2. We may have done too good of a job creating an interface that makes librarians comfortable with traditional ILSs feel comfortable with Evergreen, and haven’t explained well enough just how the core Evergreen is designed and shown just how easy it is to expand services in ways no one has yet considered in terms of an ILS

Looking Back

What we now call the ILS, a product purchased from and maintained by vendors, first emerged in the late 1970s and early 1980s. This is, for all intents and purposes, where history begins.

Over the last thirty years we’ve seen, more or less, three architectural generations of ILS arise from the original proto-ILS. Each generation learns from the lessons of those that came before, as well as from the wider world of software engineering. At each stage there are specific changes in architecture which provide obvious differentiating features that are wholly new so far as the ILS is concerned, but there are also concepts and constructs carried over from previous generations. In addition, there are non-architectural design components that are typical of each stage of evolution, and while the basic architecture of systems at each evolutionary stage may not be directly relevant, there is an identifiable correlation between the overall architecture and these higher-level design decisions.

The Client-Server Age

In the beginning (the late 1970s to mid 1980s) there was the monolithic client-server system, and it was good. Mostly it was good because there was nothing else, and something was needed. These systems were designed to run on the computers of the day; that is, large (for their time) central computers with dumb terminals, or later, thin clients on PCs, for data entry and output. They were (and are, it’s amazing how some of these systems persist) consolidated 2-tier systems that contained all of the logic in a single program on the server.

The back-end storage systems, and in many cases the display engine, were integrated directly into the main program, and required that this one program run on one server. The only way to scale such a system is to purchase a larger server. It is far from impossible to outgrow the largest servers on the market, even today, unless an institution is willing to dedicate a very large portion of their budget to such a system.

Another design constraint of theses systems, though not related to their client-server architecture but still endemic to the age, is that they were never meant to run the operations of more than one organizational entity. There is little or no consideration for location independence. If a staff member has a permission, they have that permission everywhere within the system. In other words, there is no concept of location-specific privilege separation.

Case in point: PINES is the state-wide consortium in Georgia at which Evergreen was initially developed. Although functionality was lacking in their existing solution, an equally concerning problem was the performance of the server during normal business hours. The 48 processor E10K they were running on was straining under the load of a state-wide consortium, and regular maintenance jobs that would not be a problem for smaller scale installations were requiring a mid-day restart of an essential, core service, and a nightly restart of all services. To upgrade out of the red zone would have meant investment in a 2 million dollar E20k, or larger. The PINES budget for one year is around 1.5 million dollars. Putting aside the cost and scaling factors in running such a system, there was no way for PINES to separate privileges based on which library or library system a staff member worked in. Among other things, this meant that PINES could not implement centralized Acquisitions.

The Web Application Age

Then in the late 1990s, scurrying around the feet of the lumbering, antiquated 1- and 2-tier client-server dinosaurs, there evolved the 3-tier web application. These systems are characterized by a nod towards database independence, the use of non-library standards for core functionality, and interface rendering handled by a generic third-party application such as a web browser. Such systems can be made to scale horizontally — that is, the full spectrum of functional areas can be scaled up — by adding more web servers in a dumb cluster, but because all of the web servers must run all the business logic for the ILS, as well as generate web pages for display, this scaling is not linear — one sees less usable per-server capacity added with each new server in the cluster. A related scaling problem is that there is no opportunity for balancing base-line resource utilization against the specific needs of the installation — in a low-circulation, high-search environment the server still has to load and run all of the heavy circulation logic with each instance of the search logic, sapping memory and CPU resources that could be used elsewhere.

These systems also carried over the lack of location-aware privilege separation from the earlier generations. While adding new services to such systems is somewhat simpler than in a client-server architecture, they are still basically a monolithic code-base built to run the operations of a single organization. They are also targeted at smaller library systems lacking the need for some of the more sophisticated business processes of larger institutions. As such, scaling is not a primary concern — and rightly so, with their small-system focus — and is not addressed directly but comes as a side-effect of the architecture, to the level that such scaling exists.

The SOA/Distributed/Dis-integrated Age

In the mid-2000s we see the rise of REST and SOA. New software systems in most industries are being modeled on distributed and modular architectures that allow the dis-integration of services and interfaces. ILSs designed and developed in this time period have the specific characteristic of incorporating concepts of SOA and distributed computing from the ground up. Each functional unit of the ILS is implemented as a service with a well-defined API, and these services can be replaced or augmented over time without the fear of disrupting the rest of the code-base. New services snap in like Legos and are trivial to implement in comparison to new services in previous generations, and service APIs stay consistent across time and even development and implementation methodology. Because ILSs built this way have intentional separation between all service layers (UI, business logic, storage) they can present many different workflow-optimized interfaces to the user, or to other services, while leveraging existing code.

Because of the focus on service dis-integration, resources can be applied precisely where they are most needed, and horizontal scaling is linear in the worst case. Scaling in this architecture is managed through the addition of simple, replaceable commodity hardware, making it extremely cost effective for initial capital outlay and providing the possibility of “just in time” cluster expansion using hardware that delivers the most bang for the buck at the time of need.

Greener pastures

Evergreen is the first production ILS, and only we are aware of as of this writing, to be designed with Service Oriented Architecture (SOA), Representational State Transfer (REST) and “n-tier” architectural concepts specifically in mind. Evergreen achieves this by building services and applications on the OpenSRF (Open Service Request Framework, and pronounced “open surf”) platform. OpenSRF handles all of the details of implementing a stateful, decentralized service architecture and the Evergreen code supplies the business logic and UI framework that matters to libraries.

To provide a specific example of the ease of extension that Evergreen and OpenSRF provide, the online bill pay functionality coming in the next major release was designed and developed by someone that had only passing familiarity with the underlying of Evergreen, or with the OpenSRF framework on which it is built. It was created in about 4 hours, and adds integrated, ILS-wide support for credit card and PayPal payment processing.

Another mistake I hear repeated all too often is the fallacy that Evergreen requires uniform policy definition across participating institutions. This could not be further from the truth — Evergreen supports the most flexible and location aware circulation and hold policies of any ILS available, and can even be extended with ad hoc exceptions to any policy definition via simple rules. This is, of course, unrelated to the architecture of Evergreen, but as it is the only example of a system based on such an architecture, this feature is also endemic to this pattern.

But wait, there’s more!

Another natural consequence of the SOA/dis-integrated architecture of Evergreen, facilitated by OpenSRF, is that most if not all of its code can be re-purposed largely without modification. We at Equinox Software are currently beginning development on FulfILLment, a large-scale, cross-ILS borrowing platform to facilitate the functionality of large ILL consortia, such as state or region-wide networks. This system will leverage much of the organization-aware business logic that Evergreen already provides to support cross-institution circulation in a completely ILS agnostic fashion.

The Future

While neither I nor anyone else can predict what the Next Big Thing will be in terms of application architecture, we can draw some clues from the current state of the art. Bleeding edge application development in 2008 seems to be moving towards refining the SOA model. Efforts such as SOA 2.0 and Service Component Architecture (SCA) point toward a near-term future where SOA and dis-integrated services become mainstream, and service-on-demand and mashups are the norm. If these trends are any predictor, Evergreen and OpenSRF are in for a long ride, especially as more features and functionality are incorporated over time.

Note: Updated 2008-04-22T10:00:00-04 to add some term clarification.

The Path to FulfILLment™

Thursday, March 13th, 2008

FulfILLment OverviewOne of the smartest data guys I know, Equinox’s Bob Molyneux, is in New Jersey as I write this talking to the New Jersey VALE group about Evergreen and consortial ILS deployment, a topic that we at Equinox know a bit about — we manage a State-wide consortium in the US and a growing Province-wide system in Canada, and there are several other installations well under way.

Why are large consortia forming around and with Evergreen? To answer that question we must first define what a consortium is. There are different types of consortia, and each consortium of each type has its own subtle variations from the broad definition, but basically they can be broken down into three main groups

  • ILL consortia like GIL — These consortia build union listings for broad search. Some ILL consortia will attempt to smooth the way for interlibrary loan by mediating requests through a central system, though require that all participating libraries use the same ILS for seamless ILL and are notoriously difficult to configure and maintain.
  • Purchasing consortia like WALDO — These are generally meant to provide leverage when negotiating with vendors. Direct resource aggregation is not their primary concern. As such, these consortia do not directly leverage economies of scale for implementation, and they generally end up being as expensive as taking the ILL consortia route to resource sharing.
  • Consolidating consortia like PINES — These consortia work to realize the full benefits of interdependent cooperation through broad resource sharing initiatives, such as a single shared ILS implementation.

Evergreen directly addresses the needs and concerns of Consolidating consortia by providing a way to consolidate hardware, software, support and administrative services, while still allowing local control over policies and procedures. This works, and works well, and is inspiring the creation of other Consolidating consortia throughout the US and internationally.

(As an aside: yes, I know you’ve heard that Evergreen requires adopting uniform policies, but that’s simply not true — it never was and never will be. Every participating library in an Evergreen installation can implement their own local policies, though there are benefits, especially for patron experience and staff training, to adopting similar policies.)

But what do all of these types of consortia have in common, in terms of what they attempt to address?

Markets. It’s all about markets.

Things

First, there is the internal market of resource acquisition within a set of cooperating libraries. Resources are scarce and must be allocated in the most efficient and effective manner possible.

Because ILL consortia do not attempt to consolidate, but rather duplicate ILS installations, this market is not addressed in any direct way.

The issues here are partially addressed in the Purchasing consortium model, though only on the procurement end and not on the resource requirement end.

However, this is one of the core goals of Consolidating consortia, and one of the driving forces behind the initial development of Evergreen. The reduction in direct costs that come with an Evergreen powered consortium is undeniable and amazing. What were once repeated, per-system costs for licensing, hardware and support becomes a single shared investment which can be 90% smaller, a full order of magnitude, than the aggregate for existing individual systems. This economy of scale is unprecedented in library-run software, and presents wholly new opportunities for self-direction and resource distribution.

People

Next, we have the external market for patrons. Libraries, for better or worse, are traditionally silos. In practice, they build local collections, limited by available resources, based upon what they believe will most benefit their patrons. Every community is different, and so every collection is different. Patrons, however, are not concerned about local library politics or the intricacies of collection development. Patrons want to retrieve the items they need, and they want to do so as efficiently as possible. They vote with their feet, and will follow the path of least resistance to the items they desire.

ILL consortia attempt to address this issue by building a new system around and on top of existing standalone ILS installations. These union listings, though, are not authoritative and are generally not updated in real- or even near-real time.

Purchasing consortia do not address the issues of the patron market in any direct way, as their constituent libraries do not (within and for the purposes of the purchasing consortium) aggregate collections.

Consolidating consortia, on the other hand, address the issue by being the authoritative source for information. They can provide a seamless experience to the patron and drive circulation of the “long tail,” helping patrons discover resources they never knew were available. In PINES we have seen a trend whereby patrons from areas served by non-participating libraries will travel out of their way to a PINES library because PINES has a larger, broader collection — nine million items on 1.8 million titles — than any one participating library could hope to amass. Put another way, patrons will seek out the larger, less convenient collection in preference to the smaller local collection, period.

So we have shown that one way to positively position libraries in both of these markets is to consolidate services in a single large, scalable system. To date, Evergreen as implemented at PINES is the largest single-instance public library ILS deployment in production in the United States with 275 outlets in 49 distinct library systems. To the best of our knowledge it is also the largest single-instance public library ILS deployment in the world. Evergreen is also the first, and currently only, ILS built to deal with the complexity of such a consortium, and is proof positive that Consolidating consortia work and that patrons and staff reap the benefits of addressing the issues in both of these markets.

TIMTOWTDI

There Is More Than One Way To Do IT — the Perl motto

Consolidating consortia, even implemented with Evergreen, are not without costs and great effort, however. It takes strong leadership and great political will to build a large Consolidating consortium. It requires buy-in from all parties of interest, and a willingness to work together and compromise. Even with all this, timing and existing contracts can make building such a consortium nigh on impossible. So what’s to be done?

Enter: FulfILLment™

FulfILLment is a new Open Source product being designed and developed by Equinox Software to help address cost and patron issues from the point of view of an ILL consortium by applying the lessons learned building Evergreen for the Consolidating consortium model. At the same time, FulfILLment aims to provide enhanced services to both patrons and staff, lowering the barrier to entry for all users.

FulfILLment leverages the underlying architecture of Evergreen and many of its concepts and algorithms. Some of the greatest strengths of Evergreen — its hold and circulation policy flexibility, its open and extensible OpenSRF architecture, and its easy integration with external services — are at the heart of FulfILLment and can be applied directly to the problem of inter-system ILL.

FulfILLment does this by redefining the problem space. Conventional wisdom says that ILL is conceptually distinct from circulation. The problem of automated ILL has thus far been addressed mainly through the use of union catalogs. This eases the search and discovery portion of ILL, assuming that the union catalog is up to date, but many union-catalog based systems do not address automated mediation well, if at all. In fact, many systems are little more than cross-lending agreements on paper that require full staff mediation. The reasons for this are clear if you consider these points of traditional ILL:

  • Little or no a priori knowledge of item or patron status
  • Little or no surrounding context for the ILL request
  • Either: forced ILS uniformity to provide seamless ILL; or spotty interoperability of NCIP and related protocol implementations, or in the worst case, so-called “paper ILL”

All of which lead to complicated data gathering, retention, aggregation and reporting.

However this conceptual distinction between ILL and circulation is not necessarily correct, given the proper circumstances. Consider these counterpoints from the view point of a circulation system:

  • Complete global state knowledge
  • Complete context of hold requests
  • Implementation based on “best and most appropriate” protocols

FulfILLment brings the benefits of a circulation and hold system based on the core algorithms in Evergreen to the ILL problem space. By encouraging and facilitating the participating institutions to collect and enter all relevant information about ILL policy and system definition, FulfILLment can provide not only truly automated mediation of ILL request (holds) but also full ILL transaction (circulation) management and automated transit management.

If the infrastructure and algorithms of Evergreen are the heart of FulfILLment, the FulfILLment Next Generation Discovery Interface (NGID) is its public face. The FulfILLment NGDI is a hybrid physical/virtual union catalog which automatically loads and deduplicates bibliographic records from all participating institutions for central search. Records can be pulled in using standard protocols such as OAI-PMH, Z39.50 or SRU, or can be automatically pushed into the NGDI from the local systems by whatever means are available.

FulfILLment leverages the hold targeting and capture algorithms from Evergreen — arguably the most advanced in the world in terms of policy and process modeling — and uses them to find the best item to fulfill the request of the patron based on all available information.

FulfILLment’s hands and eyes consist of the Local Automation Integrator, or LAI. This system uses the best and most appropriate protocol for each participating institution’s ILS, be it NCIP, SIP2 or a custom connector, to query each local ILS that advertises items on the requested record in real-time in order to provide status information to the hold processing mechanism. Data concerning the requesting patron is also pulled in real-time, and can be automatically obfuscated or expunged if required as soon as all open ILL requests and transactions for that patron are completed.

Once an ILL request has been accepted by the lending library and the item captured for remote circulation, FulfILLment tracks the complete life-cycle of this transaction. Both ends of the ILL, the lending and borrowing libraries, know the current status of items on loan and can generate reports based on this information using the Evergreen Reporter, one of the most advanced and flexible reporting engines available for an ILS.

The road ahead

This true end-to-end management and automation of ILL, particularly in an ILS-agnostic fashion, is something that has not yet been achieved in the library world. The potential benefit to staff in terms of reduced workload when fulfilling ILL requests might be enough on its own to make FulfILLment worthwhile, and when the cost reduction benefits of Open Source software, the advanced Next Generation Discovery Interface and the capabilities of Evergreen are brought to bear on problem of ILL, the return on investment will be immense.

We at Equinox are truly excited about the possibilities that will open up for building and growing ILL consortia on a scale not yet seen. You can expect to hear more in the near future and we hope you will all join us on this path to FulfILLment.

–miker