What is a best practice? Ben Curry definitely one who has popularized and even trademarked the concepts around SharePoint Best Practices through the book and conference has decent explanations of best practices… “Best Practices is about doing things the right way: the most efficient, effective ways to achieve goals, distilled into adaptable, repeatable procedures you can use.”
Blogs are great for sharing your version of the truth and what you’ve learned about the product, but my concern lately is those who read one blog and get one version of “truth” they get one “best practice” and consider it golden. There’s a real problem these days of looking at a problem with only one pair of rose colored glasses.
Consider these “Standards” from SharePoint Hillbilly, one with a unique perspective, but not complete perspective. He makes some decent points in his recent post “10 SharePoint Deployment Standards,” but at the same time with only one perspective, I want to show you how this list of best practices apply in certain situations and and illustrate there is no one size fits all with SharePoint. After getting back from the land of rat temples, and goats on top of busses, I see there are more ways than one to get things done… it is said there is more than one way to skin a cat. Not sure where that came from, (maybe a hillbilly?) but the principle is once applied to SharePoint is real. I hope people have found in my posts despite when it sounds like I’m saying there’s only one way to go there are exceptions. It’s these exceptions… why the consultants get paid the big bucks! (I know @Mrackley rocks and won’t take this personally. He uses google ads a poor practice, so this makes him an easy target. :) ) He makes some statements, this isn’t to discredit him, but more to provide some insights and create an antithesis… I hope he understands the use of these as an example and continues to provide his great insights. Let’s look at a few of these examples of his deployment standards and under each of these I’ll explain how these wouldn’t apply in some deployments. You’ve wondered why Microsoft’s TechNet documentation has challenges and it feels like they should be be providing more guidance, seems very rare that you get the… it depends on X, Y, and Z… you should. There really are a lot of scenarios where one set of guidance is based on assumptions, and this is where SDPS and consulting comes into practice. Just make sure that guidance you are getting comes from solid experience and is based on the right assumptions.
Excerpts from the SharePoint Hillbilly’s 10 SharePoint Deployment Standards
HB 1) SharePoint Designer must not be required to update any portion of a SharePoint Site
For WCM, I can understand some of this, but for a collaboration environment, and one where people have been trained… SharePoint designer has a place. Note the word training, and I’d add qualified.
HB 2) No SharePoint Designer WorkFlows
The SPD workflows do have portability issues, but again if you aren’t using SharePoint for records management or have invested in a crack dev team using visual studio workflows, or have the ability to purchase a third party workflow system, (which I do find pays off) the SPD workflows can fit minimal requirements for many collaboration and non complex scenarios.
HB 3) All sites must be created using Site Definitions or Site Templates
This sounds like a tough requirement designed for serious WCM. I’m not a fan of custom Site Definitions, I have grown to accept a minimal site definition that essentially uses the blank template and then uses feature stapling, but custom site definitions and custom site templates really aren’t required for most collaboration environments which I personally find are the most common deployments.
HB 5) Large libraries (>2000 items) should be divided across multiple libraries.
Large libraries should definitely be optimized, but you shouldn’t split them by 2000 items per library that’s going to cause an explosion in a DM or ECM environment and render the SharePoint navigation difficult. Folders are better than more libraries, and I know folders are used in a different standard. I’m not a fan of folders either. Meta data should be used, and so should limited filtered views that return less than 2000, but ultimately 100 or so in any given query.
HB 7) Team Site Collections should not have more than 1 level of subwebs. (Subwebs should not have sub-subwebs.)
There’s a place for nested site collections. One example is with portals. An Intranet portal could have the Intranet portal at the top, then a set of site collections for the divisions, then groups or lines of businesses, and then products, and so on building a heirarchy. I wouldn’t say that’s where you then do collaboration… that’s where you should then have links to the projects, or documentation and so on in separate site collections. There is a place for nested webs, but super deep nested obviously should be avoided with URL restrictions.
HB 8) Content databases should have no more than 5 site collections (some larger ones should be the only site collection in the content db.)
The best example where content databases should have more than 5 site collections is my sites. Especially when you limit the size of your site collections with quotas such as 100MB or 1GB you could fit hundreds into a database, and save on database management. For division portals, document management systems, and ECM this does make sense to go with dedicated databases, but you don’t want to blow out tons of databases in the collab and my site space with a few exceptions.
When I first read the post, I was anxious to hear some new deployment insights, but it was what he wasn’t saying about his standards that I was thinking about as I read it. It’s great to be able to disagree. There are a couple of things I do agree with him 100%… HB 9) All images for a site must be stored in image libraries and not on the file system. Totally agree. Developers do need to learn to dance with SharePoint and not fight it.
In his concluding paragraph he sums it up quite well… “The more consistent your SharePoint environment is, the more maintainable it will be, your admins will be happier, your users will smile…” Standards within an environment are great. It’s so important to have rules to avoid chaos.
No comments:
Post a Comment