n-tier architecture benefits

JDBC architectural models
N-tier architecture benefits

N-tier architecture provides the solution developer and the customer with a variety of benefits.
The following table describes the key benefits.

Key benefit			Explanation
	Scalability			N-tier architectures allow scaling of systems beyond the limits of two-tier client/servers. You could implement a two-tier system with a DBMS running on a server with a thousand users. It would be very difficult, however, to scale much higher without using an n-tier technology. The middle tier can funnel thousands of connections into just a handful, reducing the load on the database server. This technique has been used on mainframes for decades (using, for example, CICS).
	Business flexibility			Modular services can quickly be replaced or updated to meet changing business needs. External interfaces can be designed and implemented in a short time frame.
	Technological flexibility			With an n-tier architecture, you can generally swap database engines (minus trigger and stored procedure code) or port your middle tier to a different platform. Simplification of presentation services also lets you implement completely new interface technology, such as voice response systems, kiosks, and Web technology for the Internet, intranet, or extranet.
	Lower long-term cost			You can save money by choosing commercially available components or services, and by replacing only small modules rather than complete applications.
	Higher-quality systems/better match to the business			Core vendor competencies can be leveraged by purchasing specialist services and modules. You can build new modules to support individual business needs rather than whole systems.
	Competitive advantage			With the ability to adjust rapidly to changing business needs, you can develop new products or processes quickly, gaining that extra advantage in competitive situations.
	Reduced risk			Because services may be deployed in small pieces, using a combination of custom development and components from experienced vendors, users are more likely to implement acceptable applications. The risks of unacceptable systems are best avoided by implementing smaller systems in a modular, continuous improvement approach (the basis of most RAD methods).