MOSS 2007 Document Management Services - Document Centralization

I received a question (or, I should say many questions) from a reader today:

"Is there any problems with Content Editors and Users requesting documents for editing/viewing from ONLY ONE Central Document Library that contains metadata columns that classify the documents by business group, industry, material substance, division, etc.

Does response time take a hit because all the documents are located in the same doc lib ?

Is this central doc lib a recommended Microsoft approach (is there a Microsoft architecture or implementation document that supports this) ?

Appreciate any feedback or resource link you can provide."

First and foremost, when I am referring to Document Centralization, I do not mean using a single Document Library.  The container itself could be your entire MOSS 2007 Enterprise Knowledge Management implementation, a Site Collection, a Site or any combination of the above.

By Centralization, I am primarily referring to eliminating disparate locations where files in your organization are stored; i.e. Exchange Public Folders, File Shares, Local Machines, Laptops, etc.

Now on to answering the questions...

"Is there any problems with Content Editors and Users requesting documents for editing/viewing from ONLY ONE Central Document Library that contains metadata columns that classify the documents by business group, industry, material substance, division, etc."

As I indicated above, I don't believe you will find using a single Document Library working well; unless, of course, you only have a couple-hundred documents to store in SharePoint.

I also don't believe you will find this approach to content classification to work well.  You can eliminate the amount of work the end-user has to do by classifying your content first.  For example, you can create a Document Content Type named "Customer Contract" and only allow the storage of such documents in the Sales Site or Site Collection.  Just doing this, without any further metadata eliminates the user from having to classify the department or LOB; i.e. we already know it is a Contract and we already know it belongs to Sales.  Taking this concept one step further, you can create another Document Content Type named "Vendor Contract" and only allow the storage of such documents in the IT Purchasing Site or Site Collection.  You have now defined two different types of contract documents for your organization but the primary classification is explicit.

In the above example, I would recommend creating 3 Document Content Types; i.e. "Contract Base", "Customer Contract" and "Vendor Contract".  The "Customer Contract" and "Vendor Contract" Document Content Types would be derived from "Contract Base".  I would then define all common metadata in the "Contract Base" Content Type; such as Contract Number, Total Value, Expiration Date, etc.  Each derived Content Type, "Customer Contract" and "Vendor Contract", would then build upon the base and add any specific metadata, behaviors and information policies.

"Does response time take a hit because all the documents are located in the same doc lib ?"

No question about it; but maybe not in the way you are thinking.  MOSS 2007 uses SQL Server as the back-end data store, not the file system.  Storing hundreds, thousands, even millions of documents in SQL Server can be accomplished.  Queries and also be tuned to obtain results very quickly.  However, once all those documents have been retrieved from SQL Server, an HTML page has to be rendered; and this is where you will take your first hit with regards to response time.

And, of course, this is where you are going to get a lot of flack from your users too!  Why?  If you are attempting to retrieve a couple thousand documents from SharePoint, there will be a small delay in response time; depending on your hardware and network.  Forcing your users to scroll through a couple thousand document is a whole different animal.  They will hate you!

"Is this central doc lib a recommended Microsoft approach (is there a Microsoft architecture or implementation document that supports this) ?

I don't believe you will find anyone (or I at least hope not) at Microsoft recommending the use of a single Document Library to store all of your organizations documents.

I hope this cleared things up for you and anyone else reading these articles!  If not, shoot me the next question and I will do my best to get it answered!