Overview
Building a solid "Information Architecture" is important for a number of key reasons
- Users will know where they should go to physically "put” their content into the system, known as "Putability"
- Users will know where they should go to "Find" content that they are interested in, known as "Findability"
- New information can be formed by manipulating user data to give it new meaning and context
I like to describe this as "asking questions" of corporate data or enabling data stored in multiple locations and / or owned and managed by different content owners to be "aggregated" into new views and dashboards.
- A scalable technical platform can be built to host the anticipated volume of data generated by the organisation over a foreseeable future.
To facilitate these high level objectives Information Architecture design, in SharePoint, is often broken down into 3 major components:
- Physical Architecture
This relates to the "Where" should content be stored and looks into the SharePoint Farm, Web Application, Site Collection and Subwebs elements.
Where content is stored can also be directly influenced by the capabilities of the underlying platform governance, such as SQL Content Database capabilities and best practices. For example, if a SharePoint "Application" is expected to contain a Terabyte of content then it would not be practical to store all this in a single Site Collection as the underlying Content Databases would be too large to effectively backup and restore in a recovery scenario. In this case a Physical Information Architecture should be planned to span the content over multiple Site Collections and Content Databases. A Logical Architecture (for both navigating and tagging) can be applied to seamlessly connect the different elements of these physical boundaries and limits.
A Physical Architecture should be designed around a scalable content storage structure and not a strict hierarchy that represents how users intend to navigate or are organised in the organisational hierarchy. Those hierarchies can be built in the logical architecture levels.
The danger with a highly structured organisational hierarchy, for a physical architecture, is that these hierarchies change, users don’t always see the world in this way (how many times does IT come under Finance?) or users require a mashup of these hierarchies. This is also not scalable if one section of the hierarchy (let’s say Marketing) starts to build up a LARGE amount of content that means the entire hierarchy no longer fits within the storage capabilities of the system.
- Logical Architecture (for navigation)
This area of Information Architecture relates to how users are able to navigate around a physical architecture.
The aim of this layer is to make a platform with multiple "pieces" appear as a single, coherent and easy to navigate system. Often there can be different ways to navigate the same system, such as by "organisational structure" and also by "Service". Designing Logical Architectures for Navigation requires an understanding of the user bases and what information they would like to see.
- Logical Architecture (for content tagging)
This area of Information Architecture design relates more to "content" aggregation and filtration rather than site structures and navigation.
Managing Content is a complicated set of tasks and a number of different factors are involved, such as Content Ownership, Editor (and approval) Permissions, Information Lifecycle Management, etc. Oftentimes end users want to see content brought together from multiple locations and content owners and platform administrators need to simplify the ownership and permissions elements.
Tagging content with globally available and consistent terms is the best way to discover content from multiple locations and present them in a common view, or dashboard.
There are 3 key elements involved in building a logical architecture for content tagging; a Managed List of Terms, Enterprise Keywords and Content Types. Each of these elements serves a slightly different purpose and a combination of all three gives us a solid information architecture.
Managed List Of Terms (Managed Metadata)
At its most basic level, content needs to be "tagged" with Keywords and Metadata to give a piece of information "context".
If SharePoint Site Columns are used in list items to present the actual data (think of address fields in a contact list, those columns make up the data) but then they can also used to provide metadata (information about information) that can be used to filter and aggregate volumes of data items. Typical metadata values are "Categories" or "Statuses" and can be applied to both list items and document items.
Within SharePoint, the Site Collection provides a hard boundary for a lot of items, such as Site Columns and managing commonly used terms (such as departments, statuses, customers, etc) in an information architecture over multiple site collections used to be problematic. SharePoint 2010 brought us a piece of technology to allow this atomic set of sharing common and structured sets of keywords throughout our entire SharePoint Farms (and, indeed, across SharePoint Farms). That is called the Managed Metadata Service Application and, in particular, the Term Store.
The Term Store should provide the available terms and hierarchies of terms that are deemed "Structured" and "Enforced" in the organisation. This is an agreed corporate taxonomy that needs to be consistent across all content. A term in a term store can still maintain:
- Multiple labels (or synonyms) to represent different labels that are actually the same thing.
- Related labels in multiple languages
- Permissions to allow Term Store administrators to maintain the official list of terms
- The ability to "re-use" terms in new Term Sets allowing subsets of terms to be used in client applications, whilst retaining a connection to the master term.
Enterprise Keywords
Enterprise Keywords work in a similar way to Managed Metadata Terms, but are unstructured. This means that there is no pre-defined set of terms, but users, in a crowd-sourced or social manner, tag their content with terms that are most meaningful to them as individuals.
As they write terms in the field SharePoint suggests terms that other users have already used and the expectation is that the crowd defines the information architecture and important terms and socially interesting content "bubbles" to the top.
Social tagging is good for unstructured content and agile / fluid business who are too constrained by highly structured Managed Metadata.
It is often useful to mix structured and unstructured tagging to give users the most flexibility. In many scenarios it is more "user-friendly" to provide a limited set of structured metadata fields that user must complete then allowing them to complement that with any unstructured keywords that they feel is appropriate.
Content Types
Content Types operate at a level above Managed Metadata and Enterprise Keywords and provide a far more structured schema of content in the organisation.
Content Types outline the "Context" of a piece of information such as defining it to be a "Contact", or an "Announcement", or a "Monthly Report", or a "Company Policy", etc.
When defining a Content Type we specify the metadata tags that must be present when creating an item of that type and any associated workflows and policies (note workflows and policies are not allowed when Content Types are published via a content type hub)
Content Types are useful when known objects are to be created in multiple locations (such as sites, site collections, web applications, etc) but aggregated together to be shown in a common view or dashboard.
Managed Metadata Properties
Managed Metadata Properties are used in SharePoint search to link together similar SharePoint "Fields" that may have different names (known as Crawled Properties in SharePoint Search) into common Managed Properties that can be used for property-based searches.
For example, different content owners may use the following fields to tag their
- Department
- Owning Department
- Internal Department
- Associated Department
- Business Section
By combining these different fields into a common Managed Property called "Department" we can initiate a search where "Department = Marketing” and will receive results based on any of the linked Crawled Properties associated to the Managed Property.
Thanks