What is software architecture?

Before we start learning about microservices architecture and the different patterns related to it, we need to learn what software architecture is.

If we have to construct a building, a structural architect needs to lay out the design of the building and think about building capacity, the weight the foundation needs to hold, the number of floors the building will have, staircases, elevators for easy access, and the number of entry and exit gates.

Similar to a construction architect, a software architect is responsible for designing software and defining how software components will interact with each other.

Software architecture defines how your source code should be organized and how different elements in your code interact with each other in a software application using proven design patterns to achieve a business outcome.

The following diagram shows the interaction between source code components and their organization with the help of design patterns, which is what software architecture is built on:

Figure 1.1 – Software architecture structure

Now that we have defined what software architecture is, let’s compare it with the building example we discussed earlier. If you look closely, you will find that the construction project is very similar to an application and that each area in a building resembles a different aspect of software architecture. Each floor in a building can be thought of as a software layer in an application.

Building capacity is very similar to the load or number of requests your application can handle. The building’s foundation can be compared to the software infrastructure or hardware on which the application is deployed, while load capacity is directly related to the memory and space needed by the application. Staircases and elevators can be thought of as items used for your users to access your application and entry and exit gates can be treated as endpoints exposed by your application to outside systems. Design patterns can be thought of as a method you use to mix the concrete or how many iron rods you need to lay out a solid foundation.

Software architecture is built by organizing the source code components and their interaction with each other, constructed with the help of design patterns.

Important note

A design pattern defines a way to solve a common problem faced by the software industry. Design patterns don’t provide any implementation code for the problem but provide general guidelines on how a particular problem in a given context should be solved. These solutions are the best practices to use in similar situations. An architect has the flexibility to fine-tune solutions or mix different patterns or design new patterns to solve their specific problems or adjust solutions to achieve certain results.

Fine-tuning a solution or design pattern is known as an architectural trade-off, where you balance out your parameters to achieve a certain result. For example, let’s say you need to have your building foundation a few meters under the Earth to make a skyscraper, which increases your construction cost; however, if you want to make a building with only a few floors, then you don’t need to make your foundation so solid. Similarly, you can make adjustments to your software architecture/design pattern to achieve certain results. To mitigate risk to a project, the Architecture Tradeoff Analysis Method (ATAM) is used in the early phase of an architectural design.

How you build your design pattern or interaction is based on your use case and the architectural trade-offs you have made to achieve certain software goals; there is no right or wrong architecture – it is something that keeps evolving.

The ATAM process

The ATAM process collects quality attributes such as business goals, functional requirements, and non-functional requirements by bringing the stakeholders together. These quality attributes are used to create the different scenarios; then, architectural approaches and decisions run through these scenarios to create an analysis of risks, sensitivity points, and trade-offs. There can be multiple iterations of this analysis and each iteration fine-tunes the architecture. The solution proceeds from being generic to more specific to the problem and risk is mitigated.