MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Museum discussion list <[log in to unmask]>
Date:
Thu, 25 Jan 1996 15:46:22 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
To all involved in this discussion, and especially to Joe, as a "systems"
person who spent more than five years in a museum setting developing a
system, and has also worked in traditional business settings, i.e. large
insurance companies, accounting firms, etc., I'd like to say that while your
ideals and position have merit, reality prevails! The paramount thing is
always the data, and as long as you can get at it, export it, and also
implement proper vocabulary controls and oversight for data collection, then
at least the databases you develop make the effort worthwhile.

After my many years evaluating various collection management
softwares/companies, and trying to guide development of same with consulting
programmers and thorough analysis in-house, I have come to believe that
using a product developed "commercially' is probably the best approach, as
long as 1) the foundation for the product is an industry standard, i.e. SNAP
for Windows is based on Access, and 2) careful checking indicates the
company is stable, and has a good reputation for support and delivery of
product.

Why? Because software development is complicated, time-consuming and
expensive. The best products are usually produced by teams of people, and
most museums do not have the staff, time and expertise to support this type
of effort. It is true that the solution is not one guy with a laptop, but I
don't think it is in-house development either, unless some spectacular
person is able to rally a team of volunteer programmers from someplace like
the giant insurance company where I worked for a year and a half.

In addition, there is another important economic foundation for using one of
the good products being developed for the museum community -- the benefits
of economies of scale -- a company selling a large number of systems to many
museums can offer the consistency and quality of a team product and a better
price. It is a tragedy to see data trapped in a lousy expensive, outdated,
proprietary product from a vendor who has gone under, but it is equally sad
to think of all the dollars wasted on in-house development of systems
that are similarly flawed or non-functional.

In the large museums that have the time, staff and money to develop their
own systems I have seen some impressive work, but I believe we should not
delude ourselves about the true costs of software development versus the
ease and affordability of selecting a vendor product.

ATOM RSS1 RSS2