Layers is a classic architectural pattern for 'application architectures'. That is, Layers is normally thought of as a build-time strucuturing technique for building an application or service that will execute in a single process.
The problem is that there are many variations on the layers pattern. For example, the following patterns all involve using layers in software architecture:
Martin Fowler also discusses layers: http://martinfowler.com/isa/layers.html
One huge problem with all of this is that no one agrees exactly on what a 'layer' is. For example, some layering schemes have very little relationship to the runtime. Others confuse layers with a 'tiered' runtime architecture where the various layers are not only split by build-time packaging, but by running in different processes and possibly different nodes at run time.
So in this work we want to clearly separate the idea of a 'tiers' from a 'layers'. A tier is a structure for runtime component interaction that implies nothing about the construction of the build time. For example, we might have a 3 tier system composed of a web browser, web server/asp pages, and database. Each tier runs in a different process and in many systems different nodes. In this case, the majority of the component are off the shelf and only the asp pages are part of the application.