Wait! Do not forget to implement SharePoint!

21
Sep
2009

Fred Yeomans

Last month’s column drew quite a bit of interest and many comments here and elsewhere. Most were even positive, and those that were not were at least constructive. Before getting into this month’s topic, I wanted to revisit some of the things people said.

One valid point that was made was that much of what I said last time did not apply only to SharePoint, but to pretty much any implementation of an enterprise software product. While I agree with this, I also think the SharePoint is a little different in that it is a less specific product than many others. When you implement a practice management system, or document management system, or an accounting package, you typically already have at least a high-level understanding of what you want to achieve and what success looks like. This is not necessarily this case with SharePoint – I have seen many organizations charge headlong (or drift aimlessly) into a SharePoint deployment with no clear understanding of the high-level business value.

Another common comment theme was along the lines of “nothing new here”, and “we have said this for a long time. ” This is true – there is nothing new here at all. Unfortunately, there are still large numbers of organizations (and consultants) out there who still stumble over these same fundamental hurdles.
 
Now on to new stuff. This month I want to look at the other side of the coin, so to speak. Let’s assume that you have done things right and have gone through the business analyses and have properly defined what you want to accomplish, what the business value is, and have even decided that SharePoint is the right technology for the job.

Now what?

This may seem blatantly obvious, but even so it is the source of many failed (or at least not completely successful) SharePoint projects. As I have said before, one of SharePoint’s strengths is that it can be installed and set up with minimal experience and forethought, and you can very quickly have a site up and running where you can start adding web parts and lists and customizing and having all sorts of fun.

This, while fun, is of course not the right way to do things. It seems that a lot of organizations, having decided to “implement SharePoint” forget to actually implement SharePoint! They set up SharePoint in a somewhat ad hoc way, and then let it just grow organically (or hope it will). This is dangerous on so many levels.

SharePoint is just one piece of the puzzle, and in order to have an effective, scalable, maintainable SharePoint infrastructure requires an understanding of many moving pieces, including but not limited to:

• Initial deployment topology: How many servers do we need? How many WFEs, database servers, etc.
• Geographic distribution: How are your users distributed? Are they all inside the firewall? How to you want to manage your servers (centralized or distributed)? What are the bandwidth considerations?
• Authentication & Identity: How do you want to authenticate? Do you have AD? Do you need to tie in user information from other systems?
• Integration: What are the line of business (LOB) systems to which you need to integrate?

And there is much more. This requires a team with knowledge of many systems, including SharePoint, SQL Server, AD, networking infrastructure, and more. I say team, because it is difficult for one person (or me, anyway) to have deep knowledge of all of these areas.

While it is not necessary to start out with a complex infrastructure of lots of servers (remember I said last time to start small and grow), just as it is important to have a clear roadmap and vision of how the solution will grow, it is important to start out with a clear understanding of how you can grow your infrastructure as your solution grows.

It is also important as you plan your SharePoint environment to understand how you will do development (both content development and solution development) within this environment. Will you be doing actual development (coding) or will you only be doing customization and content creation? Will you have multiple environments (development + staging + production, etc.)? What tools do you need and who will use them? How do you deal with updating solutions in your live environment?

As with analysis of your business needs and success metrics, taking the time to lay all of this out upfront will help avoid nasty surprises later on, both in terms of unexpected scaling costs, and in terms avoiding “dead ends” and the need to tear down and rebuild infrastructure.
   
So, when you implement SharePoint, do not forget to actually implement SharePoint!