|
Purchasing and using a database can be one of the most difficult yet rewarding experiences for any library. One reason is
that databases usually handle a substantial portion of what the library considers its mission-critical information. If the
database doesn't work, or breaks down, it could become a crisis. In my capacity as the CEO of a database software company,
I have learned a great deal about what my customers go through on their way to choosing a database. I hope you can benefit
from my experiences.
Relational databases can be thought of as powerful versions of a regular database, like Excel. Whereas Excel is very good
at keeping track of simple one-to-one relationships between different pieces of data - for example, "What is John's social
security number?" - it is not capable of keeping track of one-to-many, or many-to-many relationships. These kinds of data
relationships are much more complex, but much more useful. A relational database can answer a question like, "How many people
in the county have checked out books on tax preparation that are due in the next week and how many of those people also signed
up for the free Turbo Tax demonstration you are going to be giving tomorrow?" Try getting Excel to answer that question.
Dealing with the past
When people first approach me, it's often with a grudging recognition that they "have to do something" about the state of
technology in their library. Typically, this person is a director, an IT professional, or a consultant hired for the purpose.
Whoever they are, they usually seem less than excited by the prospect of working through all the details involved in finding
a way to use databases productively and cost-effectively. Most of the people who approach us have already tried several different
kinds of technology to solve their data tracking needs. Some have built their own database (now unusable because the person
who built it has long since left), some are trying to use Excel (and can't track most of the items they would like to track)
and many are unhappily using paper and pens (letting a lot of their data needs fall through the cracks). Many people in the
library community have had unfortunate experiences with technology, and they are appropriately wary of companies promising
them "flawless transitions" and "affordable solutions."
Today there are several companies making relational database software that can be used by libraries. Many of these companies
offer their software as a service over the Internet and some offer their software in traditional form, loaded onto your computer.
In any case, all these companies are attempting to bring the power of relational databases to libraries. One of our customers
was attempting to use Microsoft's Access program but was having trouble getting it to issue the reports she needed. Relational
databases were able to solve her problem because once data is entered into a relational database, you never need to enter
it again and it can be sliced and diced any way you want.
It's the relationship, not the product
Usually, once library staff begins to understand the power of relational databases and the substantial cost saving inherent
in Web-based software, their attitude shifts considerably. Most of this shift, however, has as much to do with people beginning
to trust companies like mine as it does the product itself. The banking industry doesn't experience this trust hurdle. Banking
is a mature enough industry that no one questions its reliability. We give banks our money and trust them to keep it safe
and keep an accurate count of it - even though we have never met the people who do that. Because of the newness of some technology,
however, libraries often feel differently about their data. Using a third party to provide software means, in some cases,
that your data will be held somewhere else and your technical support will come from someone else. This transition can be
a difficult one to accept.
After reading about all the precautions that we take with our customers' data, another of our customers exclaimed that her
agency would have never thought of all those safeguards and even if they had, could never have afforded them. It is often
the case that libraries feel as though their data is safer and more secure when it's with them. In reality, however, library
data will almost always be safer and more secure with a company whose only job is to keep that data safe. We would never expect
software companies to do as good a job of providing services as libraries. Likewise, we should never expect libraries to do
as good a job protecting data as software companies.
In my experience, people want honesty about technology's total cost. This seems obvious, but total cost can be a difficult
thing to assess in this sector. Companies that sell client-server software (which you must maintain on your own servers) often
do not mention the cost of those servers or the wide-area network that you must establish to use their software. ASPs often
do not mention the cost of Internet connections when they tell you how much their software is. But in both cases, it is important
to remember that these costs are not optional. Having said that, there are external costs associated with every single technology
option. Building your own database also means having someone around to troubleshoot, customize, and support it, not to mention
having someone to conduct staff training and provide continuing software development.
Reality bites: implementation and training
There is one central unpleasant realization that agencies experience when implementing a large-scale database application
for mission-critical activities: There are a lot of politics involved in something that seems like it "should" be devoid of
politics. For example, information technology staff is often privately concerned about being "replaced" by a comprehensive
Web-based system. As a result, they may try to defend their importance. Fiscal or accounting staff often wants a kind of "firewall"
to exist between "library" data and fiscal data. As a result, they may try to remain apart from the process of using an library-wide
database. Lastly, because using a database often provides an opportunity for the library to improve its business processes,
the line staff may have difficulty adjusting to these improvements. For a time, the new system may seem less efficient than
the old one. Of course, if your time frame is short enough, every change is less efficient than no change. That doesn't mean
change should never be undertaken. Our work suggests that it is important to understand and realize the benefits of a new
system over the long term - 6 months or a year - not just tomorrow.
The light at the end of the tunnel: usage
So, is it worth it? With all the time and money and political machinations and business process changes and relationship building
and all the things that can and will go wrong, is it worth it? Absolutely. Relational databases have been used by the corporate
world for years, and with very good reason. No human being - or group of human beings - can keep track of all the millions
of pieces of data in a large library and all the ways that data relates to all the other data. There is simply no substitute
for an enterprise-level database. After your initial investment of time, money, and energy, relational databases will end
up saving you substantial time and money forever. This technology will enable you to issue reports at the touch of a button,
figure out how much vacation Sally has left, and how long it's been since John wrote a progress note for Jim Smith. In short,
the question is not should you start using a professional database at your library, but rather: When will you start using
a professional database at your library?
|
