Category: Taxonomy

Many SharePoint implementations are unsuccessful. They do not deliver business benefit, are too expensive to build, too expensive to manage and are difficult to use by the stakeholders they are seeking to help.

SharePoint is a large, pervasive and complex system and as such is subject to the usual reasons for failure of all similar sized systems; but SharePoint in particular frequently fails because it has no information architecture underpinning the content, users and context of the organisation’s information environment. In most cases this lack of an information architecture is due to the implementation being IT driven. SharePoint in all but the most trivial of implementations is not an out‐of‐the‐box system – despite what many people believe and the Microsoft marketing machine suggests.

An Information Architecture within SharePoint is crucial because there are many design and configuration decisions that need to be taken before the implementation starts. In addition, many of the fundamental information structures within SharePoint are not easily changed once the implementation starts.

Information Architecture Phases

The information architecture activities for implementing SharePoint can be broken down into four phases:

1. Analysis: Discovery of content and structures that already exist within the organisation
2. Design: Creating the information architecture itself (see below)
3. Configuration: Implementing the information architecture as determined by the design
4. Testing: Validating the information architecture and reworking in light of user feedback

Key Aspects to Consider

The design of a SharePoint information architecture must consider a number of aspects of SharePoint functionality.

• Site Plan: Information to be stored and accessed within SharePoint must adhere to some overall structure. Whilst SharePoint does not implement a classical “fileplan”, one must be created never the less.
• Interface Structure (Usability): Once the site plan has been created this must be mapped to appropriate SharePoint interface structures.
• Content Types: Content Types are one of foundations on which much of SharePoint’s functionality builds. Therefore, getting the Content Types correct is of prime importance to any SharePoint development.
• Metadata: The metadata schemas to be used within SharePoint must be defined. This metadata is primarily related to the Content Types, but also in other key SharePoint structures.
• Taxonomies: Any controlled vocabularies required to populate metadata fields or define navigation structures must be defined.
• Search: Defining the parameters of the search and attendant user experience.
• Permissions Model: A SharePoint implementation must define the permission model that applies to it – namely who can do what to any given item of content.
• Workflow and Versioning: Any organizational document workflows that are needed must be defined.
• Policies and Governance: Whilst SharePoint allows significant codification of the information architecture and its usage, there will always be a need for policies and governance guidelines.

SharePoint lends itself well to having its configuration performed by information architects rather than software developers. The reasons for this are two‐fold: the detailed and comprehensive set of configuration options that are exposed via the administration user interface; and the pervasiveness of these options throughout the many SharePoint information structures.

Download this article.