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?

3 Answers
3

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.

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.