TFS Areas, Optimal Definition and Configuration

Question

Having recently migrated to TFS 2010 I was wondering what the best or most widely accepted definition or configuration is for an Area?

The only useful article I can find online is this one and is what I would have assumed to be correct. However it got me thinking if any of the following is indeed more widely accepted.

• Areas by business functionality
• Areas by technology
• Areas by system layer
• Areas by physical or geographical location

Answer 1

Areas in my opinion is a grouping mechanism, with Areas you can group your wortitems in any kind you want.

I think everything which fits to your development process and or make you more productive is ok.

All of your items on the list are valid types of areas, I saw all of them in projects.

But too deep hierarchies are not really helpfull, because if you create a workitem you than you have to choose/select the right area.

Answer 2

It really depends on the product/project you 're building, I suppose it was made available as a general-purpose placeholder which can get its meaning from the context of the team & the team mission.
I can imagine projects, where ignoring it on the grand total, would also be a perfectly acceptable solution.

Our initial TeamProject structure in fact did ignore Areas for our flagship product we construct in a Team Collection. This resulted in a reporting nightmare, since we needed it on a platform-level (TeamCollection), rather than a distinct part of it (Team Project). When we realized the problem, we went searching & found this article, which made us change course: we are now using TFS Areas within one single Team Project & found what fitted best to our situation.
In our universe Area = a distinct release line within the platform.