Base Your SharePoint Database Architecture on Business Requirements First, Database Concerns Second
Sometimes when I’m speaking at SharePoint events, I’ll mention something about the fact that “the geeks” make decisions about Site Collections and database boundaries that are a detriment to the users. I got a question about this the other day:
…you mentioned something that I wanted to follow up on: basically it was a warning to avoid setting up the information architecture (site collections and thus ability to shuffle between databases) based on “the geeks”. I would love to find out what the issues you’ve seen or experienced that were caused by breaking up data across site collections. I image it might be the cross site query web parts and such.
The main thing I am referring to is the promise of being able to promote content from private or local contexts into wider contexts, therefore maintaining the single version of the truththat Microsoft sometimes talks about. This single version of the truth ought to apply not just to content when considered from a database perspective, but also from a Content Management perspective. A particular version of a document ought to exist in exactly one place. Of course, that’s far more easily said than done, but it’s a Content Management goal.
Note that when I talk about “the geeks”, I mean those of us (yes, I sometimes belong in this group, too) who view the technology for technology’s sake over what its function for the users should be. If you’re an admin who never talks to end users about what they need, then you probably are in this group, though you might not be because you are able to extrapolate their needs well.
Take the example where an Intranet has a root Site Collection and then a Site Collection per Department. (A simplified example, sure, but not that uncommon.) If there is a document in the HR site that we want to promote to the root site, there are no good mechanisms to do it. Site Collection boundaries are primarily security boundaries from the end user standpoint, so we can run into permission issues. We also don’t have a good way to keep a pointer on the root site to the actual document in synch. That means there can’t easily be one version of the truth.
CQWPs and DVWPs in CrossList mode are also out of the question for doing things like rolling up Announcements, for example, which is an extremely common use case. Again, Site Collections are permission boundaries, so those Web Parts don’t work across them. We have to resort to all sorts of tomfoolery using the Web Services or third party tools.
Of course, to the geeks, it makes total sense to make the Departments individual Site Collections. They want to be able to manage the content that way so that they can go to one Department if that Department’s content is getting out of hand to make them clean it up. But it often doesn’t work from a user perspective.
A more complex example would be a smaller organization (as a larger one is unlikely to find the idea palatable) which wants to use SharePoint for its Intranet, Extranet, and Internet sites. Ideally one could create work output in a Team Site in the Intranet somewhere and upon completion, promote it to expose it more widely on the Intranet. That itself if often a problem. But what if we then want to expose that piece of content in multiple Extranet sites? Or we want to expose it as part of the content corpus on the Intranet? Now, one can easily respond with all sorts of enterprise-class concerns about security, but that’s up to the customer. These scenarios come up with my clients all the time, and if they want to make them happen, it’s their choice. The geeks will usually set things up to preclude any of this because of the content database concerns they have.
The business sometimes simply can’t do what it wants to do because of decisions based on database concerns, and SharePoint is blamed for a shortcoming which it doesn’t actually have. That’s not a good thing for any of us.
Making things easier for end users is important, but the security concerns are equally important. There maybe some documents that HR would want everyone to see, but there might potentially be a lot of documents they wouldn’t want anyone outside the department to see. What’s the strategy for maintaining those silos and maintaining one version of the truth?
CarlosT:
The security concerns would be part of the business requirements. I’m not suggesting a open free-for-all, but a requirements-driven approach to farm topology. Requirements first, databases second.
M.
You make a great point Marc in “requirements first databases second.” We fall into the smaller category, but we still had reasons (backup, performance, warnings about having too much content in one database, etc.) to split things up. We also ran into a requirement to have our Internet-facing content in its own farm because of legal requirements drafted, perhaps, by people (outside) without a firm grasp of technology. We weren’t asked to explain our security; we simply had to agree to very restrictive requirements in order to get some content. In trying to keep to the one copy rule, we find ourselves asking users to meet us in the middle. Sometimes, department material will be split into Dept-a Public and Dept-a private. For example, HR stuff that needs to be locked down is in “HR”. HR stuff that needs to be shared is in “Employees.” This works but makes it harder on the users. In other cases, like when one department needs infrequent access to another department’s content, we will rely on links.
We also have purchased a few of those third-party tools and we are trying to get familiar with the tomfoolery.