Understanding software architecture

Let’s begin by defining what software architecture is. When you create an application, library, or any software component, you need to think about how the elements you write will look and how they will interact with each other. This arrangement of elements and their interactions defines software architecture. In other words, you’re designing different elements and their relationships with their surroundings.

Just like with urban architecture, it’s important to think about the bigger picture so as not to end up in a haphazard state. Thus, the architecture of a software system is a metaphor similar to the architecture of a building; it is a set of important decisions about the organization of a software system. On a small scale, every single building may look okay, but they may not fit together well. Similarly, while software architecture aims to create a well-structured system, software development might progress in unexpected ways.

Keep in mind that whether you put thought into it or not, when writing software, you are creating an architecture. Therefore, avoid accidental architectures—those that arise without a clear strategy—as this can disrupt your IT systems.

On the other hand, emerging architectures—those that emerge gradually from the multitude of design decisions—are inevitable as systems grow. Over time, they become explicitly identified and are implemented intentionally after proving themselves.

So, what exactly should you be creating if you want to mindfully define the architecture of your solution? The Software Engineering Institute has this to say:

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

In the following section, we will discuss different types of architectures and explore how software architecture fits within a broader context. A clear understanding of the architecture type helps in correctly identifying the elements involved and defining the scope of work instead of just hopping into writing code.

Different ways to look at architecture

There are several ways to look at architecture, each with a different scope:

• Enterprise architecture deals with the whole company or even a group of companies. It takes a holistic approach and is concerned about the strategy of whole enterprises. When thinking about enterprise architecture, you should be looking at how all the systems in a company behave and cooperate with each other. It’s concerned with the alignment between business and IT.
• Solution architecture is less abstract than its enterprise counterpart. It stands somewhere in the middle between enterprise and software architecture. Usually, solution architecture is concerned with one specific system and the way it interacts with its surroundings. A solution architect needs to come up with a way to fulfill a specific business need, usually by designing a whole software system or modifying existing ones.
• Software architecture is even more concrete than solution architecture. It concentrates on a specific project, the technologies it uses, and how it interacts with other projects. A software architect is interested in the internals of the project’s components.
• Infrastructure architecture is, as the name suggests, concerned with the infrastructure that the software will use. It defines the deployment environment and strategy, how the application will scale, failover handling, site reliability, and other infrastructure-oriented aspects.

Solution architecture is based on both software and infrastructure architectures to satisfy the business requirements. Later in this chapter, we will talk about key principles of software architecture to prepare you for both small- and large-scale architecture design. Let’s now discuss another critical aspect of understanding software architecture.

Communication and culture

The focus of this book is software architecture. Why would we want to mention communication and culture in a book around software, then? If you think about it, all software is written by people for people. The human aspect is prevalent, and yet we often fail to admit it.

As an architect, your role won’t be just about figuring out the best approach to solving a given problem. You’ll also have to communicate your proposed solution to your team members. Often, the choices you make will result from previous discussions.

These are the reasons communication and team culture also play a role in software architecture.

Conway’s Law states that the architecture of the software system reflects the organization that’s working on it. This means that building great products requires building great teams and understanding that social interaction impacts the success or failure of projects.

Development culture can be compared to an ecosystem. It is a daily task and cannot be introduced by decree. The culture can become destructive if you don’t take care of it. Poor management can degrade even a well-established team culture within an organization.

Thus, if you want to be a great architect, developing people skills may be as important as developing technical ones.

Now that we have looked at both the technical and social aspects of software architecture, let’s answer one fundamental question: why is architecture important?