One question I often hear is: "How many physical tiers should be designed into an infrastructure architecture."

You have to understand the customer's architectural perspective for the life of the application. Especially for systemic quality analysis.

Reason to increase physical functional decomposition into a higher number of tiers:

1) Massive Performance Scalability &/or Availability needs during the life of the solution (example: minimum = 10 to 20K concurrent users)

Why? Because, with massive scalability needs, a highly coupled presentation and transaction tier can create an amazing amount of brittleness as well as decreased architectural choice to optimize logical tiers as scalability needs increase. While there is a communication penalty by communicating over a network instead of local calls, most enterprise application vendors have found that the rigidity prevents utilizing different scalability tools and techniques for specific logical tier areas (example: vertical scaling, application clustering, stateless load balancing, even grid batch node distribution)

2) Significant adaptability needs in the presentation logical tier

If the presentation tier is expected to undergo a significant interface design during the life of the solution, then having a separate tier makes sense. This further makes sense as client interface systems undergo radical change over the life of the solution. Furthermore, as presentation tier aggregation strategies have been common for the last 5 years, the ability to aggregate multiple business transaction tiers through a unified presentation gateway (whether it's a portal, an MVC engine, etc...) becomes more important. Companies which undergo significant merger or reorganization activities are good candidates for this.

3) Significant adaptability needs in the business transaction logical tier.

If the business tier is expected to undergo significant change during the life of the solution, then having a separate tier often makes sense. An example is a call center staff which wants to keep a consistent visual interface while the business/transaction system might undergo radical change over time.

4) Operational stability for large systems

Having separate tiers creates physical separations of concern where a poor application would develop less of an application impact on other tiers (except for the potential communication latency which are easily observed and diagnosed for root cause analysis). This reduces the impact of memory bleeders (which is big concern to operation teams). Also, separate physical tiers creates a more simple rolling upgrade model (without having to understand the complexity of off lining aggregated tiers).

Good rule of thumb (but not always true): If it's very large, needs to scale much larger in the future and/or logical tiers require significant adaptability, then consider physical functional decomposition and optimization (more tiers).