C H A P T E R  3

Leveraging Content Types

“A better place to put our content” is the most common and fundamental reason that organizations give when implementing SharePoint. For all of SharePoint's rich capabilities, a SharePoint solution is of very little value without good content. An event in a calendar, a policy document in a library, a news article in a pages library—these are all first and foremost content, and they are each defined and managed within SharePoint using content types. This chapter explores the importance of content types and the role of managed metadata to ensure that SharePoint can become that “better place”—not just a glorified file system and content dumping ground.

The Importance of Content Types and Metadata

Both the greatest strength and greatest weakness of modern information management systems is the ease at which users can create information—vast amounts of information. There is no question we are well into the Information Age with the Internet providing the distributed backbone. But the Internet is so often just an information black hole—information goes in and is never seen again.

Like the Internet, SharePoint can become an information black hole within an organization, much in the same way that file systems and filing rooms were in the past. The key difference with SharePoint is the wide range of information and formats that it can accommodate—wiki pages, contact lists, Key Performance Indicator (KPI) data, video files, and stock standard documents, to name a few. Nearly everything an information worker does within an organization can be easily created or put into SharePoint; this is both the solution and the problem.

For SharePoint to be “a better place to put our content” it needs to be designed, implemented, and managed to be that better place. This all starts with an understanding of the roles played by content types and metadata.

A content type is an item template for a specific style of information asset, such as an event or a policy document. Like site columns within SharePoint, content types are defined independent of any specific lists and libraries and can therefore be used across many lists and libraries. This allows you to manage information assets by what they are rather than just where they are—a change from the traditional system of physical filing cabinets and rooms.

To function as an item template, a content type defines a collection of metadata, properties, rules, and behaviors that are enforced for items of that type regardless of the list or library in which they are stored. This collection can include the following:

• Workflows, such as approval or feedback
• Information management policies, such as expiry or auditing
• Columns and metadata, such as Author or Topic
• Document templates, such as a word.dot file
• Document Information Panel settings

Out of the Box Content Types

Within SharePoint 2010, many out of the box (OOB) content types are implemented to support standard types of information and to allow some of SharePoint's rich functionality. For example, a Post content type defines the properties needed to be a blog post.

For those not yet familiar with content types, Table 3-1 will at first read like a list of the standard lists and libraries; this is because each list and library under the hood has a content type to support its type of information and functionality.

When a site is provisioned using the standard Team Site template, a document library called Shared Documents and an announcements list called Announcements are created and each has an underlying content type. Shared Documents has a content type of document and Announcements has a content type of announcement.

Showing the Content Types of a List or Library

