Why I’m starting to like SharePoint…

Ok, this is quite the shocker I guess. After four posts of not liking SharePoint all of a sudden I come up with a post that doesn’t sound as negative as the others. It’s been well over half a year since I wrote the other posts about SharePoint, and all the quirks I mentioned in them are still in existence. Nevertheless, SharePoint is not a bad product, you just need to use it the way it was meant to be. I’ve seen numerous different implementations over the last few years, both good and bad and that has only contributed to my present day feelings about the product.

At the start of each project it is vital to talk to the customer to see what it is that he actually wants. While on the surface of it, SharePoint might sound like a viable solution there is some stuff you need to take into account. SharePoint can be ideal as a backend for a website or an intranet portal. An implementation where the content and the way your customers/employees use it is the most important factor. That’s what it’s made for. Presenting, sharing and working on content and documents. The SharePoint lists should primarily be used for the things the standard listtypes cater to: document storage, contacts, tasks etc. Of course you can store some additional information in a custom list if the standard types do not suffice, but do not expect full fledged database table capabilities from it.

In my humble opinion it is no good if you purely want to use it as a web application catering to certain processes within a business and saving data of what one could call a business object. Especially if those processes contain lots of conditional do’s and don’ts and have some sort of rights matrix it needs to adhere to. Surely the SharePoint lists system mimics a relational database and it greatly saves you the amount of time to code all of this yourself but it simply isn’t a relational database at the core. “Relations” you create through lookups aren’t forced by constraints and actually retrieving data across multiple lists is a strenuous task. Something you would normally do through a database view or stored procedure.

If you want to create custom reports based on the actual raw data contained in the lists could end up being a similarly hard thing to pull off, because the SharePoint database is such a beast. It simply isn’t what it’s built for and from my experience you will always come across issues, one weirder than the other. The time you eventually spend developing/maintaining such an environment is equal to or greater than what it would be if it was a dedicated (.NET) web application.

It’s too bad that sometimes it seems like the buzzword alone justifies a project to be pushed into a SharePoint-like environment. It shouldn’t. If people would just let common sense prevail and do a good analysis you could always base the actual choice on that. If the customer wants to have it in SharePoint and your analysis says that it shouldn’t be the way to go, you can at least point out that maintenance of such an environment will take more time and eventually cost more. If the functional specs say that SharePoint is the way to go then by all means do so. You won’t hear me complaining. In the end it’s still the customers choice, but it all starts with a decent advice.

Steven | Computer | 21-02-2010 19:44 | 0 reacties

Steven is een afgestudeerd Software Engineer en heeft een baan als .NET ontwikkelaar. Fan van wielrennen, doet zelf aan mountainbiken, speelt wanneer hij zin heeft op zijn gitaar en Xbox 360. Probeert met enige regelmaat te bloggen over vanalles en nog niets.