Software Application Design — Part 1: A Multi-Layer, Multi-Perspective Paradigm for Thinking about Applications
1. Introduction
When discussing application design, most of us will promptly visualize the familiar three-tier model (user interface, business logic, and data layer). The more experienced among us will think of something more involved: a distributed system of web browsers, load balancers, specialized hardware, web and application servers, and database clusters.
I have used the distributed model extensively in high-level design documents and architectural diagrams where I wanted to show what the system was about.
In many cases, however, I quickly saw that more diagrams were needed to portray particular subsystems, functionalities, services, and transaction or data flows. Even when illustrating the architectural structure of the system, the generic distributed system model was underwhelming.
This article will present an alternative view of application design consisting of a multi-layered, multi-perspective approach to understanding the structure of modern software applications. We will call it M2LP.
Before we keep moving, have a look at what topics are covered in this series.
Application Design Series
2. M2LP: The Multi-Layer, Multi-Perspective Model
2.1 Logical Decomposition into Multiple Layers
The M2LP refers to a multi-layer, multi-perspective new paradigm for thinking about application design. When we say multi-layer, we don’t necessarily mean something similar to an onion, where one layer entirely envelops the one beneath it.
Instead, let’s think of a vast Rubix cube, where random blocks are removed from its interior and attached to other blocks with free surfaces, similar to the picture above. Each block of our modified cube represents one component of the application: a web server, load balancer, database instance, network device, logical business unit, process, etc.
Unlike the cube we started with, with its compact and densely connected components, ours has sparsely interconnected ones. This sparsity creates clusters of blocks, which we call components, with dense inter-block connections and sparse intra-cluster connections.
While systems configured in that manner are great candidates for complexity and rarely but indeed display epiphenomena, we cannot call them complex; they are merely complicated, and complicated systems can be understood when analysed with the right skills and tools.
The blocks, components, and connections between them will be our preferred approach to breaking down a large and complicated application into more manageable pieces. Unlike the 3-tier model, this is richer and more dynamic, giving architects the flexibility of modelling real-world applications without losing precision.
2.2 Software Application Design from Different Angles
When preparing solution design documents (or any other technical documentation), I usually find the target audience to be a narrow specialized group, such as senior managers, business analysts, architects, developers, and testers, but rarely all at once.
In cases where the audience is diverse, getting the ideas across becomes significantly more challenging (this is a generic problem in knowledge management). The best solution would be to write a document with one audience group in mind. Terminology, diagrams, and concepts would belong to a well-defined context.
This focus on context is our next driver to understanding software design. Instead of looking at the entire application with all its complexities, we will focus on specific domains, one per stakeholder, trimming down the amount of information we need to examine to understand the design. Our stakeholders are:
Each analysis will cover a subset of components in the system, which we will call view, consisting of a cluster of related components in our modified Rubix cube. This cluster is held together by the necessity of providing services critical for the stakeholder in question.
3. The Anatomy of M2LP
3.1 Stakeholders
Stakeholders are the people who regularly interact with the software and whose job depends on this interaction going well. They all use the system thoroughly, developing, modifying, operating or maintaining it.
There are eight stakeholders we would like to consider: end-users, architects, product managers, product owners, developers, operations, testers, and DevOps engineers.
This list contains most of the profiles we can observe in software development teams today. Some companies have more profiles, others less. However, this variation does not impact how M2LP works. As long as the software is complex enough and distinguishable roles exist, its fundamental paradigm of segregating the view to make analysis easier remains valid.
3.2 Blocks
Blocks are granular pieces of software or hardware making up a component. Working with other blocks, they collectively provide the component’s service.
The diagram above shows a standard setup of server applications we are familiar with. First, a TCP driver handles client communications in both directions. Incoming messages are packaged and placed in a queue, waiting to be picked up by an idle worker. The task manager polls the queue regularly and then tries to find an idle worker to execute the client’s request. Workers typically have access to the database through a data layer. Finally, once the request is completed, the task manager places the response on the outbound queue.
Each element in this diagram is a block, working with the rest to provide a service to clients on the outside. We adopted the convention to use “blocks” when discussing elements at this hierarchy level and with these characteristics. There is no particular reason why this should be the case; it’s just a convenient method of breaking down large applications.
3.3 Components
A component in a software system is an identifiable and bounded piece of software or hardware that provides services to other components in the system.
The boundaries of a component can be as short or expansive as we would like them to be. An example of a component can be:
The boundaries of a block can also be as short or long as we would like them to be. But if boundaries are fluid, can a block encompass a component? How are blocks different? The answer is as follows. While component and block sizes can vary widely, we use the following rules to distinguish between them:
The following section will show a few examples of views with typical components.
3.4 Views
A view is a collection of components providing the services a single stakeholder requires.
We usually like to use three types of views. Although there could be more, these are the most common—first, network diagrams. Second, business architecture diagram, and third, solution diagrams.
Views can share components with other views and, in that regard, are more flexible structures than components and blocks. While the latter two do not change significantly during the product’s lifecycle, a view can see more components added and old ones removed or replaced.
3.4.1 Network Diagrams
A network diagram shows hardware components such as client machines, firewalls, load balancers, database instances, etc. These are very useful in architectural documents to show server machines, locations, network security zones, and any other hardware machines required for the solution to run.
3.4.2 Functional Diagrams
Functional diagrams show the business architecture of the application. A component in this view might be spread across different servers and comprise various sub-applications. It is just convenient to group them when discussing functionality.
The diagram above shows the design of a web application server for an e-commerce website. This could be the same application as represented in the previous network diagram, just from the point of view of business functionality.
3.4.3 Solution Diagrams
Solution diagrams often depict the platforms involved in a particular service. You will typically see a core platform and connection to third-party service providers like authentication services or payment gateways.
4. Understanding Application Design with M2LP
4.1 Car Engines and Software Applications
Perhaps the best analogy of how M2LP works is imagining a mechanic inspecting a car engine. The engine is a highly complicated device with many subsystems integrated through electrical, electronic, and mechanical devices.
One way of troubleshooting a car’s engine is by plugging in a scanner and looking for errors and faults registered in the onboard computer. When that fails to identify the problem, a qualified engineer must disassemble and examine the engine. Depending on the problem, possible faulty components are labelled for inspection, taken apart, and tested in isolation. The faulty component is then either fixed or replaced by a specialized technician.
It is remarkable how close troubleshooting a car’s engine is to fixing software problems. In the latter, we start by looking at the outside description of the problem. We then locate some potential areas within the application, inspect the logs for exceptions, and, when found, send the issue to development for fixing.
M2LP is an extension of that method of using different engineers and technicians to look at subsystems of the greater whole in which their expertise is most valuable.
4.2 What M2LP Is Not
To be extra succinct with what M2LP offers and what its limitations are, perhaps it’s best to start with what it is not:
4.3 Advantages of Applying M2LP
The advantages of the multi-layer, multi-perspective model (M2LP) can be summarized as follows.
5. What Next?
In the following instalments of this series, we will take the role of the different stakeholders working with an enterprise software application. We will look at what each expects from this application regarding behaviour, functionality, features, and quality standards.
By the end of the series, the reader will have gained an understanding of modern application design.