Peter,

Use an search engine and create an aggregated database/index of all the
> material from the organization, or use a federated search system to
> search the repositories/catalogs/databases/etc. in real time? Did you
> consider both? And why the choice you made?


I was not involved in the initial planning. I came in sort of halfway
through and had to make a lot of the initial planning decisions work.  (Even
while I disagreed with some of those decisions.)  Again, my perspective
relates mostly to use of catalog data.   However, I would add that we did in
fact have a federated search tool when I came but quickly discarded it
because it couldn't do the more limited functionality we were hoping for it
to accomplish (present best options to users for where to search among our
databases and collections according to subject), let alone aggregate or
search across disparate data repositories.

Personally I find it very difficult to believe that a federated search such
as what you provide at MuseGlobal can do this sort of enterprise combination
of data well.  The data is not well structured (except for catalog data) and
includes an extreme range of completeness and little commonality.  What is
interesting to note, however, is that on the one hand, a vendor such as
yourself may claim that you can do this sort of stuff well (I'm not saying
you said that, just that you might say that). On the other hand I find it
interesting to note that the enterprise search tool vendor we have, coming
from a completely different market and perspective, would readily claim they
can do "all that library stuff" -- that they do in fact offer true federated
search. Which in my personal opinion isn't true at all.

But ideally I would answer your question in this way. I think there should
be a combination of the two approaches, that this would be more practical
and workable than just one or the other.  How's that for sitting on the
fence :-)


> Build vs. Buy? It obviously has taken Steve and his colleagues a lot of
> hard work to produce a nice looking system (except for all those big
> black bits on the screen!) and it obviously takes maintenance (it is
> 'fragile') Do you think it was/is worth it and if so why?


My answer is, it is too soon to tell.  There are many reasons why our
implementation is probably unique (and I don't mean to imply that it is
better than someone else's, just that I doubt it could readily be replicated
elsewhere).  We have a number of very different requirements and use cases
than what some other library settings might have.  We have a large number of
constraints on the IT side.  We have had to do a lot of custom stuff as a
result. This is probably why it is fragile, more than because of
deficiencies in any one piece such as the search tool itself.

But we are still, in my view, only at the very early stages of assessing the
whole package's value for our users.  And we have very particular, demanding
users.

In sum, we have had to buy AND build and so it isn't, again, a question of
one versus the other.

Steve