Layering represents an ordered grouping of functionality, with the application-specific functionality located in the upper layers, functionality that spans application domains in the middle layers, and functionality specific to the deployment environment at the lower layers.

The number and composition of layers is dependent upon the complexity of both the problem domain and the solution space:

• There is generally only a single application-specific layer.
• Domains in which previous systems have been built, or in which large systems are composed in turn of inter-operating smaller systems, there is a strong need to share information between design teams. As a result, the Business-specific layer is likely to partially exist and may be structured into several layers for clarity.
• Solution spaces that are well-supported by middleware products and in which complex system software plays a greater part will have well-developed lower layers, with perhaps several layers of middleware and system software.

Subsystems should be organized into layers with application-specific subsystems located in the upper layers of the architecture, hardware and operating-specific subsystems located in the lower layers of the architecture, and general-purpose services occupying the middleware layers.

The following is a sample architecture with four layers:

• The top layer, application layer, contains the application specific services.
• The next layer, business-specific layer, contains business specific components, used in several applications.
• The middleware layer contains components such as GUI-builders, interfaces to database management systems, platform-independent operating system services, and OLE-components such as spreadsheets and diagram editors.
• The bottom layer, system software layer, contains components such as operating systems, databases, interfaces to specific hardware and so on.

A layered structure starting at the most general level of functionality and growing towards more specific levels of functionality.