How to Create a Metadata Framework

Many of our clients are busy planning their move to the cloud by migrating their employees and enterprise content to Office 365. But often, executive pressure on the IT organization to move quickly leads to moving content to Office 365 without time to create a proper information architecture, perform a content analysis, or implement a proper migration plan.

And don’t forget the metadata framework — it’s critical to getting the maximum benefits from your Office 365 investment. A metadata framework is simply a small collection of three types of metadata that are used together to make managing and finding content more efficient. It’s an essential step that’s often overlooked. If your migrated content isn’t tagged appropriately and accurately, users will have a hard time finding it, if they can find it at all.

Benefits of a Metadata Framework

Improved findability.

Search results are dramatically improved by using search filters and facets. Content can also be delivered dynamically, based on the user.

Improved user experience.

For most departments, users will assign a single tag and all metadata will be automatically applied.

Improved manageability.

Records and security will be improved because every document will have the correct metadata to enforce compliance.

Building Blocks of a Metadata Framework

The process of building a metadata framework remains the same regardless of industry or size. It’s important to approach metadata modularly and to avoid overcomplicating the process. Simplicity and flexibility are essential.

Simply put, your framework should include a set of global metadata (applicable to all information across the enterprise), supplemented by a set of local metadata (applicable to departments, functions, or processes). The third component is document type — which is itself a type of metadata — but I like to think of document types as separate from global and local metadata. Document types have a specific function in the framework and, as we’ll discuss shortly, they are a separate part of the information gathering process when developing your metadata framework.

Together, this power trio enables dramatic improvements in management and delivery of content in your organization. More importantly, the end user experience is simplified: Finding information is faster, more reliable, and with greater confidence that the correct document (and version) and has been retrieved. Hasn’t this always been the dream of effective content management? Furthermore, the global and local metadata (including document types) that are collected as part of your framework can be used to create simplified navigation, sorting, and those cool checkbox filters that are so commonplace in our online shopping experience today.

Specific to each business area, local tags help users find the documents they need by enabling advanced navigation and search capabilities.

Document types

Document types are business-friendly names used to describe the documents created, stored, and used during business processes. They can also be used to allow multiple, related metadata values to be automatically applied when a user uploads a document.

Steps to Create a Metadata Framework

Most of the information you need for a metadata framework will come directly from talking with business users. They know their own processes, content, and organizational principles. If your stakeholders are currently storing information in network shared drives, they’ll likely have great ideas about how they’d like to “improve the current, complicated folder structure,” which is your cue to introduce them to a better way — folderless content management. Here are the first steps:

1. Define Standard Global Metadata Fields

Global metadata are data that are assigned to all content, regardless of who generates it, where it is stored, or what location, division, or country it is associated with. Expect to define 8 to 10 global fields. The good news is that these values rarely differ from company to company, so you may be able to use the list of examples below as your starting point. Generally, IT, RIM, and Legal have the final say about these terms, but as an IT leader or manager, it will be your job to assess if the metadata fields can be used in production systems.

Examples of Global Metadata

Subject Matter

Record Series Code

Security Classification

Regulatory Area

Department Name

Location Description

Company (if your organization has more than one operating company)

Document Type (more about this metadata field, below)

In the global metadata set, we also include 8 to 10 system-generated metadata values, such as Date Created, File Format, and other values that are not user-selectable. Therefore, you don’t need to manually assign values for these metadata fields — they’ll be provided by the content management solution you’re using. You can see examples of system-generated metadata in the Global Metadata Example list, here:

2. Define Standard Local Metadata Fields

Meet with representatives from each department and conduct short, one-hour interactive sessions. Attendees should be selected based on high-level knowledge of their group’s processes and familiarity with the work that their group or team produces. The sessions are meant to be an exchange of knowledge; you’re helping them find better ways to work, starting with the organization of their content (usually on shared network drives).

Questions to ask during these sessions include:

What are their most important business processes that require the use of documents?

For each major document-centric process they describe, what are their most important document types?

How is their information organized (e.g., by year, by subject, by process, by person)? This is essential. It’s local metadata that you can later use for creating sortable columns and search result “refiners.”

What key fields or terms would help them the most in searching for documents (e.g., searching by document type, year, subject, last-modified date, entity)? This is another way to ask the previous question. The answers you receive to these two questions will often be similar and can reveal the “best” terms.

Where is their information currently stored (e.g., on shared drives, on my hard drive, in email)? This is not required for the framework but is helpful if you have specific, near-term migration plans for the group.

Examples of Document Types

Audit Report

Purchase Order

Regulatory Filing

Project Plan

Meeting Minutes

Asset Tag

Examples of Local Metadata

Project Type

Project Level

Project Name

Work Order Number

Project ID

Equipment Type

Vendor

3. Compile your findings into a spreadsheet

The spreadsheet will be used to gain buy-in and approval from stakeholders, and ultimately used for setting up your content repositories with metadata during migration. Your results should look something like this example of local metadata, created after two one-hour sessions with a public utility company’s Environmental Health and Services Department:

How the Framework Components Connect and Relate to Each Other

By now you may be wondering how these three metadata components work together. Remember, global metadata is assigned to every document in the repository (and ideally in all repositories in all places in the company). These are fields that are useful for everyone in the organization. They enable users to search and sort any group of documents by high-level attributes like author or company division. Fields like Record Series Code allow your Records Management team to retain and dispose of content as required by law. Your IT or Security groups use global fields like Information Security Classification to manage sensitive content.

At the business unit or department level, the metadata is specific to the local community of workers — hence local metadata. Local metadata allows them to share common organizing principles through agreed-upon metadata fields and values. These are in turn applied as column headers (in SharePoint, for example) or as search result refiners. Lastly, the Document Type field is not the format of the file; rather, it is the way that the local users describe their work product.

Conclusion

Your metadata framework will evolve over time. While global metadata is the least likely to change, expect local metadata to need adjustment periodically as your business evolves. In forthcoming articles, we’ll present options for reviewing, refining, and implementing your metadata framework. Concerned about how all of this useful metadata will get assigned to the content in your repositories, without asking users to manually apply it? We’ll cover that, too.