Why is Application Architecture So Important?
Some people prefer to work blindly, adapting as they discover new needs, with little to no planning. In a market dominated by speed, project delays due to an inability to adapt the architecture to needs can be a death sentence, which is why having a clear application architecture is so important.
Everything you need to know about application architecture
Application architecture is the structural map of software applications within a system. It details how each software unit relates to others and how they interact to meet business or user requirements. So, if it's just a diagram, what's the big deal? Why do so many people place such importance on it?
Think of it as a blueprint. For very small projects, say patching a crack in a wall, you wouldn't bother drawing the entire layout of your house. But if you want to build a house, that's a different story. And what if the house is already built? Then your blueprint serves as a guide if you want to remodel it in the future.
Application architectures are similar in that they help us understand how everything is arranged, and thus allow us to predict what will happen if we make changes to the system. In other words, it's a powerful tool for strategy and planning. A well-documented architecture is a prerequisite for a smooth transition, whether it's changing a part of our system or scaling the application.
Can you make changes to a system without a clear understanding of its underlying architecture? Of course. Is it a bad idea? Obviously. Software architects have a term for applications that are assembled haphazardly: "spaghetti architecture" — a maze of incoherent dependencies between different parts of the application.
So what's the problem with "spaghetti architecture"? Let's take a look:
- Poor service abstraction: Imagine your core services scattered across different systems. This is not only extremely difficult to manage but also makes editing code harder.
- Snowball effect: When components are not isolated from each other, changing one part of the system can trigger a chain reaction that crashes the entire application.
- Inflexible legacy systems: The more complex the architecture, the harder it is to change. In turn, the less motivation there is to update it, fostering a culture of obsolescence.
What are the layers of application architecture?
Software is best thought of as a series of layers. In fact, this is such a good analogy that it is used by default in most AA diagrams. To summarize, the most common layers of application architecture are:
- presentation layer
- data services layer
- business logic layer
- data access layer
Other models have fewer or more layers, but whichever model you work with, there is always a way for users to interact with the application, a way to deliver data, a core processing system that performs calculations, and a place where data is stored.
Presentation layer
This layer is related to the user interface; it is the part of the application that handles user input, manages user requests, sends requests to data services, presents output, and essentially deals with all other forms of user interaction. For example, in the case of web applications, this is the so-called frontend, using technologies like JavaScript, HTML, and CSS to create the part of the site that the client consumes.
Data services layer
This layer is the link between the presentation layer and the business logic layer. From a security perspective, it represents a wall separating user actions from the core application logic, making it safer for you and your clients.
Business logic layer
At this level, data is exchanged or processed, user input is encoded, and/or information is prepared for transmission to the presentation layer. For example, in a dynamic web application, this is the part that decides what information the presentation layer needs. It retrieves information from the data store, performs necessary preparation, and sends it for display to the user.
Data access layer
This is where data is stored, most often using SQL or NoSQL solutions. This is the layer from which data is accessed and sent.
What are the different types of application architectures?
Although there are too many to summarize in one article, you should at least know that there are dozens of architectures. Some are more popular than others, and those are the ones we'll discuss today.
Monolithic architectures
Also known as the three-tier application model. Although many consider it outdated by modern standards, it is still used, especially in legacy systems. In this model, the architecture is a single monolithic structure managed by one team. The application becomes a huge system of intertwined instructions that becomes increasingly cumbersome as it grows.
Microservices architecture
In this architectural style, the application is built as a set of independent services. Each can use different technologies, for example, be written in different programming languages, and be tested separately from the rest of the system. Each service is tied to a core business function and can be deployed independently of the others.
Event-driven serverless architecture
This type of architecture functions as a series of disparate systems that are triggered in response to events. In this case, we don't have servers but services that wait for something to happen to react. It is a very compact and fast architecture that scales easily and is cost-effective because only what is needed is used when needed.
Cloud architecture
This architecture is similar to both microservices and event-driven architectures, but with the caveat that it is specifically designed to maximize the use of cloud technologies. For example, architecture with the ability to auto-scale based on requirements or to combine different services from one or multiple cloud providers.
It's never too late...
What if you already have an application without a clear architecture? Is it too late? Of course not, the need to create a diagram based on an existing application is much more common than you'd think. The sooner you start, the better, because as we said, the longer you wait, the more you sink into the quagmire.