Where do they Come From?
The creation of shadow databases can
result from many factors.
Availability and Marketing of Central Systems
In medium to large institutions, non development staff may now always be
aware that there is a central system of alumni and donor records and what
the official policy on shadow databases are. Coupled with this,
advancement support staff may not always be the most knowledgeable about
marketing techniques and how to promote the value and virtues of the
central database throughout the campus.
Overall campus orientation practices may not include a discussion other
than in a very general sense of development and advancement let alone any
systems that support these activities.
Data Integrity Issues With Central Systems
One of the most common justifications for shadow databases is that "the
data we have in our department is more accurate than that which is
maintained in the central system."
You to be wary of this statement but also react to it. Make sure you are
meeting industry accepted standards regarding addressable rates and that
your data has integrity.
It can also mean that users may be
actually storing data in a way that you don't store it on the central
system such as they way they do their joint invitation names.
Systems that don't have adequate functionality for supporting all facets
of advancement operations also lead to the creation of shadow databases.
Many departments will create shadow databases to maintain
their donor recognition and naming information. Few advancement systems
currently have a naming module which can adequately manage the data
associated with naming such as the building, the rooms within a building,
the plaque on the wall in the room and the name on the plaques.
Those With the Gold Make the Rules
Development of shadow databases can often be initiated in departments and
schools that have more resources and the ability to focus resources on
their "specialized needs".
The ability to make these types of departments cease using their shadow
also be subject to a greater degree of political considerations and
A development system may also be difficult to use.
The writer of this article remembers very distinctly being at an
institution where the records staff stated that in order to receive your
password to the database you had to take a minimum of 2 days of training
after which you were required to take an exam, where it was likely you
would fail the first time.
While training is necessary, the above example clearly illustrates why
someone might be more interested in just setting up a shadow database to
keep a mailing label list for their department.
Report and Data Request Turnaround Times
What is your turnaround time for requests?
Users expectations are higher
and if they have to wait 2 to 3 weeks to get a set of mailing labels, it's
obvious why they might want to set up a shadow system so they can expedite
Data Needed for a Web Site
Tied in with system functionality, but a somewhat different issue.
Sub units of the organization may need data to put on their web site such
as membership lists.
These lists, which are typically not refreshed from the main database are
in fact shadow databases and may quickly get out of date. In addition,
since they are on a web site, the risk of public exposure and liability
due to incorrect data is greater.
Shadow database projects have a way of growing and soon, what was a simple
list will have evolved into an actual system with its own coding
structures, data integrity rules, reports maintenance practices and more.
Some departments may even insist that they should have their own
advancement system since they've so aptly demonstrated the they can manage