By default, content types are not shown in the settings page of a list or library, but it is easy to make them visible so you can understand what content type or types are being used by each list or library. You can do this for any list or library but here we will refer to the Shared Documents library in a standard Team Site (it's assumed you have full control permissions for the site).

1. Navigate to the Shared Documents library.
2. From the Library tab in the ribbon, select Library settings.
3. Select Advanced settings.
4. The first option is to allow the management of content types; set this to Yes.
5. Select the OK button at the bottom of the advanced settings page and you will be returned to the main Library.
6. On the Settings page you should now see a new section called content types, as shown in Figure 3-1.

Figure 3-1. The content types section on SharePoint library settings page

You can now do this for any list or library to see what content types are being used; I recommend you find a calendar and a discussion board to explore what content types they use by default.

Each site has a content types gallery that is used to manage the collection of content types that are available for use within that site (see Figure 3-2). The gallery actually displays all content types from all sites above it within a site collection hierarchy; this is why each content type has a source property indicating which site it is managed in. This means that most content types are actually managed within the root site of a site collection and only custom configured or deployed content types will be managed within a local site.

Figure 3-2. Standard SharePoint site content types

Viewing Content Types in the Site Content Types Gallery

To view the site content types within any given site, follow these steps:

7. Navigate to the site you want to view.

8. From the site actions menu, select Site Settings.

9. From the Galleries group, select Site content types.

10. Use the drop-down box on the right to view a specific group of content types.

What vs. where

My favorite analogy to illustrate this concept is the rules around renovating a house in New Zealand, as this was a project I was tackling when I started trying to explain the value of content types to my customers.

New Zealand has laws that specify how a house must be built and these are defined in the National Building Code. Regardless of where you build a house in New Zealand, you must comply with this code because of what is being constructed. Then, depending on where the house is built, further local bylaws apply that cover specific location variations such as very high winds or very cold temperatures relating to where the house is being constructed (see Figure 3-3).

Figure 3-3. What vs. where for a house in New Zealand

Content types are like the SharePoint Building Code specifying the rules to which content must comply. Lists and libraries are like the SharePoint local bylaws that specify further rules that content must comply with when stored in a specific List or Library because of where it is.

The first two versions of SharePoint contained no content types within the architecture of the SharePoint platform, so a solution could only drive rules based on where an item was located.

For example, if you wanted to manage different behaviors for Books and Reports, you needed to create a specific list or library for each. But with the addition of content types in SharePoint 2007 and in SharePoint 2010, you have the flexibility to have a single list or library that contains both Books and Reports by leveraging a content type for each document type that can apply specific rules to each content type even though they are in the same location.

By leveraging content types to consolidate different types of information into a single location, while still preserving specific properties and behaviors for each type, you can provide a much simpler OOB user experience for both content contributors and content consumers (see Figure 3-4).

Figure 3-4. Combining two types of information into a single library using content types.

In this Books and Reports example, you can easily provide a list or library view to your users of just Books or just Reports, and you can easily provide a consolidated view of Books and Reports. For content authors, you can easily apply a specific approval workflow to just Reports, a different approval workflow to just Books, and then apply an expiry policy to all documents in the Library.

In the next example, each office has a library and can apply rules and behaviors for all content relating to that office. At the same time, content types can be leveraged to apply rules and behaviors for specific types of information regardless of what office library they are located in. Content types can also be easily levearged for the legal team to see all contracts by creating views in the document libraries that provide an aggregated view using a Content Query Web Part or by using an advanced search filtered by Contracts content type (see Figure 3-5).

Figure 3-5. Example library and content type relationship for three offices

Inheritance

There are many places within SharePoint where inheritance is an important pattern, such as for the management of user permissions, applying site themes, or controlling available site templates. Inheritance is also a critical concept for the creation and management of content types; all content types inherit from a parent content type, other than the underlying content type called System (see Figure 3-6).

This content type inheritance pattern can be used to an organization's advantage by creating parent content types that include any properties that are required across all items and documents of a particular type. Then, as the organization evolves, further properties can be added to the parent content type and therefore can be inherited automatically to all the descendent content types.

Figure 3-6. Parent child relatiohship from system content type to Web Part page content type

Figure 3-6 shows the child parent hierarchy from the OOB Web Part page content type down to the System content type, which is the foundation content type of all content types. The OOB content types also leverage this exact same inheritance pattern; this can be explored by navigating to the parent of each content type from the content type Settings page, as illustrated in Figure 3-7.

Figure 3-7. The Settings page of a content type

Figure 3-8 illustrates a simple scenario for an organization with three types of documents: Contracts, Policies, and Presentations. Each type of document has a specific content type with two unique metadata columns and three generic metadata columns that are inherited from the parent content type called Document Base. If another column was added to the parent content type, all the child document types could inherit that new column. Further unique columns can be added to just the Contract content type to extend it to meet specific business requirements for managing contract documents.

Figure 3-8. Three types of documents modeled as three specific content types

Creating Custom Content Types

One of the great opportunities for organizations when managing information in SharePoint is the creation of custom content types. Figure 3-5 and Figure 3-8 illustrate three custom content types that are not provided OOB when SharePoint is installed; Contract, Policy, Presentation. Other than very simple SharePoint environments that just leverage the OOB content types or simply add a few columns to some lists or libraries, the activity of designing and creating custom content types is an important step in extending SharePoint to meet an organization's specific information needs.

As SharePoint is used to deliver business solutions across areas such as document management, team calendars, team contacts, and publishing pages, you will probably discover a need for many custom content types. The content types for a publishing web site will be quite different than those of a document management repository or a team calendar.

One of the small but useful features SharePoint provides to support a vast number of content types is the ability to group content types. The OOB content types are grouped as illustrated in Figure 3-2; this pattern should be followed for custom content types by creating custom groups to help with sorting and usability of working with content types. An effective grouping approach is solution-centric grouping; Project Site Content Types, Public Web Site Publishing Content Types, Intranet Publishing Content Types, or Platform Content Types.

The most important part of a custom content type is the definition of the columns that define the data it manages. Designing a content type and the columns it needs is a fairly traditional business analyst activity that starts with understanding the lifecycle of the information, the people who interact with the information, and the way people need to find and experience the information. This analysis will inform the requirements and purpose of each column (and will be discussed in more detail shortly).

Once a content type is designed and understood, the approach for creating them is usually very straightforward (see Table 3-2). Once created, they can be assigned to a list or library.

There are no hard and fast rules or best practices around the number of columns in the design of custom content types because it's so specific to an organization's requirements. But here are some usability-centric guidelines that can help with realistic and useable boundaries:

• Aim for 12 or less columns in list content types used for storing data.
• Aim for 5 or less columns in library content types used for storing files.
• Aim for 5 or less content columns, supported by 5 or less metadata columns on a Publishing content type used for creating publishing web pages.
• If a column is not mandatory, remove it; then really justify why it needs to come back.
• Give columns default values for types such as dates or current user, but avoid pick lists as many users will be lazy or simply in a hurry and just stick with the default.
• Keep column names unique, short, and descriptive as they are displayed at the top of every standard list and library view.
• Create three simple and specific content types rather than one complicated yet flexible content type.
• Test your content types with real business users as part of your design and build process.

While lots of columns may look great when the design is on paper and provide amazing future proofing and flexibility, end users will simply not respond well to lots of boxes to populate when creating or uploading information. Many business users will give up and not use the system at all or they will simply populate poor quality values just to get through the process quickly. Either way, the design might be great but the solution won't be a success.

Columns Need a Purpose

One of the significant risks of content types and the inheritance pattern is that enthusiastic architects create such a complex hierarchy of granular content types that it becomes difficult to use and impossible to manage. Any good system design should be as simple as possible. Everything in that system should have a distinct and describable purpose. The same applies in SharePoint 2010 for content types—particularly for columns.

It is a best practice that each column has a well-defined and communicated purpose. If a column doesn't have at least one purpose that can be described succinctly, that column shouldn't exist. In many instances, columns will actually have more than one purpose, because the data they hold may help with a number of scenarios. For example, date columns help with searching and retrieving the content. They can also help define an audit of activity against content for records management purposes. Column purposes can be grouped under four types to help describe the role or roles a column performs; see Table 3-3.

Figures 3-9 and 3-10 show two tables in a style that can be used to document each column. The specific columns in these examples illustrate an interesting scenario relating to the challenges of names and the fact that names can change over time.

Figure 3-9. Example documentation of a column called Client Full Name

Figure 3-10. Example documentation of a column called Client Full Name Record

The Platform vs. the Solution

To design and govern SharePoint effectively, one of the most important concepts to understand is that the SharePoint platform is distinct from the solutions that exist on that platform. A single SharePoint platform can technically manage an Internet web site solution, an intranet web site solution, and a corporate records center solution (see Figure 3-11). While each of these solutions will function differently and possibly be managed independently by different business teams, they all coexist on a single platform and therefore share common platform architecture. A critical part of that platform architecture to understand is the role of content types and managed metadata. In this scenario, will content that is a document have metadata and behaviors that are consistent across all three solutions, or will each solution define a document in a unique way?

Figure 3-11. Three solutions implemented on a shared platform

Often a large corporate intranet is actually a collection of solutions with numerous web applications, site collections, and areas of functionality for end users. These solutions might feel and behave like a single intranet experience, but architecturally they are likely to be different site collections managed by different teams and performing very different functions. However, when it comes to defining specific types of content that will exist across the intranet, you want to them behave in a consistent way regardless of the solution.

Take, for example, project documents. An organization may provision many sites within a projects area of their intranet with each site having the specific purpose of supporting a single project. Some of these projects use a waterfall methodology and some use an agile methodology. Therefore, depending on the project methodology, there are certain metadata columns that support describing documents to suit that methodology, (such as a metadata column called Stages within waterfall and a metadata column called Sprints within agile) but there are also common metadata columns, such as Owner and Project Code.

The organization decides to develop a custom site definition for provisioning waterfall projects and another custom site definition for provisioning agile projects. Based on the size and lifespan of these project sites, it is decided there will be a site collection for all waterfall projects and a site collection for all agile projects. So the organization now has a solution for provisioning sites to manage waterfall projects and a solution for provisioning sites to manage agile projects (see Figure 3-12).

Figure 3-12. Two solutions implemented on a shared platform.

The Role of the Content Type Hub

Once a SharePoint environment is described as being a platform with solutions, then the role of the content type hub becomes easy to explain: to manage common platform content types that can be used by different solutions (see Figure 3-13).

Figure 3-13. The relationship betweem content type hub and site collections

The content type hub is a new feature provisioned as part of the managed metadata service (commonly known as MMS) within SharePoint 2010. A hub provides a place to centrally create and manage content types that need to be leveraged across many site collections or Web Applications. Each site collection that needs to leverage content types from a hub can subscribe to the hub. When a hub publishes its content types, all subscribed site collections will get the content types or any updates to content types.

Take the previous example about the organization with the waterfall projects solution and the agile projects solution each with their own specific site collection. Each site collection will have a specific type of project document represented by a content type, but what content type should the project document inherit from?

Figure 3-14 illustrates a logical approach to leveraging content type inheritance to have a common content type called Project Document that extends from the standard Document content type. The Project Document content type then adds two columns generic to all project documents. Then each of the project methodologies has a specific content type that extends Project Document to add the required methodology specific column.

Figure 3-14. Inheritance of two types of project document

Because the project methodology content types are each specific to their own site collection but the parent Project Document content type is common to both, it's clear in this scenario that the Project Document content type should be managed in a central content type hub so that both site collections can leverage it. One of the great future benefits is if the Project Document content type is updated in the future, both Waterfall Document and Agile Document content types can be automatically updated also.

Once a content type hub is being used in an environment, the content types at the destination site collections are automatically made read-only. This ensures that the intent of centralized management of content types is actual preserved; therefore, if the site collections need different content types that can be configured at the site collection level, don't subscribe them to the hub or don't even have a hub. Once committed to a content type hub, it's best practice to leave content types at the destination site collections as read-only and make all future updates through the hub.

If you browse the blogs posts and forum threads that relate to the content type hubs, a common theme or comment you will find is something along the lines of “The CTHub can become a real nightmare if you don't get your design right the first time round.” This is because it is much easier to add and extend columns on content types through the content type hub than it is to change or remove columns. This is, in fact, not just about the content type hub because the same issues arise when trying to change and remove columns within the context of a site collection. It all relates to the way SharePoint is designed and architected to provide a level of isolation and preservation for content once it is created. Once a content type is leveraged to create content, data is stored against the columns; therefore, for areas such as audibility, version history, and records management, this data (and also the columns) most likely need to be preserved. Just like changing a database schema (which is what changing columns on content types is essentially doing), there are potentially serious implications if the system has been in use for some time and already has significant volumes of content reliant on that schema.

If a new column is added to a content type in the content type hub and published, the outcome is as straightforward as the destination site collections. However, if you want to change or remove an existing column, you first have to untangle the relationships the site column has with any content types within the content type hub; then you have to publish the updated content type. This will remove the read-only state on the destination site column so that you can untangle the relationships the site column has with any content types within each site collection. However, if you have content you need to keep and preserve within a site collection, this needs to be done with due care and consideration.

In the Project Document content type scenario, for this content type to be updated in the future, the content type hub and the role it plays will require a level of governance. This governance will be required to protect the platform content types from misuse or inappropriate change and to ensure that they are used across the solutions on the platform in the appropriate way. When a new solution is being designed for implementation on the SharePoint platform, one of the critical activities is to understand which of the available platform content types the solution should leverage, extend, or add to. (Later in this chapter, I talk more about this design activity.) If this level of governance can't be maintained within an organization as an operational activity for their SharePoint platform, then a content type hub could create more problems than benefits. While in many scenarios with many site collections the content type hub can provide a simple solution to shared content types, it also adds a level of complexity to the architecture and the governance that could outweigh the benefits. This is an important concept for SharePoint capabilities in general; just because SharePoint can doesn't mean you should.

While I don't feel there is a best practice statement I can make around this topic, I can offer some general guidance based on an organization's size and capabilities. These hopefully read like common sense, but we all know that it is not always so common.

• If an organization can't design the information architecture relating to columns and content types in-house and needs to bring in an external party, then they are unlikely to be able to manage that architecture over time and should avoid the complexity that managing content types in a content type hub may introduce in their context.
• If an organization doesn't have a recognized information architecture discipline in-house that can provide guardianship and governance of a complex columns and content types hierarchy, then they should avoid the complexity that managing content types in a content type hub may introduce in their context.
• If an organization has a small team looking after their information management architecture within SharePoint (and often it is just one of the many hats they are wearing), then they need to consider if they can realistically ensure continuity of the expertise and understanding necessary to provide guardianship and governance of a complex columns and content types hierarchy.

To sum up with a slightly left-field analogy: if you don't have the resources to staff, service, repair, fuel, and dock a super yacht, you should seriously consider a less complex, more manageable power boat.

The Role of Managed Metadata

Content types are the building blocks for managing information within SharePoint 2010, but it is the metadata users define and manage against content that brings many solutions and benefits for end users to life. Many people understand the potential benefits of metadata and most have experienced metadata in action through online systems such as Amazon and eBay, but many organizations struggle to implement and leverage metadata effectively within their internal information management systems. There is no travelling medicine man selling a guaranteed magic solution to good metadata because it is a technical issue, a governance issue, and an end user issue. However, SharePoint 2010 does provide some great features for creating, managing, and defining metadata that can help organizations to succeed with leveraging metadata.

When an organization and its users are moving to SharePoint from storing content in network drives and folders, they often struggle to see beyond using folders to organize their content. A simple and effective approach to help them see the role and benefits of metadata is to present the following scenario.

An organization writes many reports about endangered animals and environmental impacts of mining and logging on animals. They currently store reports in a hierarchy of folders using animal's names and different types of mining and logging. If a report is written on the impacts of copper mining around the world on endangered animals, the report is put into the Copper Mining folder. If a report is written on the environmental impacts on tigers, it's put into the Cats folder. So how do you file a report on the impact of copper mining on tigers and panda bears in Asia?

This scenario sets the scene for introducing a better approach of leveraging metadata to organize information. If this organization creates a single SharePoint library for reports and then takes the names of the different types of animals, types of mining, and types of logging and makes them available as metadata, then the report called “Impact of Copper Mining on Tigers and Panda Bears in Asia” can go into the Reports library and be tagged with Copper Mining, Tigers, and Panda Bears. Then, using filtering, views, or search on this library, a user can be presented with reports on Copper Mining, Tigers, or those that include Copper Mining and Tigers. Keep in mind, however, that in very large situations the scale and security for all reports may require multiple libraries or even multiple site collections, and then search can leverage the metadata to create consolidated views from all sources.

The managed metadata service that enables the content type hub capability also provides significantly improved capabilities for managing metadata, as its name implies! The service provides a term store feature, an enterprise keywords feature, a managed metadata feature, and some smart end user controls for defining metadata values for content items. If used wisely these features can help metadata succeed.

The first point to make is that the name managed metadata service is not supposed to trick you into thinking it will manage your metadata. It provides the tooling to enable the management of metadata, but without good design and governance of metadata values and how metadata is used, the benefits will not be realized or will be short lived.

The second point to make is that the discipline of designing and managing taxonomies, ontologies, controlled vocabularies, lookup lists, data dictionaries, and metadata is a large and potentially complex field. Being able to install and configure SharePoint does not instantly make you a metadata master, so be realistic about what can be achieved with the available skills and resources. The tooling provided by the managed metadata service will not reduce complexity. Situations with multiple levels relationships between terms might be too complex to be managed effectively so more specialist taxonomy modeling tools may be required. That said, there are many organizations that don't need or aren't ready to leverage an exhaustive taxonomy or complex metadata. Doing the basics with managed metadata could be a small step for a SharePoint administrator but a giant leap for the organization.

The two primary types of metadata commonly used in content management solutions are controlled and uncontrolled. The more technical terms often used to describe these are taxonomies and folksonomies. Taxonomy is commonly a collection of hierarchical terms that is designed and managed by an information architect and made available for end users to select values from to define metadata against content. In contrast, a folksonomy is commonly a naturally evolving and changing collection of values that users can add to and select from. SharePoint 2010 supports both these approaches through the enterprise keywords feature and the managed metadata feature that through open or closed allows either read-only or read and write.

Enterprise Keywords

To support a semi-controlled approach to metadata, SharePoint 2010 provides the enterprise keywords feature that includes:

• a standard column called Enterprise Keywords that can be added to content types, lists, and libraries.
• an enterprise keywords control for users to interact with when editing the properties of an item.
• an enterprise keywords term set which is a bucket of non-hierarchical terms that via the term store that administrators can use to view and manage the enterprise keywords that have been created.

What makes this solution semi-controlled is the way the enterprise keywords control provides a list of existing terms as the user types. When a user starts to type in the control, a list of existing terms is displayed based on the characters that have been entered. By displaying existing terms, a user is highly likely to find the term they want to add and select that existing term rather than adding a new term. Obviously the longer enterprise keywords have been in use, the more chance that the term will already exist. The list also includes any managed keywords, further increasing their chance of being able to select an existing term. If the user doesn't see the term they need, they are able to add a new term, which will be added to the enterprise keywords term set and will be available to them and any other users next time.

But wait, there's more! Not only do they get existing terms, the terms are displayed relative to their location in the term set hierarchy. Therefore if design is a keyword, they can qualify if they want to select design relative to user interface design or system infrastructure design or landscape design. Exposing existing terms in this contextual way creates a semi-controlled keywords solution that encourages users to leverage existing terms while also allowing them to freely expand the terms over time.

Managed Terms

To support a more controlled approach to metadata, SharePoint 2010 provides managed terms that includes:

• a type of column called Managed Metadata that can be added to content types, lists, and libraries.
• a managed metadata control for users to interact with when editing the properties of an item.
• term sets that via the term store administrators can use to view and manage hierarchical collections of terms.

While enterprise keywords is just a big non-hierarchical bucket of terms, managed terms allow the use of hierarchies to organize and control the context of terms. If a term needs to appear in different parts of different hierarchies, this can be accommodated by reusing terms. For example, in the reports scenario earlier I introduced Tiger as a term for the organization, but Tiger may need to be described in relation to being a large cat or in relation to being an Asian animal. The reuse term capability allows the single term of Tiger to exist in different contexts. If the animal's term set is a closed and therefore doesn't allow users to add terms when they are adding metadata to a content item, then the user will have to select one of the existing terms such as Tiger. This forces a controlled set of terms and removes data quality issues relating to bad spelling or slang terminology.

The End Goal: Finding Content Using Metadata

While managed metadata and the related controls support better population of metadata for content items, metadata doesn't return any business value until users leverage it to find the content they need. The activity of finding content, particularly searching, often relies on users knowing what they are looking for by using familiar keywords and terminology. A user may not be familiar with the metadata terms that have been populated against content items for a number of reasons: they may use different terminology to describe the same concepts or they may be new to the concepts and not have any terminology to use. To support these users, there are two managed metadata capabilities in particular provided by SharePoint 2010.

• Synonyms : In addition to synonyms at the search level you can provide synonyms on terms within term stores; therefore when a user searches using a term that is a synonym of primary term, they will get results back for the primary term.
• Metadata Navigation : Turning on the metadata navigation control for a library provides a tree view of the related term store that the user can navigate through to see if any documents are tagged with the term they are interested in.

While the managed metadata service and the capabilities it provides can be leveraged very effectively, they also add a level of complexity that needs to be considered. An organization should only activate and leverage these rich capabilities if they have the resources and capacity to manage them; keeping it simple with choice columns and lookup lists might still be the most realistic solution. The same applies to the other extreme where an organization has large taxonomy management needs. In these situations the term store can be a very frustrating tool to populate and maintain terms so an additional tool could well be justified to help extend the native capabilities of the managed metadata service to improve the management experience of the taxonomy.

Visualizing the Complexity of Content Types

One of the many challenges in solution design within any enterprise is achieving a shared understanding of what exists within the enterprise systems and platforms that provide boundaries and opportunities for new solutions (as in, what type of search capabilities are available, what web services can be leveraged, what authentication is in place, and what content types can be used or extended?). The first step in achieving a shared understanding is that the people involved need to be made aware of what exists, and one of the most powerful tools for giving visibility to systems and platforms are diagrams and pictures that can capture and visualize the important elements in a single view.

A SharePoint content types model can be used is to illustrate and describe the relationships, context, and purpose of all content types within the different layers of the Enterprise SharePoint Platform. This model is an important information asset for the operational management of content types. As new SharePoint-based solutions and information needs are identified across the organization, this model must be used to design and define how additions and changes to the model happen to support the constant evolution of the SharePoint Platform and the information managed within it.

The Model: Layers

The SharePoint content types model is defined by four layers with each layer representing a logical layer within the Enterprise SharePoint Platform, as shown in Figure 3-15.

Figure 3-15. Model layers

System Layer

Owned and managed by: Microsoft

The system later contains the generic foundation elements of SharePoint that are created by the Microsoft development team that builds the SharePoint product. These are the elements that are automatically provisioned when SharePoint is installed in any organization. The system layer is extended by the platform layer to provide the organization-specific SharePoint platform elements.

Platform Layer

Owned and managed by: Enterprise Architecture

The platform layer contains the global elements that are configured or developed for the organization and are consumed by solutions that are built on the platform or integrate with the platform. The content type hub is an important feature for the centralized management of global content types in the platform layer. As existing solutions evolve and new solutions are created, new global elements will be identified as part of the solution design that need to be provisioned and managed as part of the platform layer.

Solution Layer

Owned and managed by: Enterprise Architecture and Solution Design

The solutions layer contains elements that are configured and developed for specific business solutions that are deployed on the platform. These solutions are often developed by a Project team and then handed over to the Business as Usual team on completion of the project and the solution. Most solutions will be described as SharePoint solutions; however some solutions may be other systems or applications that need to integrate with the SharePoint platform in some way. A critical part of the solution design process is to identify elements within a solution that will consume platform layer elements, extend platform layer elements, are new platform layer elements, or new solution-specific elements.

Site Layer

Owned and managed by: Site Collection Administrators, Site Owners and End Users

The site layer contains elements that are provisioned and configured for a specific SharePoint site collection and/or site that is being used by business users on the SharePoint platform. Sites are the end user experience of the SharePoint platform and the solutions delivered upon it. A critical part of provisioning a site is understanding, communicating, and managing the type of site it is within the organization, relative to the type of solution and the platform. For example, a centralized enterprise search center or enterprise records center is a very different type of site than a Project Collaboration site or a person's blog site. There are “one off” sites and there are “stamp out lots of sites” sites; these are all valid SharePoint solutions and sites but should be understood, designed, and managed appropriately.

Illustrating the Model

The diagrams that follow, Figure 3-16 for libraries, Figure 3-17 for lists and Figure 3-18 for an actual project site, illustrate a content types model for a SharePoint 2010 platform. These were created using Microsoft Visio but could be created in any number of tools or simply hand drawn on a whiteboard or piece of paper. The example model captured in these diagrams is an enterprise view for a relatively small and simple SharePoint 2010 environment that currently supports three solutions.

• Solution One: Management of customer documents within the Lending Services department of the organization.
• Solution Two: Management of customer documents within the Credit Services department of the organization.
• Solution Three: SharePoint site definition for provisioning sites for managing agile projects within the organization.

Reviewing the diagrams that follow for this model, you should be able to clearly identify the four layers and the content types that are defined within each. You should also be able to find the following:

• The system layer content types that are intended to be available for use within sites within this environment.
• The platform layer content types for documents that define the global document content types that will be used across the currently defined solutions within this environment.
• The platform layer content types for tasks and stakeholders that define both these types of content as global types that will be used across the currently defined solutions within this environment.
• The solution layer content types that define the solution-specific content types needed for the three currently defined solutions within this environment.

Figure 3-16. Enterprise Content Types Model—Libraries

Figure 3-17. Enterprise Content Types Model— Lists

Figure 3-18. Provisioned libraries in an actual project site

Summary: Designing for Complexity and Growth

The goal is not to create a complex design, but many organizations and their required information architecture are inherently complex. The real goal is to keep the model as simple as possible yet still meet the business requirements.

Planning for an appropriate level of evolution and change within the model is important, and deciding when to create platform level or solution level content types to support potential future requirements is an important design decision. As discussed earlier, it's much easier within SharePoint to extend content types than to change or remove them. This is particularly true in relation to inheritance. Therefore, it is a best practice to create platform-level content types that provide a parent between the system content types and solution content types. This approach makes it easier to add branching in the model to support future solutions that need to leverage the same content type but with solution specific columns and behaviors. When planning for potential growth, platform content types will often have no specific columns or behaviors when they are first created, but they are ready for them should a future business need require it.

The down side to this approach is the risk of over-engineering and trying to predict every future possibility. An overly enthusiastic analyst can easily create a very complex collection of content types that risks being very difficult to manage over time and difficult for site administrators and business users to leverage. It is critical to keep the end users of the model in mind and balance designing very specific content types that restrict what users can do with flexible content types. Flexible content types provide an opportunity to reduce the overall number of content types in the model to reduce complexity; however, flexibility also increases the opportunity for the end user to use the content types incorrectly when populating content and data into SharePoint.

As highlighted already in this chapter, how much complexity an organization needs vs. how much they can govern and maintain overtime is an important consideration that will influence the approach to content types, metadata, and information architecture within SharePoint.