SharePoint’s impact on information management – a comment…
So… I went to the JBoye.com conference – SharePoint at work – in Copenhagen a few weeks back. Let me start by sending a “shout out” to the people behind these events. Again they succeeded in attracting an excellent crowd and foster a lively discussion and exchange of knowledge and experiences. Good work by the event staff – and great food!
During the last session about SharePoint and information management, I heard a few “slip’s” in regards to how SharePoint really works. These could lead to mistakes for companies using SharePoint today and others in the process of evaluating SharePoint. As I have gotten a few questions about this afterwards, I think a post on the topic are in place…
During the talk these statements were made, that I feel deserves a few more details….
“The difference between a SharePoint intranet and a SharePoint collaboration portal is paper thin.
I dont think this is true at all..!
Companies that have worked with both of these scenarios know that there is quite a few differences that needs to be taken into consideration. For the operations team there is a world of difference in the way these two solutions should be designed and managed.
The reason is, that the usage scenarios are completely different. The intranet should be designed to meet a Web Content Management / Publishing set of requirements, where there are only a low number of publishers (or contributors) but a large number of readers. Also the content are primarily HTML based, meaning that individual files are lightweight and can be cached progressively to strengthen performance – especially in a global implementation.
The Collaboration scenario will have an equal number of contributors and readers. You could argue that all users are really contributors, which means that the interactions that they will have with the application will be of a completely different sort than in the intranet scenario. Files are likely to be in different formats, where the ones we see most often are PDF’s, Microsoft Office files (pptx, docx, xslx etc.) and in some places media and drawings (images, autocad etc.)
For the operational staff these differences are HUGE! Many companies have already made their own experiences with poorly designed information architectures and logical architecture for SharePoint. The problem here is not SharePoint as a platform, but the fact that most people still do not get the difference – and how to deal with them.
“SharePoint stores document in the database as blobs… (a problem to scalability)”
This statement was followed by a few details to make the case that it is not posssible to scale SharePoint as a document repository, compared to other systems. The example given was the a 200Gb recommended limit = 200.000 documents.
Well – if you try to do the math – these documents must be quite big documents. In the standard configuration of SharePoint there is a soft limit for filesize that will not allow documents at this size. The best explaination is that this is an “on stage” mis-calculation.. The worst is that the speaker tried to make a “scary image” with no reality attached to it.
It’s true that SharePoint – by default – stores documents in the database. The reason for doing so, is that it allows a lot of built-in management tools to move content around the SharePoint infrastructure, for more flexible management – without impact for the users. This is actually a good thing!
But – as database storage is often more expensive than file storage, and as the size of a content database should be limited for it maintenance reasons, there are scenarios where you would like to able to store large documents and files outside ofthe database. What the speaker failed to mention is that this (Remote BLOB Storage) is perfectly supported in SharePoint, and is a fairly common way to design a document intensive SharePoint infrastructure. If you want to learn more about this – check this out: http://technet.microsoft.com/en-us/library/ee748607.aspx
Actually – Using Remote BLOB Storage (RBS) can be used for setting up SharePoint with SQL Server Express (2008 R2) which is a very cost effective installation (License-wise). With this type of installation you can store files with a corpus of much more that the built-in 4Gb hard limit that applies if the files are stored inside the database. There are naturally both pros and cons for this solution – but now you know about it 🙂
“Records Management does not work because of content types…”
The statement here is, that records managers store records in series with retention policies. With SharePoint a rentention policy is attached through the content type of an item – and all items (documents, sites, data or whatever) must have a content type (and only one) in SharePoint.
This is correct. But in SharePoint you have a special type of document – called Document Sets – that has that exact functionality. A question from the crowd about Document Sets had the speaker explain that Document Sets will store each individual document with it’s own content type – and therefore the documents in the Document Set are stores with different types.
This is actually not the case, as a Document Set – when sent to a Records Management site (called Records Center – where records are stored and managed based on the policies applied) – is saved as a ZIP file, containing all the relevant documents. The content type of the Document Set (You CAN have different types of Document Sets) will the decide what policy will be applied in the Record Center. So Document Set becomes Records Series and a common rentention policy can be applied to all files in the series.
From my point of view Content Types are actually providing a much more flexible and functional platform for Records Management, but you need to understand Content Types to get the full benefit.
The only conclusion you can have is that understanding SharePoint is difficult! As a platform, it serves multiple scenarios – more than any other platform. That gives a high complexitiy when planning and designing business solutions.
As SharePoint is the de facto standard in thousands of organizations, I would argue for spending more resources in understanding the capabilities of the platform, before bying another platform for Records Management – just as an example.
To make the business case you need the full picture! And this is where SharePoint continue to have challenges…