Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2009/09/29/sharepoint-standards-ndash-indeed-context-is-important.aspx
You know, it was a year ago next month that I started getting really active in the SharePoint community. Going to events, joining twitter, blogging, speaking at SharePoint events, and organizing a SharePoint Saturday. It’s been a busy year. I can honestly say, it has been one of the most rewarding years from a technology growth standpoint that I have ever had. I would still be banging my head against a wall trying to figure out what “Unknown Error” meant if it weren’t for this past year.
Also in this past year, I have had the rare distinction of being the focus of not one, but two of Joel Oleson’s blogs! How many of you guys can say that? The first being SharePoint Designer – More than a Maybe and now his latest blog entry SharePoint Best Practices – Context is Everything.
I think Joel has the best intentions, however, in Joel’s latest blog he did take some things from my blog post 10 SharePoint Deployment Standards out of context. Joel seemed to treat my blog post as if I were promoting “best practices” which is not the case at all. I did not say that the standards were “Best Practices” or even standards that everyone in the world should follow. They are the standards that we developed for our organization, and I even explain why we follow these standards. They may not fit every organization, and I hope I make that clear. If I didn’t, then I’m doing something wrong with my blog.
I guess the other part of Joel’s blog that irked me was his statement:
“Just make sure that guidance you are getting comes from solid experience and is based on the right assumptions.”
This seems to indicate that my experience may not be solid, and granted I do not have the years of experience that Joel or many others have. I do, however, have solid real world experience and I’m careful to vet most of the information I post with some of the super talented MVP’s I know. I’m not exactly flying blind here. I also come with the unique perspective of a architect/admin/developer who has to maintain these sites and applications after a consultant has left. I do believe that lends even more credence to some of my insights.
Let’s take Joel’s statement that there is no “one size fits all” in SharePoint. It’s true that it’s hard to nail down Best Practices and there are a lot of shades of grey out there, but in some instances there ARE best practices, and they should be followed when possible.
Let’s take a fairly common argument that has strong opinions on both sides and apply a real world scenario to it. Site Definitions… I recommend for our organization that any firm that comes in and does work for us leave us with a deployable site definition using feature stapling for the features. Joel (and many others) feel that “custom site definitions and custom site templates really aren’t required for most collaboration environments which I personally find are the most common deployments.” I totally agree! In fact, I said as much in my blog “Now, I understand if you are manually creating some Team sites or some other minor site in SharePoint it would not make sense to create a Site Definition all the time.” The context of my blog is outside consultants coming in and doing work for your organization. My argument is that if you are bringing in a consulting firm to develop a site or application for you then they better leave you with a site or application that is completely deployable, upgradable, and moveable! Period. How can you argue with that logic? And the same argument applies to workflows IMO. You may be thinking, “okay, but that is still not a Best Practice ALL the time.” True, and I never presented it as such. However, there ARE some Best Practices you should follow always 100% of the time! For instance, you should ALWAYS deploy your custom code as features in SharePoint. Doing so provides many benefits including maintainability and security because these customizations can easily be turned off and on as needed. Get that one tattooed on your arm and stop manually copying your code in the 12 Hive.
I believe the level of an organization’s standards is directly related to how seriously an organization is using SharePoint and the talent of their staff. If you are only using SharePoint for MySites, Team Sites, Document storage, and other internal collaboration then maybe you can afford to be a little more “lax” on your standards. Maybe you can allow Betty from accounting to fire up SPD and create a simple workflow to send out some specially formatted emails. Why not? Maybe your technical staff does not have the knowledge or experience to develop custom Web Parts or Workflows. Maybe you don’t want any custom code deployed on your farms? Well, in those cases you’d pretty much have to use SPD.
However, let’s say you are a multi-billion dollar company (we are). Let’s say you have multiple SharePoint Farms, multiple WFE’s, and let’s say you have customers logging in to your farm to utilize business critical SharePoint applications. Do you still want Betty from accounting logging on to your severs and playing with workflows? Even if you have fully developed and tested a SPD Workflow on a test server you still have to manually duplicate it in production which increases the chance of user error. Think of the terror that could happen if a user accidentally forgets to set the Workflow up to fire when an item is created and instead sets it to fire on an item change??? (I should know, I did that once…. Once…) I can give other examples for the other items I listed as standards. I deal with solid, real world experience everyday, and we have to deal with the mess when consultants finish a project and leave the organization (no offense to my countless consulting friends). I’m there, maintaining, debugging, and updating. It better be up to our standards!
My understanding of “Best Practices” and “Best Standards” comes from my experience and from conversations with the most freaking brilliant SharePoint MVPs I have ever met and there ARE Best Practices and Best standards out there. The question for your organization is whether or not it is worth the effort to implement. Do you want to just “get by” or do you want to have a world class SharePoint environment that is consistent, stable, and will stand the test of time? Regardless, everyone should find out the best standards for their organization, document them, and stick by them. Real world experience has taught me that much.
Families in Germany who are facing divers health problem, such persons can buy drugs from the Web without prescription. With the market flooded with divers web-sites selling sundry medicaments, purchasing medicines from th WEB is no longer a trouble for common man. Certain medications are used to treat infections caused by dental abscesses. Of course it isn’t all. If you’re concerned about erectile soundness problem, you probably know about Xenical and Hoodia. Probably each adult knows about Garcinia. (Read more PhentermineXenical). The symptoms of sexual health problems in men include improbability to have an hard-on sufficient for sexual functioning. Certain medications may add to sex drive difficulties, so its substantial to cooperate with your soundness care professional so that the prescription can be tailored to your needs. Preparatory to grab Levitra or other preparation, speak to your pharmacist if you have any allergies. Talk to your soundness care provider for more details. Preparatory to ordering this remedy, tell your doc if you are allergic to anything.