Software Application Design Principles: The Definitive Companion

ByGeorges Lteif

1. What are Software Applications?

Viewed from 30,000 feet, a software application is a computer program that processes digital information. It typically consists of three layers:

The no-introduction-needed 3-tier model of traditional software applications.
  • A presentation layer consists of a user interface (primarily graphical, but might also be a command line or API) that allows end-users and admins to interact with the system.
  • The business logic layer (or application tier) encodes the business rules and processes applied to user data entering and exiting the system. Software applications are designed to provide services to end-users. A service can be anything from computing the ratio of two integers to ordering books from an online store. The business logic is the application component responsible for making that service available. It also channels information back and forth between the presentation layer and the data layer.
  • A persistence layer (or data tier): All applications require user, configuration, and software program data storage in a local database. By local, we don’t necessarily mean the same server or data centre, as cloud storage is now prevalent. In this context, local storage refers to data storage explicitly allocated to the application in question. Data can be structured (tables, XML or JSON-formatted) or unstructured (text), and all modern applications must be able to manage both types.

The 3-tier model is popular because it offers several advantages: modularity, scalability, and maintainability. Each layer can be developed and maintained independently, allowing smoother updates and modifications. Additionally, separating concerns simplifies the overall architecture and enhances system reliability.

Part 5: High-Level Solution Design Documents: What Is It and When Do You Need One

2. Limitations of the Business 3-Tier Model

While the Business Logic/Persistence/Presentation layers paradigm for software applications is highly intuitive and was, undoubtedly, accurate in the remote past, it has become a gross and costly oversimplification of the reality of modern software.

A diagram of a modern enterprise application showing the stark contrast between the 3-tier model and what reality presents us with today.
A diagram of a modern enterprise application showing the stark contrast between the 3-tier model and what reality presents us with today.

Software engineers trained in this model tend to neglect other equally crucial aspects of application architecture and design, without which you would not have a viable product. This series of articles aims to rectify this situation by providing an alternative, sophisticated, and realistic view of modern application design.

Drawbacks of the 3-tier model

Below are some of the flagrant examples of oversimplification:

  • Real-world complexity: Many modern applications have more complex architectures involving additional tiers or layers. For example, microservices architecture, serverless computing, and distributed systems introduce new challenges beyond the scope of the traditional 3-tier model. Legacy systems grew organically as more functionality was added over the years, and their architecture is as far from the Business Logic/Persistence/Presentation layers as one could imagine.
  • Security, compliance, testing, and continuous integration: Supporting modules (such as compliance, data encryption, logging, user access and permissions, system integration or unit testing, and many others) that are now integral to modern software design are not covered by the Business Logic/Persistence/Presentation Layer Model.
  • Interconnected Services: The presentation layer is one of many interfaces that expose the application to the outside world. Many applications provide services to other applications, and the role of the UI is relegated to providing admins with a graphical interface. In contemporary applications, services and components often need to interact with various external services, APIs, and data sources. The 3-tier model may not explicitly address the complexity of managing these external dependencies.

This series of articles will take another approach to examining application design, one that acknowledges the shortcomings of the 3-tier model and tries to replace it with a more modern approach.

Application Design Series

Part 1: A New Paradigm for Thinking About Design

Application design, architecture, classic design models, MVC

Part 2: What End Users Want

User-friendliness, accessibility, security, aesthetics, performance

Part 3: A Developer’s Perspective

Modularity, loose coupling, proven design patterns

Part 4: Architecture

Preserving architectural integrity

Part 5: Application Quality Assurance

Extension, Maintenance, Performance

Part 6: A Product Owner’s Guide to Application Design

Extension, Maintenance, Performance

Part 7: A Day in a Product Manager’s Life

Roadmaps, profitability, user satisfaction

Part 8: The View from Operations

Stability, performance, troubleshooting, maintenance

3. Operational Excellence and Application Design

Operational Excellence, the central theme of this website, is defined as an organisation’s ability to steer its departments, products, and people effectively towards its vision.

For example, a mature and lucrative product has grown too expensive to run on-premise and requires redesigning to become more cloud-friendly. As with any transformation initiative, immense challenges can lie ahead. These challenges can be exacerbated by an antiquated view of technology and technical product design, leading to underestimating the effort and risks involved.

But this is not only about rare and expensive transformations. It’s also about the daily activities of software engineers. In the not-so-distant past, programming skills and business knowledge were enough to get most software developers through their day. Today, the complexity is so much more that gaps between performance expectations and the reality on the ground have become so significant they can’t be ignored.

What this series of articles aims at is offering multiple views, each from a slightly different angle, of a complex system where so much ingenuity, skill, and knowledge has been focused. It is like learning about the human body, described in terms of its constituent subsystems.

We hope these articles will allow software engineers to get closer to their work and become part of the drive to operational excellence without the frustration generally involved in performing a complex task effectively and efficiently.

Principles of Operational Excellence in Software Development