Which is why the interface specifications are at least as important,
if not more important, as the specs for each of the modules that you
enumerated. If the interfaces are well-defined, then the components
can be designed and developed with a minimum of further interactions
among developers. In fact, there might eventually be more than one
implementation of a particular module, allowing a library to assemble
an ILS out of interchangeable components. (I'm assuming open
source--it seems unlikely that proprietary vendors will ever come
around.)
Sharon M. Foster, 91.7% Librarian
Speaker-to-Computers
http://www.vsa-software.com/mlsportfolio/
On Tue, Apr 7, 2009 at 2:52 PM, Genny Engel <[log in to unmask]> wrote:
> Also back to the original question, what is an ILS in the first place?
[...]
> Without the ability to support all the back-end processing and accounting, simply replacing the front-end OPAC and the bibliographic database does nothing to eliminate the need for an ILS, unless it also opens the way to feed data in and out of cheap off-the-shelf accounting and purchasing systems that aren't library-specific. A lot of libraries still won't want to put together even that much out of parts, and will prefer an ILS, but if it were me, I think I'd look at reengineering some of the parts to become more interchangeable with stuff like standard accounting software.
>
> I must admit I was kind of horrified when I first got here and found that all this functionality was resident in a single system. No wonder these things are so honking expensive.
>
>
>
>
> Genny Engel
> Sonoma County Library
> [log in to unmask]
> 707 545-0831 x581
> www.sonomalibrary.org
>
|
