Software design that separates an application into several different "tiers" which each perform a specific range of functionality, and communicate to the adjacent "tiers" when other functionality is needed.  Communication to adjacent tiers is done via an ApplicationProgrammingInterface (API) which describes how to use the functionality, and which could continue to work the same way for adjacent tiers even if a different program  was swapped in at any particular tier.

Tiers might include:

User interface (always at one extreme end of the "layer cake") - also called presentation layer - such as Web browser; GUI application for Windows, Mac, or X-Windows; dumb terminal; WAP enabled cell phone; voice synthesis plus keypad presses for telephone service.

Data storage (always at the opposite extreme end) - such as a database management system or file system.

Business logic (always between the two extremes) - software that uses the data storage tier's API to persistently store, retrieve, update, or delete data without having to know the details of how the storage system works internally; and that uses the presentation layer's API to provide information and prompts to the user, and to receive commands and information from the user, without having to know the details of how the display mechanism works; and that processes data according to the requirements of the task or business at hand, such as providing appropriate discounts to particular customers, showing today's to-do list sorted by priority, or collecting votes for which Wiki pages are too verbose.

The above is a three-tier architecture.  If the business logic is handled inside the database - for example, with Java classes run inside the Oracle 8i engine - and the presentation is handled by a separate program - such as a Web browser - then there is a 2 tier system.  Or if the business logic and presentation are handled by the same program - such as a corporate internal Windows application written in Visual Basic and running on desktops - while the data is stored in a separate SQL Server database - then this would also be a 2 tier system.

There might be an additional layer between the business logic and the storage.  For example, ScottAmbler (http://www.ambysoft.com) suggests storing information in rows inside a relational database which uses SQL, while having a layer that provides software objects (in Java, for instance) to the business logic.  The new Java version of the ArsDigitaCommunitySystem has a persistence layer which initializes storage according to metadata templates.  The Webridge platform stores data in SQL Server rows but provides the data to the rest of the Java runtime as Java objects, which are lazily loaded into a caching proxy as needed.

There also might be more than one layer of business logic - one layer to perform underlying services, such as adding a customer or printing a receipt, and other of business methods that call on those services, such as updating accounts receivable by printing statements for all open accounts and also generating graphs of receivables aging for display by the presentation layer.

To avoid the complexity of counting each tier, the generic term "n-tier" applies to any system with three or more tiers.

The tiers may be run on multiple machines for scalability, but could be logically separate software all running on the same box.