4 minute read
The other day, I got a question form an ex-client about Content Types:
How many content types can we reasonably have in a document management collection for a large organization, with multiple document libraries? I am proposing using around 200 content types. We are 12,000 people in 130 countries, so we are big and complex. Our IT guys say this may be too many and they want to consider using much fewer, with just a metadata column to distinguish between content types. I believe this is ultimately a less powerful approach, but I wanted to check with a real expert such as yourself.
First off, after some quick Binging, I can’t find any mention of a hard technical limit on the number of Content Types. I’m sure that someone out there will tell me some number per something, but in SharePoint 2010, it’s gotten pretty hard to run into technical limits without working at it.
In my opinion, the right number of Content Types is the number that you need. (How’s that for a consultant’s response? But I think it’s the right one.) In looking for limits I ran into one well-written piece (Note: the original link seems to have gone south. Here’s one from the WayBack Machine.) from Stephanie Lemieux of Earley & Associates where she says very similar things to my opinions. (It’s a really good article, which includes discussion with Shawn Shell. I recommend reading it.) In her article, she mentions that they “typically end up with about 10-15 content types for a site of medium complexity”. That’s an interesting range, but it’s really rather arbitrary, and I wouldn’t treat it as any sort of real boundary.
What you certainly wouldn’t want to put in place is a Document Library where your users must choose from dozens of Content Types. (There are exceptions to everything, of course.) What you build *must* make sense to the end users; it’s doesn’t matter much at all whether it makes sense to IT, unless it is going to cause a serious technical issue. (See “First off” above.)
Content Types are an incredibly important piece of any information architecture. They really represent the different “business objects” that you might need to move through your SharePoint environment. They might represent what you currently have as printed forms (Paid Time Off Request, Laptop Upgrade Form, etc.), “light” content (Weekly Project Update, etc.), or significant, meaty documents produced only rarely (Annual Report, Position Paper, etc.). Deciding what should be a new, individual Content Type versus piggybacking on an existing Content Type by varying a metadata value is more art than it is science.
It’s important to keep in mind that Content Types have hierarchical relationships. Every Content Type you create inherits from one of SharePoint’s basic Content Types (Item, Document, etc.). Your Content Types can also inherit from each other. For instance, you might have a Content Type called “Status Report”, with other Content Types called “Weekly Status Report”, “Monthly Status Report”, and “Annual Status Report” inheriting from it. This allows you to inherit the metadata structures of the parent Content Type and add to them for each specific child. Changes to the parent can be applied to all of the children, if desired (and it usually should be).
The key components of a good set of Content Types should be driven by the needs for permissions, metadata, workflow, and what templates you want to provide to your users. If there is uniqueness along any of those dimensions for a particular business object, then it may deserve its own Content Type.
There is certainly library science that you can bring to bear: people with that background tend to be pretty good at this, by training. Sometimes that discipline doesn’t translate as well into the SharePoint realm as it might, so having someone who really understands SharePoint as well is critical to building good information architecture. Creating a strong information architecture should rarely be a one-person effort; you should involve the library science role, the SharePoint role, and lest we forget, the end users.
Also keep in mind that in SharePoint 2010, there is a Service Application called the Content Type Hub. This Service Application allows you to share Content Types across Site Collections, Web Applications, and even SharePoint Farms. (In SharePoint 2007, the scope for Content Types was limited to a single Site Collection.) With the Content Type Hub capability the “E” in Enterprise Content Management (ECM) truly becomes possible.
- Introduction to Content Types (MSDN)
- How to: Customize Content Type Syndication in SharePoint Server 2010 (ECM) (MSDN)
- Plan to share terminology and content types (SharePoint Server 2010) (TechNet)
- SharePoint Content Structure – Let a thousand content types bloom? (Stephanie Lemieux)
- SharePoint 2010 Content Type Hub (Marcel Medina)