Chapter 4. Implementing a Metadata System - Build-Versus-Buy Analysis
Deciding whether to build or buy a metadata system can be a challenge. Starting
from scratch without being sure you have the human resources needed to handle
the job can be overwhelming, but commercial products bring their own limitations.
For example, most commercial packages are proprietary and cannot be modified
without invalidating warranties and, in some cases, preventing upgrades from working
properly. In addition, many commercial systems are designed with a very limited set
of metadata that cannot meet even the most basic information needs common to
education organizations. A "build or buy" choice has other ramifications as well, often
including dictating whether metadata system architecture reflects centralized, federated,
or distributed architecture (see below). Answers to the following questions can help
planners decide whether to build or buy a metadata system.
- Have other organizations with comparable needs and budgets found acceptable
commercial solutions? If so, perhaps those technology solutions might work for
your organization as well. If not, an off-the-shelf product may not work for
your organization either.
- Do commercially available products meet all of your organization's needs or will they
need to be modified? If a product meets most, but not all, of your requirements,
you may wish to determine whether it is possible to modify it, or reconsider
the importance of any unmet needs. Adding to, or changing, a proprietary
product's existing functionality is sometimes feasible; but modifications
to improve processing speed or other aspects of performance, or to enable
it to run on different platforms, are usually not. In addition to potentially
invalidating warranties, customization of commercial products often causes the
modified tools to become incompatible with future releases or updates from
the developer. Before proceeding, confirm that support will still be provided
even after you have modified the product.
- Will commercially available products accommodate change over time? Policies,
business rules, and metadata characteristics are not constant. Priorities and
procedures occasionally change, and a metadata system must be able to
accommodate these changes when they occur.
- Do you have access to staff or consulting resources with the necessary expertise to build
your system? If so, is the allocation of staff time or the cost to hire outside
expertise within the range of the resources you have for the project? If you
must hire outside expertise, have you determined how your staff would
support a system they did not develop?
- Do you have resources to support the system in an ongoing way? Have you planned
for ongoing costs such as new staff member training, system upgrades, and
ongoing licensing? Whether building or buying, initial development costs, as
substantial as they might appear, are not the only resources needed to maintain
a system over time.