I find Microsoft’s advice regarding how to properly assemble a taxonomy somewhat nonsensical, but it’s because I love the Records and Information Management standard ISO 15489 so much. As you write your SharePoint 2010 Records Governance Plan, I recommend you consider the following.

Remember: to write a Records governance policy for SharePoint 2010, you need to read ISO 15489’s General Guidelines and the Technical Report. Get your copy of the general guidelines here. A link to the Technical Report is provided on that page.

Garbage In, Garbage Out

Microsoft reminds implementations teams that “putability” (the act of putting quality data accompanied by excellent metadata into information architecture) and “findability” (the quality of being easily retrieved) are linked to information architecture scalability and training. For Records colleagues, taxonomies mean classification -- because ISO 15489 tells them so. From the General Report:

Classification of business activities acts as a powerful tool to assist the conduct of business and in many of the processes involved in the management of records, including:

  1. Providing linkages between individual records which accumulate to provide a continuous record of activity,
  2. Ensuring records are named in a consistent manner over time,
  3. Assisting in the retrieval of all records relating to a particular function or activity,
  4. Determining security protection and access appropriate for sets of records,
  5. Allocating user permissions for access to, or action on, particular groups of records,
  6. Distributing responsibility for management of particular sets of records,
  7. Distributing records for action, and
  8. Determining appropriate retention periods and disposition actions for records.

Folder linkages. Standard naming conventions. Fast retrieval. Access controls. Auditing and compliance. Distribution. Retention. If you’ve read your SharePoint 2010 source material, these words should sound familiar. You heard them in ISO 15489 first.


Beware (and this is strange): while Microsoft makes taxonomies in SharePoint 2010 complicated, it doesn’t seem to like folksonomies. “A taxonomy refers to a hierarchy or organization of objects that will likely include synonyms, equivalencies, parent/child relationships, and metadata. In contrast, a folksonomy can be thought of as a ‘free-form’ method of describing data without a hierarchy or an organization of terms from which to draw metadata values.” The description reeks of disapproval; however, in most organizations information architecture is honed by well-intentioned administrative professionals and analysts in real-time. While the implementation team is abroad discussing the importance of folder structures with this level of the organization, prepare to map. The architecture of SharePoint 2010 requires purposeful file planning.

But Are They Different?

Microsoft will tell you that there’s no clear definition of what information architecture is, but it asserts that business taxonomies are “buckets” that relate to organizational functions and policies, while content taxonomies (aka “operational taxonomies”) map to the business needs, user needs, technology support and relationships amongst the various types of content.

ISO 15489 is more elegant; of course the standard doesn’t make this distinction (why would it?), but it does advise you on the building process:

Classification is the process of identifying the category or categories of business activity and the records they generate and of grouping them, if applicable, into files to facilitate description, control, links and determination of disposition and access status. Using business-activity-based classification systems, the process consists of the following steps:

  1. Identify the transaction or business activity that the record documents;
  2. Locate the transaction or activity in the organization’s classification system;
  3. Examine the higher-level classes to which the transaction or activity is linked, to ensure that the identification of the classification is appropriate;
  4. Check the activity classification against the organization’s structure, to ensure that it is appropriate to the business unit to which the record belongs;
  5. Allocate the identified classification to the record to the levels appropriate to the organization’s requirements.

Moreover, Microsoft will advise you to restrict the number of levels within a business taxonomy to seven or under. ISO 15489 counterpoints:

The number of levels of classification and entry point of the classification process (whether at transaction level or above) depends on the following factors:

  1. The accountabilities of the organization;
  2. The nature of the business;
  3. The size of the organization;
  4. The complexity of the structure of the organization;
  5. The risk assessment of criticality for speed and accuracy in control and retrieval of records;
  6. The technology deployed.

In other words, your taxonomy can be as simple or as intricate as your industry requires it to be. See the benefit of using ISO 15489? If you need policy perspective to support your architecture perspective, it’s clearly stated for your borrowing pleasure for your socialization of the SharePoint 2010 project.

Consider This

Five years ago, when MOSS 2007 Administrator Companions appeared on the shelves, there were maybe ten pages devoted to Records Center inside any given textbook. The first page of the Records chapter dealt minimally (at best!) with RIM theory and it was an uncomfortable read. Taxonomies and classifications weren’t mentioned. Thankfully the John Hollidays and Don Leuders of the world stepped forward. I argue that the relationship between taxonomies and SharePoint 2010 feels similar -- architecturally feasible but not fully baked in the administrator textbooks.

Incidentally, two years ago, industry experts predicted business units would implement rogue information management systems because: 1. the IT department didn’t have enough resources to implement applications at the rate of speed and efficiency to suit every department head across the organization, and 2. it’s incredibly difficult to create organization-wide taxonomies that all business units can adopt. I can’t help but ask myself: is the scalability -- the marketed document management capabilities -- of SharePoint the subconscious reason why the platform was adopted by customers so quickly?

From the frying pan (shared network drives) into the fire (MOSS 2007, now SharePoint 2010), I suppose. I encourage you to consider how taxonomies influence the success or failure of your SharePoint 2010 electronic records management implementation. Plan accordingly and defer to the Records group.

Editor's Note: You may also be interested in reading: