Print | posted on Sunday, December 21, 2008 2:34 PM
Adam Buenz over on SharePoint Shelter has a nice post titled When Best Practices Aren’t Best Practices. It’s a good read, and pretty much all he says I agree with. There are a few things he doesn’t touch on that I feel like highlighting however, so here goes…
The key problem is the term itself. “Best Practices”. I’ve always hated it. “Best Practices”, says who? :) There’s nothing funnier than someone who has been practicing a particular technology for six months spouting off about them. Well actually there is, and that’s the vendor spouting off about them, especially when the so called best practice is supporting their latest attempt to cover up a weakness in the product.
As I keep telling people (some of whom are listening) Software is about tradeoffs and compromise. One person’s “best practice” maybe a terrible practice for someone else’s scenario.
Unfortunately of late the SharePoint world has a fetish for “Best Practices”. It’s probably one of the babble speak terms you will hear most often (apart from the equally disturbing “governance: of course), usually being spouted by consultants. In the introduction to the all-round pretty damn decent SharePoint Server 2007 Best Practices book, Ben Curry says:
“As you’ll see when you read this book, there is a fine line between best practices and design decisions……
…..at some point, design concepts and best practices are intermingled. At other times, best practices are presented with a notation that other design choices might be possible and might be the best choice given a different scenario.”
He tells it like it is. This might seem like stating the obvious. But the trouble with stating the obvious, is that it more often than not, is nowhere near obvious enough. If it was obvious, it wouldn’t need stating, now would it?!
SharePoint is a complex technology stack, MOSS isn't a product, it’s eight products. It’s got a lot of stuff. It’s got a lot of great stuff (that no one else has got) and it’s got a lot of rough edges. It’s a complex beast.
Most importantly, and I don’t give a monkeys what the vendor presales folk tell you, SharePoint is not a point solution, in any scenario. It’s a platform upon which you build solutions for your business requirements. This doesn’t necessarily mean you need to write code.
Because the “Best Practices” term has become such a vouge in the SharePoint world there are a few key symptoms:
- Inexperienced consultants who did something that worked once, so they pimp their approach as a best practice, when it’s nothing of the sort.
- A couple hundred thousand project managers implementing SharePoint across the globe want easy answers for difficult questions, so ask “What’s the best practice for XYZ?”
- The vendor spouts “best practices” to cover themselves in terms of supportability and services headaches.
Now don’t get me wrong, there are plenty of real best practices out there in SharePoint land. Many of them produced by the vendor. However you simply must not take them lock, stock, the whole lot. They are guidelines for the most part, and must be considered carefully as part of your overall solution and take into account all aspects of your deployment.
Adam talks about best practices often not considering industry verticals or company culture. These are less tangible aspects which are very important to any SharePoint deployment, which after all is about changing, embracing or effecting culture. The “new world of work” the vendor liked to say before they ditched that spin. I though I’d add my views towards some of the more tangible aspects of SharePoint deployments….
1. There are some best practices which are applicable to every single SharePoint deployment. Especially when it comes to infrastructure areas. For example you absolutely should be using single affinity (sticky sessions) in load balanced environments. However for pretty much every other aspect it’s not so cut and dry. Recently there was a bit of a blog battle regarding Site Definitions, there is no black and white – it’s all shades of grey. Again, compromise and tradeoffs.
2. There are no easy answers to difficult questions.
Often times I get emails from folk asking about some development related activity they are trying to get working in SharePoint. The message usually goes something like, “I am attempting to customize the navigation to include external resources from a external system and SharePoint is messing it up, what is the best practice for including such resources within my SharePoint site navigation.”
For that, my friends, what might seem a simple thing is nothing of the sort and simply cannot be answered without in depth analysis, and besides there is no best practice here. There are no easy answers to difficult questions, unless you count the default answer of a “security consultant”, which is of course, “no”. :)
3. Some aspects of SharePoint have solid best practices.
Some scenarios targeted by SharePoint, e.g. Collaboration Portals, have mature, proven best practices which have been refined over years of successful deployments. The sweet spot of the current release is this scenario. There was a solution accelerator for the previous release and the core content on release was in this space. That stuff is solid. It’s proven. However it’s still just a blue print or framework to base your deployment on and extend. Some folks take this and deploy it as is and be successful, but they are the minority, everyone else is building on top of it to meet their business requirements.
4. Some aspect of SharePoint absolutely do not have any best practices.
It’s plainly ridiculous to suggest that some features of the product have associated best practices. Why? Well, it’s simple. because they haven’t been around long enough, and they haven’t been deployed enough yet. You can’t have best practices for things which have only been available for a couple years. It’s not long enough. They are not mature enough.
Take Excel Services for example, that’s only been about for a couple years and is extremely broad. At launch the product group suggested separate ECS app servers were the best bet (reasonable bet hedging that). Now it’s more common to hear them talking about using ECS on the WFE servers. the whole conversation is totally bogus anyway as it depends upon the complexity and latency of the calculations you are performing. If you are just using EWA to display non intensive calcs like sums and so forth, then WFE is the right place, but if it’s some crazy sales projections coming from multiple external sources, it’s another story.
Another example is Document Conversions. If any one tells you there’s a best practice there then they are full of it. Sorry, but it’s how it is. The only best practice in these types of scenarios is how to approach the planning and measurement of a given deployment and taking it from there. And those are thin on the ground.
I’m sure this post will noise some folks up, but it is important to take best practices with a pinch of salt, and verify them alongside the specifics of your project, and remember there are no stupid questions, only stupid answers.
Don’t get me wrong I am fan of best practices, but only if they are truly tried, tested, proven and validated. And just by using the term or label doesn’t make it so. It is important to soak up as much as possible that can help you be successful with SharePoint, and the aforementioned book and the SharePoint Best Practices conferences are some of the best ways to do so.
The bottom line however is to have a deployment/implementation that works and meets your business requirements. If you have that then you have the best practice for your organization. And that is the only thing that matters.