SharePoint or not?

If you’re working with SharePoint for a long time, you’ll notice a pattern that shows up in many projects:

sales: Sure we can do it in SharePoint!
project manager: Or can we?
developer: Hmmm, I think we need a relational database solution for this.
architect: Do we really? I’m not so sure there.
developer: Yes we do. And SharePoint is not relational, so we can’t do it.
architect: I’m sure we can. We just need to rethink our approach a bit.

Coming (I’ll admit, years ago) from a Domino background, this is not something new to me. These kind of conversations usually happen when we get a customer request for a solution that is stepping out of the ‘out of the box’ boundaries of SharePoint or when we are asked to migrate an existing solution to SharePoint.

When stepping out of the OOTB boundaries, it’s not uncommon that you are working with a specification from our customer, or even have some screen shots / demo builds to work with. And it’s again also not uncommon that the customer comes from a relational database background. Users came to depend on the fact that you can build relationships within data, and that’s how they think nowadays. They made their own MS-Access databases maybe even, proving their approach, and that’s what are presented with.

Then the specialist comes in telling them that SharePoint is following a non-relational approach. That everything we store is like a file in a folder (read: an item in a list). And that although you can refer from one item to the other, when you remove one of the items, the reference does not resolve anymore, and it’s not even notifying us of this (notice: this is being taking care of in SharePoint 2010, which does allow relationships between items in a list and also maintains/enforces them).

There are 2 ways to solve the customer request: either you go for a relational database solution or your re-think your approach. Do we really need to maintain relationships in our data? Well, sometimes you really do, but it’s also not uncommon that you really don’t. In some solutions it’s perfectly acceptable to copy those little snippets of data that you need to ‘refer’ to actually into the item that you are storing. Only if you need to be able to dynamically update those added items in a later stage, well, then it’s a bigger challenge in SharePoint.

And that’s where the re-thinking comes in. You have to look at the base problem, not at the customer solution provided to you. Do that, and SharePoint is a very viable solution in many cases. Even if you decide to go for a relational database solution, SharePoint still adds to the value. Easy deployment of solutions, access management which can be done by end users instead of administrators, making solution more scalable by adding servers to the farm, etc.

Note: SharePoint 2010 solves many of the challenges and also allows for solutions where you actually don’t have to re-think the approach, more of that in upcoming posts.

Advertisement