A few months ago, my parents decided to buy an above-ground pool in preparation for the summer. While the pool itself was perfect, there was a very small problem. It didn’t come with the assembly manual. Not a big deal nowadays because you can just go online and download the instructions from the website.
Except my father isn’t exactly tech savvy. Much to my surprise, he had assembled the whole thing by trial and error, except for a few “spare parts” that he had put aside. When I checked the instruction manual, there were no spare parts, and the pool was an accident waiting to happen.
Some people like to go in blind, adapting as new needs are detected, with little to no planning. While that may work for a summer pool, it’s an entirely different problem for software development. In a market where speed reigns supreme, having to delay a project because your architecture can’t adapt to your necessities can be a death sentence, and that’s why it’s so important to have a clear application architecture.
All You Need To Know About Application Architecture
Application architecture is a structural map of the software applications in a system. It details how every unit of software is related to each other 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 make such a big issue of it?
Think of it like a blueprint. For very small projects, say, fixing a fissure on your wall, you wouldn’t bother drawing a whole diagram of your house. But if you want to build a house, well, that’s another matter entirely. What about if the house is already built? Well, then your blueprint serves as a guideline if you want to remodel down the line.
Application architectures are similar in that they help us understand how everything comes together and, as such, let us make predictions on what will happen if we make changes within the system. In other words, it’s a powerful asset in terms of strategizing and planning. A well-documented architecture is a must for a seamless transition, be it to change a part of our system or to scale our application.
Could 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 have been haphazardly put together: “spaghetti architecture,” a labyrinth of byzantine dependencies between different parts of your application.
So what’s the problem with spaghetti architecture? Let’s see:
- Poor service abstraction: Imagine having your core services spread across different systems. Not only is it extremely difficult to manage, but it also makes code very hard to edit.
- Snowball effects: When your components are not isolated from each other, changing a part of the system can cause a chain reaction that can bring down the application as a whole.
- Inflexible legacy systems: The more complex your architecture, the more difficult it is to change. In turn, the less motivated you are to actually upgrade it, fostering a culture of obsolescence.
What Are the Layers of Application Architecture?
The software can be best represented as a series of layers. In fact, this is such a good analogy, it’s the default for most AA diagrams. To summarize, the most common application architecture layers are:
- Presentation layer
- Data service layer
- Business logic layer
- Data access layer
Other models have fewer or more levels, but whichever model you work with will always have a way for users to interact with the app, a way to deliver data, a core processing system that deals with the calculations, and a place where data is stored.
Presentation Layer
This layer deals with the user interface, it’s the part of the application that handles user input, manages user requests, sends requests to data services, presents outputs, and basically deals with all other forms of user-application interaction. For example, in the case of web applications, this is what we call the frontend, using technology like JavaScript, HTML, and CSS to create the part of your website that is consumed by the client.
Data Service Layer
This layer acts as the bridge between the presentation layer and the business logic layer. From a security standpoint, it’s a wall that separates what the user is doing from the core logic of your application, making it safer for you and for your clients.
Business Logic Layer
The brains of the operation, this layer is where data is exchanged or processed, encoding user inputs and/or preparing information to be relayed to the presentation layer. For example, in a dynamic web application, this is the part of the app that decides what information is required by the presentation layer. It takes the information from the data storage, makes any preparations necessary, and sends it to be displayed by the user.
Data Access Layer
This is where data is stored, more often than not using SQL or NoSQL solutions. It’s the layer from which data is accessed and sent.
What Are the Different Types of Application Architectures?
While there are too many to summarize in a single article, you should at least be aware that there are dozens of architectures. Some are quite more popular than others, and those are the ones we are going to talk about today.
Monolithic Architectures
Also known as the 3-tier application model. While most people consider it outdated by modern standards, it’s still used, especially with legacy systems. In this model, the architecture is a single monolithic entity managed by 1 single team. The application becomes a massive system of interweaved instructions that becomes more unwieldy as it grows.
Microservices Architecture
With this architectural style, applications are structured as a collection of independent services. Each one can use different tech, such as being written in different programming languages and can be tested separately from the rest of the system. Each service is related to a core business function and can be deployed separately from the rest.
Event-driven Serverless Architecture
This type of architecture functions as a series of decoupled systems that run in response to events. In this case, we don’t have servers but rather services waiting for something to happen to act in response. This is a very lean and fast architecture that can easily scale and is cost-effective, since you are only using what is required when it’s required.
Cloud Architecture
This architecture is similar to both microservice architecture and event-driven, but with the added caveat that it’s specifically designed to make the most out of cloud technology. For example, architecture that can auto-scale based on requirements or mix different services from one or more cloud providers.
It’s Never Too Late…
So, what if you already have an application without a clear architecture? Is it too late? Of course not, having to create a diagram from an existing application is actually more common than anyone would like to admit. The sooner you start, the better, since as we’ve mentioned before, the more you wait, the more you sink into a spaghetti sinkhole.
