The starting point of any ECM solution is to define the information that needs to be associated with content so that we can categorize and file it. In IT jargon terms this is referred to as meta data. Many companies and standards authorities have created different names for this and one of the more common terms is "Taxonomies".  In Sharepoint we call the grouping of meta data into a useable template, "Content Types".

There are a number of technologies built into Sharepoint that allow us to build "Content Types" and then there are some features that are linked to "Content Types". I will start this blog by creating a list of these features and then I will explain each in turn and where they fit into the bigger picture:

1. Site Columns - this is the basis of all meta data in a Sharepoint Site Collection and determines what meta data fields are available and how they are defined.
2. Microsoft Office - this suite of tools becomes the front end for completing the meta data fields and are mapped to the user interface through MS Office Templates.
3. Workflow Rules - Workflow is used to route information through an organization using the meta data fields associated with "Content Types".
4. Event Handlers - allow you to execute custom code stored in assemblies that are connected to events fired by the "Content Types" when the meta data fields change information.
5. Document Libraries/ Web Pages/ Lists - are the objects that "Content Types" are linked too on the user interface of Sharepoint.

Site Columns:

The easiest way to understand site columns is to think of it in terms of a database with tables and columns. When a developer builds a standalone application, they normally store the data into a database by using columns grouped together as tables. In the case of Sharepoint, we tell it what data to store and it will create the underlying structures for us to stored the data.

To put the previous statement into context, Sharepoint will not actually create new tables in the database. It will use standard tables that were created during installation to stored the new columns as records. This form of storing data about data is called metadata. Therefore the column definitions as well as the data stored in those columns are stored as records in static tables.

These metadata columns are stored in one big list, but can be categorized. The process of grouping the columns together to form a logical unit is called a "Content Type".

Office Templates:

The next process in building an application, would be to create a user interface to store the data into the database. This can be achieved through a number of ways:

• Building Lists in Sharepoint to Store structured data.
• Building web parts to store data either in the Sharepoint Content database or in an external database.
• Using MS Office 2007 to fill in the meta data fields.
• Building 3rd party application that communicate to Sharepoint via the XML web service.

Due to the fact that most of the data stored in Sharepoint tends to be unstructured content in the form of MS Office documents, it makes sense to use templates in MS Office to complete the meta data fields. This is done by grouping the meta data fields into content types and then exposing it to the presentation layer via MS Office templates.

Workflow:

One of the fundamental problems that we face today is the flow of information through an organization. All businesses have processes that they follow to complete a business transaction from initiation to completion. In most organizations this process is still a vary manual procedure that lends itself to all kinds of problems and therefore the processes seem flawed.

This particular problem has been addressed by implementing ERM, CRM, EPM and various other systems, but they all have one fundamental flaw. They only work with structured content stored in databases as records in tables. Unfortunately almost 80% of data in the organization is stored as unstructured data in the form of files stored on file servers.

The question therefore is: "How do I workflow unstructured content?".

This problem can be solved using a number of features together that are all provided by Sharepoint:

• Document library's in Sharepoint to store the unstructured data.
• Site Columns to stored the structured data in Sharepoint.
• Content Types to group the structured data together as logical units.
• Office templates to link the Content Type to the unstructured file.
• Workflow to manage the business process by using the structured meta data stored in the content type.

Workflow's can also be acquired or built using a number of tools:

• There are a number of standard workflow's that ship with WSS and MOSS.
• New workflow assemblies can be download and purchased on the Internet and then installed.
• New Workflow's can be built using SPD (Sharepoint Designer).
• Very Complicated workflow's can be built using Visual Studio.
• Third party tools exists that build workflow's: "K2", "Interwoven", "Documentum","MetaStorm" and many others.

Event Handlers:

There is still one problem! How do I connect the workflow (built as a .NET assembly) to the Sharepoint interface and when does it activate? This particular problem has always been solved using events in the OOP world of .NET on which Sharepoint is built. Therefore it is only logical that Sharepoint supports events.

These events are connected to the Content Type and the Content Type is connected to the user interface. It is therefore possible to connect custom methods stored in assemblies to the events of the Content Type. Of course this will not be possible unless Content Types were used in the first place.

Content Types:

Content types therefore becomes the glue that brings all the bits and pieces together:

• Site Columns are grouped together to form a Content Type.
• Office Templates are built and linked to the Content Type.
• Workflow's and custom assemblies are built and linked to the event handlers available in the content type.
• Content types are linked to the user interface by associating them with document library's, lists and web pages.

The only reason some people get away with butchering a Sharepoint deployment is the fact all the standard library's and lists come with a default content type. If this wasn't the case, then most developers would still be in the dark and some are still happily destroying their Sharepoint deployments.

Conclusion:

It therefore should be very clear, that before a Sharepoint deployment goes live. All content in the organization has to be mapped to content types before the content is actually created or uploaded into Sharepoint. A lot of time and effort will be saved. It is very difficult to do this after the content has already been loaded and stored.

In my next blog I will guide you step by step through the process that I just explained.

Related Blogs:

The Importance of Site Columns in Sharepoint

High level overview to what workflows are

Office 2007: Accepting the Change

Overview of the .NET Platform