In development we understand a tier as a "level of responsability" abstraction.
Such level of responsability groups concepts together to provide a coherent semantical view of reality, or at least something similar to reality.
In such sense, the so called, 3-tier model or n-tier models are just different implementatios of that concepts.
A good example of a tier follows the jerarquical model where responsabilities are carefully addressed to the appropiate people. For example, a common bussines has Comercial, Marketing, Systems, Development and Test department (for example), which represent tiers of bussines. That way, reponsabilities are clear, Development provides the product, Testing test it, Marketing promote it and Comercial sell it, all that while systems keep the infrastructure running (is just an example).
This methaphore was first approached with the 3-tier model, where three tiers are identified. Usually this tiers are Database Abstraction Layer, which is in charge of communication and abstraction over the database, Business Rules Layer, which holds the rules that describe the bussiness process and User Interface Layer which abstracts the interaction of the user with the system.
That way, we have roles for the responsabilities of each layer, so that if the user needs to interact with the system he will communicate with one layer, not mess up across the hole system.
N-tier represent an evolution of the former concept by using more tiers to address especific needs. Usually user interface layer and database abstraction layer are left untouched, as their roles are pretty clear while bussiner rules layer is further refined.
For that, we always take into account the characteristics of the problem as well as the features we want to provide now and in the future. For example, if an application will need to work with smart clients or its foreseen to work with smart clients then business layer is usually divided into a proxy layer and a backend layer, the first routing the calls where they should go.
In the end, what's important is the concept of abstracting reponsabilities among different layers, and centralizing all related operations from a semantical view in the same place.
Note that, in addition, n-tier architecture allows for distribution of those "reponsabilities" among developers. That way, a given team can have responsabilitie over the Database Abstraction Layer while other team works on the Proxy Layer and another one works on the Graphics Abstraction Layer. When a member of a team needs to access the database he look up the DAL documentation and use one of the facilities provided or ask the DAL team to provide with the functionality he needs, so that he does not address directly the database but through the people that better known the design and intrincacies of the database itself.