Knowledge Nugget: What is a Layer in Software Architecture?

Read this knowledge nugget if you want to learn what a layer is in Software Architecture, how you can use it, how the concept works and why you would want to use it.

Based on [QinXingZheng2008] was Edsger Dijkstra one of the first discussing how to use layers in the construction of large scale systems. Layers are often used in the construction and description of software systems. Think of

  • the famous OSI Model as an abstraction of the network protocol stack,
  • the layering we typically build into software applications, such as web layer, business layer, persistence layer, etc.

A layer is a logical grouping of functions with similar concerns, independent of where it is physically going to be implemented.

Typical layering of a web-based application
Figure 1 - Typical layering of a web-based application

It is important that layers have a clear purpose and a clear interface to each other. If you build software based on a layered model it is important that layers do not randomly access functions in another layer, but only make calls to the layer next to it through a defined interface.

This is to decrease coupling, increase maintainability, and provides encapsulation and modularity on architectural level.

Figure 1 shows an example of a typical layering of a web-based application and illustrates how layered models work:

  • Client Layer – A web browser, or an other client. It is the originator of a request.
  • Static HTTP Layer – The static HTML content of an application.
  • Dynamic HTTP Layer – Sometimes called the web presentation layer. It implements the dynamic portion of a web-application.
  • Business Logic Layer – This is where all the business logic – except for the user interface (UI) specific logic – is implemented.
  • Persistence Layer – This is where all the data access logic is located (create, read, update, delete).
  • Data Layer – This represents the database.

The way it works is that the request is coming from the left – the Client Layer. The layer on the left must pass it on to the layer on the right, for example the Client Layer must pass its request on to the Static HTTP Layer. The layer on the right either responds to the request itself and passes the result back to the calling layer, or processes it as far as it is concerned (partially or not at all) and passes it on to the next layer on the right.


[pra2006] pranshujain. 2006, “Layers and Tiers”, Software Architecture and Content Management [online] available at

[QinXingZheng2008] Qin, Z., Xing, J., Zheng, X. 2008, Software Architecture, Zhejiang University Press, Hangzhou

[TanSte2002] Tanenbaum, A.S., van Steen, M. 2002, Distributed Systems, Principles and Paradigms, Prentice-Hall, Upper Saddle River

[Wikipedia2010] Wikipedia. 2010, “OSI model”, Wikipedia [online] available at

Copyright © 2010 Michael Pichler


2 thoughts on “Knowledge Nugget: What is a Layer in Software Architecture?

  1. Hi Michael,

    Thanks for this posting and your blog generally. I just wanted to comment that there are a couple different interpretations of “layer”. One is as you describe.

    Another, described in books like Documenting Software Architectures (by the SEI/CMU), says that layers are a grouping of modules (i.e., not runtime elements) that present a virtual machine interface to layers above it. They distinguish layers from similarly structured runtime elements they call tiers.



    1. Hi George,
      Thank you for pointing this out to me! It indicates to me that I should make my post more clear. Maybe it is the sample I picked that created the confusion.

      I entirely agree with the view you have described. The term “tier” distinguishes physical or logical runtime elements. What I wanted to explain is that
      • layers group logical functions (modules) with similar concerns,
      • have a clear purpose, and
      • define an interface to the layer above.

      I wanted to explain this concept with commonly used denominations for tiers in the web-centric IT world, which may have crated the confusion. I have a post on tiers scheduled for next week, which would have most likely clarified it.

      I typically use layers as a design element to structure an application logically from a technical point of view. Which tier those layers will be placed into is an architectural decision that is primarily influenced by the non-functional requirements.

      Thanks again for pointing this ambiguity out to me. I will correct it. If I have misunderstood something in your comment please let me know.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s