Skip Navigation
Forum Guide to Metadata
NFES 2009-805
July 2009

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.

Standard metadata components in many off-the-shelf products tend to be quite basic. The purchased systems generally must be customized if they are to meet the unique needs and circumstances of the organization and its existing data system; such customization may invalidate warranties and prevent upgrades from working properly.
  • 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.