Ryan McCutchen

Sometimes I think that my experience with SharePoint 2003 is so burned in my brain that is causes me to dwell on topics that very well could be a null issue in MOSS. The concept I was contemplating this week was the option of separating your WSS team sites into a separate web application. In SPS 2003 this was a very common practice primarily because of the separation of WSS and SPS in the 2003 architecture, but in MOSS that distinction is not as apparent or perhaps necessary. Team Sites can be peppered through out your site collection and live anywhere as opposed to 2003 where they primarily resided under sites. This also opens up a lot of different options from an Information Architecture perspective that I would like to discuss.

One thing that vexed me initially, was that the Microsoft Architecture documentation clearly mentions this practice of separating Team Sites in a deployment scenario, and it is still a very sensible pattern. However, maintaining sites on a separate web app or site collection is not really an out of the box solution in MOSS (like it was in 2003). From a usability standpoint, some things need to be tweaked. I pinged several colleagues and discovered that none of them were separating out team sites in their deployments, which got me wondering about how the viability of this approach. Although, separating team sites into a separate web applications can give you several benefits.

Team sites are more adhoc, and well ..."wild west" style in terms of portal governance. They are usually maintained by the business and not IT, and the business has free reign (to a certain extent) over what they do in their team site. My Sites share this model. Team Sites are also very organic in growth, and in many organizations where IT does not audit or control team sites other than provisioning, can tend to become very large high traffic sites with little IT oversight. Separating team sites into separate web applications and a separate app pool from the portal will minimize the risk of this governance model by having Team Sites on a separate SLA (Service Level Agreement) as well as isolation in IIS if things go bad with team sites. This makes sense from a high level architecture perspective to reduce single points of failure, but the reality is that team sites are the real bread and butter of SharePoint, and end users will be in much more of a crisis if their project site is down as opposed a policy in the document center, news or web content, or even enterprise search. So someone looking at the information architecture needs to do careful analysis on the capacity planning of team sites and how that ranks to the portal. Some organizations will be very thin on the "portal" side of a deployment with the majority of users focused on team collaborations while some could be the reverse.....initially. Most groups when deploying a new portal will focus mainly on the governance, design, and taxonomy of the enterprise portal side because that space is really IT's domain - that is where IT will have the control and the capacity to plan. But even if you are not meeting with every stakeholder in the company to determine their department or team collaboration needs (most teams cannot afford the time that analysis would take), do not under estimate the rate at which team sites will grow in your environment. When looking at this from a system availability or resiliency of the environment, you need to consider the practical side of what SLA's are really required, meaning, what functions are absolutely business critical and where do they reside.

I think a downside of this separation whether teams sites are in a separate web application or just all created under the Site Directory is the taxonomy limitation it can create. Creating a separate space for all collaboration to take place can have its advantages, but it can also create usability issues as users now have multiple choices of where to go, and they may not understand the distinction between a team site and the sub site in the portal. For example, say have a publishing site on the central portal available for the IT department that all employees can access, and you also have a team site that only IT users can access to get content internal to the department. Well say your ticketing system is on the enterprise IT site while your system documentation is on the IT team site. Now IT users have 2 separate places to go to do their job, and these 2 places may have different urls and or navigation paths. Is that necessary? With the right permissions model the IT users could see the all employee content and the internal content in department or project sites from the same site. Obviously if each department is it's own site collection than you can have this properly organized with less manual work, but if that is the case then what would be on this separate Team Sites web application? Most team sites can somehow relate back to a department. Otherwise what are users collaborating on?

I'm not saying that one way here is right or wrong, and each method depends on the specific deployment. I would recommend that during the planning phase their is a good amount of time spent on what collaboration means to the organization, and how that is properly blended into the overall taxonomy. If your deployment is small, set a quota on the parent site collection of 25 - 30 gb, and if it gets to close to the quota, analyze what sites are taking the most resources - and scale out to a separate web application if need be , but be cautious of over-architecting a solution and creating more of work around processes for enterprise search and leveraged metadata if it is not required.