There are good and bad SharePoint deployments, and for all of the product's prominence in the content management...
system marketplace, the bad ones far outnumber the good. Why? There are several reasons, but one primary issue is sprawl.
SharePoint sprawl happens when an organization implements content management in the enterprise without first rethinking its use or planning its new structure. At the most basic level, poor content management practices that an organization has in place prior to deploying SharePoint are simply replicated within SharePoint. Papering SharePoint over poor content management practices just makes things worse, not better.
Where old files go
The most common reason for sprawl is the migration of file shares, those ubiquitous wastelands where old files go -- not to die, but instead to live on in zombie-like perpetuity. File shares are like tumors: ever-growing and virtually impossible to kill without destroying the host. Destroying horrible file shares by opening up SharePoint seems an obvious move.
SharePoint needs to replace dead file shares. But what do most organizations do? They use SharePoint exactly like a file share. They continue to use nested folders; they fail to create metadata-driven views. In short, they save content in ways that are no different from saving content in conventional file shares -- apart from their new residence within the administrative and security shell of SharePoint. We started with a mess; we now have a secure, well-administered mess.
The old sprawl
In SharePoint, the idea is to organize content into libraries and to configure libraries in such a way that file folders are no longer be used. Instead, a library should be configured as a kind of "meta-folder," with all content tagged such that one library can have many views, each view being a virtual folder, displaying only the files that are appropriate to the view. In this way, the hard-coding of file-defining metadata within folder hierarchies goes away. The trick has been to get SharePoint users to adopt these practices, which they often don't.
With the SharePoint 2013 release, Microsoft is being proactive in encouraging better practices to combat sprawl. The old sprawl of poorly organized content, for instance, is addressed in the implementation of My Site-based default storage of all of a user's Office work. This kills several birds with one stone: It puts those files into the content management system (CMS) -- as opposed to the user's local hard drive -- where it can be readily made available to others, tagged with metadata, easily shared for additional input, placed into workflow and so on. But it also enforces, by default, Microsoft's intended usage of SharePoint libraries. Put another way: You have to go out of your way to screw it up.
The new sprawl
With the advent of SharePoint 2013, we now have a whole new kind of sprawl, one with the potential to affect the enterprise even more negatively. With its expanded enterprise search capabilities and the new features of SQL Server 2008 R2, it became possible for SharePoint to store virtually anything in the CMS -- and many organizations have begun to do exactly that.
And why not? Having everything in one place makes sense. Having it all discoverablemakes even more sense. Factor in the SharePoint security and administrative envelope around all the content, and it's a no-brainer.
The only problem is that, while you can put everything but the kitchen sink into SQL Server now, that doesn't mean that you should. Audio files? Video files? Massive graphics? These data-intensive files can undermine SharePoint in a whole new way. The new SharePoint sprawl slows your CMS to a crawl by dumping all the content that used to be in conventional storage into SQL storage, with no strategy or organization in mind.
Effective storage planning
Yes, we want the administrative and security benefits of SharePoint applied to all enterprise content -- and yes, we want discoverability, tagging, views. But there's a right way and a wrong way to create these things.
The right way is to produce a storage plan by content type -- not an abstract type, but an actual physical file type. Office files go into libraries, as well as audio and graphics files, possibly, subject to some file size guidelines -- but large files, binary large object (BLOB) content, video files and other exotica need to be handled separately.
SQL Server 2008 R2 offers the means to do so. There's a new feature called RBS (Remote Blob Storage) that enables the rerouting of unconventional file types to peripheral storage (standard Windows-based file storage) rather than to SQL database storage. When these files -- very large video files, let's say -- are routed to peripheral storage via RBS, they are nonetheless still "in" SharePoint, from the user's point of view -- still secured and administered like any other file stored in SharePoint -- but they are not literally stored in the SharePoint CMS; they're sitting next to the database, in NTFS.
Instead, SQL Server points to the file in peripheral storage (on the same physical server) -- storage that's cheaper and more efficient than SQL Storage for large files. All of these differences are transparent, but they make a huge difference, performance-wise.
The end result is greater efficiency, better practices, faster response, broader access -- and an end to SharePoint sprawl.
Using SharePoint tags effectively
SharePoint document management strategies
SharePoint performance all about SQL Server