SharePoint Best Practice: Architecture Design and SharePoint "Solution Sites"

While working on my first large scale SharePoint deployment I was invited to meet with a team of people collectively called the “solutions group”, a group described to me as developers who were looking to build business solutions based on the SharePoint platform. This sounded like an excellent idea, I agreed, and later that day I walked into a room with 4 or so developers.

To break the ice I threw out a couple of questions to kick start some chat, you know, things like “What language was your last ‘Hello World’ written in?”, “Where do you stand on the whole C# versus VB.NET decision?” and “Ever tried writing directly to the .NET Intermediary Language?”….For the first time in all my years using such a technique, things remained icy. I decided to step back a little by asking the following very simple question “So, what sort of development do you do?”, to my surprise the answer that came back was “FrontPage Development”. Now, this sounded a little like an oxymoron to me, and I had to quickly decide if they were making a joke or deadly serious. Fortunately for me, I decided to treat it with a serious looking face, saying in response “Great, it has an excellent…umm….errr…..IDE!”.

Anyway, to cut a long story short, over the next hour I was completely blown away by the “Applications” they had “Developed” using Microsoft FrontPage and Windows SharePoint Services. These went well beyond the SharePoint “Nifty Fifty” we recently released, making extensive use of Web Part connections and the DataView Web Part. The applications they developed were targeted to meet specific needs that had been identified by the business, in some cases replacing existing systems. These systems were either lacking in functionality, written on legacy platforms or simply needed to become "Web Enabled".

Leaving the meeting I started to think more about these solutions and how they should be supported on the SharePoint Enterprise architecture. The default option of course would have been to do nothing, simply create the sites on the existing dedicated Windows SharePoint Services farm, however something didn’t feel quite right. After some thought and discussion it was decided that in fact we should be creating an additional dedicated Windows SharePoint Services farm with the sole purprose of supporting just this type of site, sites we gave the label "Solution sites"

The reasons we did this are as follows:

1. Capacity Planning. The capacity models for “Solution Sites” are very different to those of an ordindary team site. For example, an organisation typically has many, many team sites, each with just a handfull of users, however there are likely to be many fewer “Solution Sites”, with each instead likely to have many users. We needed to ensure we could efficiently scale both environments based on their usage, something only possible with the introduction of a dedicated "Solution Site" Windows SharePoint Services farm.

2. Customisations. During the meeting, the solutions group asked how they could introduce custom web parts. One of the key parameters of the SharePoint project was to limit customisation, this included custom web parts, thus keeping costs (upfront and ongoing) to a minimum. We knew that additional custom web parts were going to be needed in the future, as the platform matured, but we hadn’t yet put in place any methodology for their introduction. What we did know however, was that introducing a custom web part was going to be HARD, with lots of hoops to jump through to ensure ongoing reliability and performance. With the emergence of the requirement for "Solution Sites" came a case for providing a “slipstreamed” methodology, one that allowed custom web parts to be introduced quicker. To do this without comprimising the "Standard" implementations of WSS and SPS also meant we would have to introduce a new dedicated Windows SharePont Services farm, one running initially in it's own seperate Application Pool, but longer term, moved onto it’s own hardware.

3. Service Levels. Since “Solution Sites” are delivering on a specific business requirement, they are likely to also have some specific service levels. By splitting them out onto their own dedicated Windows SharePoint Services farm we gain the greatest possible service flexibility. Such service levels may even extend to each site having its own dedicated SQL Database.

4. Administrative Policies.  The standard dedicated WSS farm will likely have different adminstrative policies. For example, depending on your oragnisations requirements, FrontPage might be turned off, and Self Service Site Creation turned on. Both these settings would be incompatible with the concept of a “Solution Site”, which by definition needs FrontPage and whose introduction/creation will most likely be restricted and centrally managed.

Based on all of this, another Virtual Server was created to host the additional dedicated Windows SharePoint Services farm.

What's the moral of the story? Where is the "Best Practice"?

Well, when you are sitting down to design your next SharePoint architecture it might be worth spending a little time going through this concept of a “Solution Site” and thinking about how best such sites might be supported. It's much easier to do this upfront, than to try and retro fit your architecture after a "Solution Site" emerges organically, and they will!

In at least one customer I have visited, much time and effort would have been saved if they have created a dedicated Windows SharePoint Services farm that was dedicated to just a single “Solution Site”. It had that many users, that many customisations and was that important to the business, that it deservered to be treated not as team site, but as a Enterprise Scale Business Solution.

As more and more customers create solutions like this, us consultant types need to be aware that Team Sites aint just Team Sites, and it's a trend that is only going to become more and more common as the platform incorporates more and more features with V3 and beyond....

 For the previous “Best Practices” in the series:
SharePoint Best Practice: Start with just one portal
SharePoint Best Practice: Reserving "Friendly" Top-Level URL's in the Portal
SharePoint Best Practice: Locking down the Portal Database
SharePoint Best Practice: Creating a dedicated Windows SharePoint Services environment
Best Practice Posts

Comments

• Anonymous
  December 18, 2005
  hi,
  
  links doesn't work.
  
  cu
  tosc
• Anonymous
  December 28, 2005
  So...I see you have a smattering of Best Practices that you have compiled now...I take it there are no theories or concepts out there that help an organization define what is the best approach to their SharePoint implementation? I like what you have so far but I am looking at things like "Should I create top level sites that mimic our organizations divisional breakdown or departmental or should we look at a project breakdown or all three...", "what are the recommended ways to handle security and how best to go about role creation", and "is it best to guide or limit growth of team sites and how to do that vs a free for all on team site creation". I will keep tuning in and look for more comments. Thanks for the great information and additional links to resources.
• Anonymous
  January 05, 2006
  Hi Tim,
  
  Unfortunately there is not real "Best Practice" that cover some of the things you are asking, as it really depends on the customer.
  
  You have given me a couple of things to think about, let me stew on these for a bit and then I will put together a couple of additional posts....stay tuned.
  
  Daniel
• Anonymous
  June 16, 2009
  PingBack from http://topalternativedating.info/story.php?id=13403