Load balancing and scalability

The immediate advantage is load balancing and scalability. Rather than requiring one server to handle all transactions, you are separating the load per server over a larger hardware or network area. Of course this implies definite advantages over upgrading of hardware and network resources.

Separation of Presentation and Function

The separation of functional behavior calculations and algorithms from their visual presentation is important in two ways.

First, it becomes easy to change visual presentation in isolation from tested functionality. You can change a display from a grid representation, for example, to a graph. You can support different classes of users with different views of the same data, providing each with a view appropriate to their needs. In fact some users will not need visual presentation they might be other programs consuming the data.

Second, with the sort of separation we have been talking about, the client computer need only be powerful enough to perform the rendering tasks and make requests of the server. Perhaps you've seen an intranet application in which complex functionality was implemented on the server, allowing users to have rich visual access anywhere they have access to a web browser and the hosting server. In fact, this scenario is enjoying surging popularity right now, and Windows DNA supports it quite well.

It's not inconceivable that a PDA (personal data assistant) could be a thin client (where minimal processing is performed on the client itself), even while a very powerful workstation (a fat or rich client) connects to the same application logic layer to offer its user a different, richer view of the data. Regardless of the presentation, the code on the server that implements the application logic remains the same.

Optimization

Any programmer who has profiled and optimized an application has been surprised by the performance bottlenecks found. As each problem is resolved, new issues are uncovered. So it is with a distributed system. Each subsystem has its own unique challenges, each with an optimal solution.

These subsystems exist in monolithic and client-server applications, but there they are bound up with each other. With an n-tier architecture, it becomes possible to isolate each and make appropriate adjustments.

In the simplistic case, you can throw expensive hardware at the servers. The data tier needs high-powered servers with redundant disks. Redundant disks are important for high availability, but are quite expensive. There are ways to write application logic tier components, so that that tier, while it needs powerful machines, does not need to have redundant disks. Because the tiers are distinct, the machines that support the application logic may be less expensive than the computers hosting the data services tier. The client can be an inexpensive computer.

At a more sophisticated level, software can be adjusted for the needs of each tier. Servers are tuned for background processes, having little or no interaction with a foreground user. The exact opposite condition exists on the client. Relational databases involve complicated mixes of disk and memory performance, while the application logic tier operates largely in memory and prefers CPU and network I/O performance. If these functions were housed on the same machine, some compromise would have to be reached. Overall performance, in consequence, would be less than the ideal case for each subsystem.

Parallel Development

A monolithic application has few opportunities for parallel development. While multiple teams can be spun off for different parts of the application, there are so many dependencies that each progresses at the pace of the slowest.

Client-server improves the process somewhat. The client team can work, at least initially, in isolation from the server team, using a very limited stub application in lieu of the server.

Unfortunately, the server possesses all the interesting logic. Recall that the functions of the application logic tier are generally implemented as stored procedures and triggers in a client-server application. The client quickly reaches an impasse, awaiting interesting results the stub cannot provide. The server software, in turn, will not be fully challenged until it is tested against the sort of interesting requests and conditions that arise only when multiple, fully-featured clients begin accessing it. The situation is even worse if application logic is split between the client and the server. In such a case, each team can make limited progress without the other, and development resembles monolithic application programming.

Things are better in n-tier architectures. There is still the need for stubs at each level, but now the stubs are selectively removed as each tier makes progress. It is a more finely tuned sort of development. If the application tier progresses ahead of the data tier, clients can still resolve more difficult issues as they are going against the live component. The underlying data is still stub data, so the client cannot be fully tested, but the client team can work on more challenging issues than if they had stub logic and stub data.

In fact, as the world moves to n-tier architecture as the model for large and robust systems, development will be continuous and some programming teams will have no knowledge of one another. If the tiers communicate through open protocols like HTTP and open formats like XML, new client applications can be developed for existing servers without access to the server software programming team. Similarly, servers may be upgraded or data migrated without upsetting clients. The key is clean interfaces between the tiers.

Code reuse

By separating and isolating application tiers into the n-tier model, you can promote code reuse more readily and more from availability standpoint. You can also have different teams work on different areas and house commonly used or Enterprise used objects into a separate repository that can be connected to and used by all. Moreover you can purchase a well-defined module that solves a problem and combine it with other components to solve larger problems.