Good post Sean. I like the approach you've taken to leave aside the whole metadata thing with custom content type columns and focus on some of the core aspects about content types and their creation and applicability. I often find that mixing into the discussion of content types talk of metadata, custom columns, document taxonomies, ends up turning people into glazed over zombies :). One important thing to be aware of (or be reminded of) is that content types do not span site collections. This means that if an organization has multiple site collections that require the same content types than they either: a) need to be manually created within each site collection, or b) require a feature (and/or solution package?) to be prepared containing the XML definitions for the content types. With option ‘b’, the feature containing the content types can then be activated for all site collections where those content types are needed. Pulling on this thread a little bit more leads into the great big discussion of an organization’s document taxonomy, information architecture (IA) and application and collaboration needs. Ideally the organization’s document taxonomy and IA has been sufficiently pinned down to establish a common organization wide content type taxonomy defined within a single site collection where that site collection typically represents pan-organizational portal and collaboration needs (e.g. Intranet). When separate site collections are required for specific application and operational needs, then they may have their own content types applicable only within their own confined scope and not required across the organization. A good example would be the TeleDermatology SharePoint solution I implemented for a medical laboratory company. They already had a site collection for their Intranet representing the collaboration and communication needs of all departments across the organization. The TeleDermatology SharePoint solution was a specific business need focused on capturing dermatology appointment information which included patient information. I created a separate site collection with a single content type called “TeleDermatology Encounter”. This content type was not required across the organization so was right at home in its own site collection with little risk of managing its duplication across other site collections. And, of course, other big reasons why a separate site collection and content database were needed included content database security, the need for specific/different/better service levels around the TeleDermatology content database without being impacted , etc. Are you still awake yet? If I don’t stop now, I fear my discussion will eventually lead to a treatise on sex, politics and religion.

Excellent post, and thumbs up to steve's comment for sharing his experiences with content type and site collections!