3-Tier Software Architecture Tutorial For Non-Developers

Whether you’re building a simple app to display pets available for adoption or a complex app that generates insurance quotations, you can use the mental model of the three layers of software applications to visualise the system architecture.

This mental model can help you visualise a software application’s design and implementation as a non-developer. Such an understanding has numerous benefits, including allowing you to:

• Assess better the technical feasibility of enhancing existing features or creating new ones
• Provide more accurate high-level estimates for new requirements
• Improve the quality of your business and functional requirements
• Determine what type of testing would give the most reward for the least effort

Here are the three layers of software applications:

1. Presentation layer to display information
2. Business logic layer to enforce business rules
3. Data layer to store information

Let’s use the example of viewing pets available for adoption to illustrate the concept of the three layers of a software application. Here’s an image of the pet adoption app I’ve built:

In our pet adoption app example, potential adopters see the presentation layer when viewing pets for adoption on their mobile device. The business logic layer controls the types of pets to display. The data layer stores the details and images of each pet available for adoption.

1. Presentation layer to display information

The presentation layer is the screens with which users interact. It is responsible for the structure, styling, and interactivity of apps.

For example, a software application’s presentation layer may control the colour of headings for each pet’s breed and the ability to click on a pet to view more information.

The presentation layer is not responsible for enforcing business rules or storing data. It only communicates with the business logic layer to fetch information to display to users.

2. Business logic layer to enforce business rules

The business logic layer implements the business rules in a project.

For example, a software application’s business logic layer may determine that the application must show only 3-year-old Labradors to a specific user based on their preferences.

The business logic layer is not responsible for displaying information or storing it. It coordinates the end-to-end process. It communicates with both the presentation layer and the data layer.

3. Data layer to store information

The data layer stores information.

For example, a software application’s data layer may store each pet’s details and images.

The business logic layer accesses it to fetch (read) or save (create, update, delete) information. It doesn’t communicate directly with the presentation layer.

Notes about the mental model of the three layers of software applications

Understanding Software as a Service (SaaS) applications

A modified explanation of the three layers of software applications can also help you understand applications built to provide software as a service. In this scenario, you can think of the presentation layer as the specific format in which the system application returns results, perhaps by exposing Application Programming Interfaces (APIs).

Comparison between the three layers of software applications and the multilayered architecture

The three layers of a software application closely resemble a specific software architecture pattern know as the Multilayered Architecture.

This semblance can be both a hindrance and a help. If you’re using this mental model when interacting with developers, let them know at the start that you’re using it as a mental model to understand the design of the application rather than a technically correct term.

Using the mental model of the three layers of software applications to help you better understand your project

The three layers of software applications is an abstraction of several typical architecture patterns used in software development. It provides a useful starting point for understanding how the project you’re working on is structured.

You can expand on this understanding depending on your responsibilities on your project. For example, this understanding may be sufficient for a subject matter expert whose duty is to provide context on the business process. In contrast, a technical tester writing integration tests may need to know that the application uses the microservices software architecture.

Have you ever used this or other mental models to understand or explain the design and implementation of the software applications you’re building?

Previously published at https://arjivan.com/3-layers-software-applications-non-developers/