SharePoint Architecture - How do you do it?

Question

I'm interested to see how different people organise their SharePoint installations in terms of Web Applications, Site Collections and Sites.

Additionally, has anyone changed their architecture as they migrated between Sharepoint versions?

For starters here is how we have done it where I work.

We started off with SharePoint 2003, with the assistance of a consultancy, and organised it as follows:

• http://intranet web application. This was viewed as a SharePoint Portal Server application housing our corporate wide information, search etc.
• http://teams. This was viewed as a Windows SharePoint Server application, housing all our team sites. Each team sites was a single Site Collection, generally only containing a top level site.
• http://mysites. Obviously My Sites.
• http://sandbox. A web app for playing around with sharepoint functionality, separate from any real content. This web app also uses a different shared service provider so that more features can be tested out.

When we migrated to Office SharePoint Server 2007 we didn't make any radical changes to the architecture - we just migrated the data between the two installations.

I have never been convinced that the distinction between the SPS and WSS functionality was valid, and thus that we needed to split out our corporate and team level site collections into two web applications, although I am not sure we suffered anything more than a bit of confusion as a result.

If I were setting up from scratch (which may be the case if I get a green light to upgrade to SharePoint 2010), I think I would merge the intranet and teams web applications, and create site collections for each department, and organise the teams at this level. Anything that would support aggregation of content at the departmental or corporate level would be great!

So - how have you done it, and how would you change things if you could start over?

Answer 1

I'll second what James said and add to it. With 2010, authentication methods aren't as important a consideration because you can have multiple authentication types associated with a single web app through Claims Based Authentication.

Security may still be a consideration when splitting out your web apps and site collections though. The department sites, for example, do you want the administrators to have Site Owner functionality, Site Collection Admin, or adhere to a web application security policy? To me, it is overkill to give each department their own web app. I can see giving them their own site collection though -- especially if they have a lot of content and should have their own Content Database.

Same thing for the team sites. If you plan to use them a lot, giving them their own web app could be good for performance reasons. But putting them all in a single site collection within that web app may be just fine (depending on how large they will grow). Ideal size for a Content Database is <100 GB. So if the team sites will outgrow that, give them their own site collection and content database. Smaller content db's restore more quickly. Also, keeping the content databases to the same type of data (Team Site, Publishing Site, etc.) will cause SQL server to run more optimized.

Answer 2

The main defining point in whether to separate out web applications is (well, was in 2007, that's probably changed in 2010) authentication methods - are my users all internal on AD or are there a bunch gonna be authenticating via FBA, and that kinda stuff.

Site collections separation is down to permissions requirements really.

I guess it depends on every project but generally from 40,000 feet that's how I start to view it, then narrow down to each requirement (started with authentication and permissions) to see how to further define the information architecture.

Answer 3

Ditto the other thoughts here regarding authentication methods. I separate Site Collections mostly on the requirements of things like:

• Security model (Site collections are a good boundary)
• Quotas and storage capacity.
• Needing the Publishing infrastructure

I would still use separate web applications for:

• Process isolation if using custom code
• Control over Content Database usage