Logical Organization and Security
Building a collaboration and information-sharing platform is more akin to an art than a science, in the sense that are multiple ways of organizing content, and there is not necessarily one “right” organizational schema. One of the strengths of SharePoint is to allow the same content to be categorized in multiple ways, regardless of where the content resides on the site. (For example, SharePoint could return all the Web Pages that are “News Articles” from the whole site, or it could return all the content related to “Japan”, whether it’s a News Article, a document, or anything else.)

A complicating factor in most content management systems is that security settings are applied to logical hierarchies of information. As an example, content related to an Accounting site is information that is pertinent to the Accounting Department, so the site itself serves as a kind of categorization element. However, it’s also likely that only members of the Accounting Department would have permission to change the content in their site. So whereas the grouping of information has the benefit of providing logical categorization, permissions are also applied to this grouping. (SharePoint has the ability to allow users to apply “Item Level Permissions” to each of its list items, but that is a cumbersome and less recommended approach.)

A good SharePoint solution balances the needs of placing content in logical locations in the site, while keeping in mind security requirements for the content at a list or site level. When content is not kept in the same logical location on the site, it’s important that common information is shared between the similar pieces of content, providing a connection between content throughout the site. This can be accomplished by providing a common Site Column that can be shared by information throughout the site, then using a “canned” search or a custom search scope to return only those items that have that Site Column.

Reviewing Site Columns and Content Types
When working with clients to define their Site Columns and Content Types throughout a site, no one wants an overabundance of either, because that means more to maintain. I try to ask my clients (and myself) the following questions when trying to define what the necessary Site Columns and Content Types should be:

How is the Content Type or Site being used?

Content Types have four major uses, in my opinion:

  1. Re-usability: CTs can be deployed to any number of lists that use them; coding Content Types into Features means CTs will have common GUIDs across Site Collections
  2. Site Columns: the CT has a collection of Site Columns that should always be included with it.
  3. Document Template: the CT was created because there’s a particular document template associated with it.
  4. Workflow: a particular workflow needs to be associated with all documents of this type.
  5. Information Policies: an Information Policy can be attached to a particular CT.

By evaluating how the content type is being used, you can start to evaluate where and how it should be defined. For example:

  • If a lot of CTs have the same set of columns but different document templates, you can choose to define the CT once at the Site Collection root, then simply apply different document templates to the individual document libraries that use the CT (as long as this will not disrupt search results, if all the documents have the same CT.)
  • If a bunch of CTs are being created only because they have a document template associated with them, create a hierarchy so they all inherit from a single CT, such as the Document CT or a custom one you define.

When looking at Site Columns, the first question to ask is if there is redundancy. This can often be the case if multiple groups within an organization have collected information for you. For example, did one group have a column called “Client” while the other group called it “Customer”?  (I recently worked with a client where this sort of thing was the case, and my asking for consensus on a common term for a Site Column brought to light a general inconsistency within the organization itself on how something was named. By encouraging the organization to pick a single term for the Site Column, I was able to encourage less ambiguity within their organization and hopefully help them avoid confusion in the future.)

Something else to keep in mind is that we (SharePoint consultants) sometimes refer to Site Columns as “fields”. Some other people think of fields as fields on a form. If a customer is thinking about a Word template or InfoPath form, they can be tempted to want to see every field in the form as a Site Column in SharePoint. However, this can be overkill, if it’s okay for someone to open up the document itself and view that information.

In general, I think Site Columns are used in about 3 ways:

  1. For filtering and/or sorting a given List view: for example, a list view where users want to see documents grouped by a column called “Country Code”.
  2. For search queries: “Return all the documents where the word ‘Taiwan’ shows up in the document” or “Return all the documents in the site where the ‘Country Code’ equals ‘Taiwan’.
  3. For CAML queries that need specific results: for example, if a Content Query Web Part needs to return a list of all the documents where the country code is “Taiwan” in the current site.

If a column doesn’t need to be used for any of these purposes, it’s important to ask if it really need to be used as a column.

If you’d like another resource, Robert Bogue published a white paper on TechNet that has a nice overview of the use of meta data and content types in SharePoint, called Managing enterprise metadata with content types.