What Is Software Architecture?

A system’s software architecture is the set of significant design decisions about how the software is organized to promote desired quality attributes and other properties.

A design decision might be significant for any number of reasons. It might represent a point of no return or influence quality attributes, schedule, or costs. A significant decision might be one that affects many people or forces other software systems to change. In any case, significant design decisions are costly to change later if you get them wrong.

To promote a quality attribute means to encourage it to appear in the software system. When the architecture is well organized, it will boost the quality attributes stakeholders want and downplay or eliminate the quality attributes stakeholders don’t want. Architecture can promote other properties too. For example, the right architecture for the job will let you ship on time, on budget, and without requiring too much overtime.

Define the Essential Structures

A skyscraper has a foundation and frames. A body has bones. Software has structures. A structure defines how a software system is arranged. Structures are in the code you write, the software you run, and even your collaborations with other people.

To create a structure, take any element and connect it to another element using a relation. Think of elements and relations like the bricks and mortar of software. The bread and peanut butter. The duct tape and…well, you get the idea. Elements are the fundamental building blocks of software. Relations describe how elements work together to accomplish some task.

It’s easy to design an architecture on paper with no bearing on reality. To avoid this trap, you’ll build architectures using three types of elements and relations. Software Architecture in Practice [BCK12] defines these three types as module, component and connector (C&C for short), and allocation. To create a structure, combine elements and relations of the same type.

Here are some example elements and relations of each type.

Module structures exist at design time. You interact with module structures when you write code. Module structures live on the file system and stick around even when the software is not running.

Component and connector structures come into existence at runtime. At runtime, components can create connections to other components, spawn new processes, and instantiate new objects. Unlike module structures, C&C structures cease to exist when the system is not running. You might only know a C&C structure existed from the artifacts it left behind, such as a log file or database entry.

Allocation structures are created by showing how module and C&C elements correspond with each other and the physical elements that exist in real life. Allocation structures are sometimes called mapping structures since they show how different elements map to one another. Does an element run on the client machine or the server? Which teams are building which parts of the system? Allocation structures help us answer questions like these.

Joe asks:

Are Components and Modules Different Things?

In your software development career you may have heard the words module and component used interchangeably and in different contexts. Technically a component is a different concept from a module. A module refers to a design time element whereas a component is a runtime idea.

Sometimes this precision in language is important. Using a term with specific meaning to describe something general can create confusion. Anytime you want to describe a generic building block of an architecture instead of using component or module, use the word element.

All that said, arguing about semantics is not the best way to get your ideas across. While I encourage you to use proper and precise terminology, your ideas will sometimes get better mileage by adapting your language so others understand you.

Different kinds of structures are useful for thinking about different properties you want in your system. For example, you can think about testability and maintainability using a module structure. A C&C structure helps us think about runtime concerns such as availability or performance. You also might know there’s a gap in our understanding if you see mixed structures such as a static element using a dynamic relation.

Structures determine the shape of our system. The shape is important since it decides the quality attributes and other properties your users will experience. In the next section you’ll see how to use structures to reason about quality attributes, but first, it’s time get your hands dirty with a quick exercise.

Get Your Hands Dirty: Elements, Relations, and Structures

Find a few teammates from a recent project. Working alone, list or sketch module, component and connector, and allocation structures from that project. Share your lists with one another. How do they compare? Are there structures your teammates identified that you didn’t? Discuss the similarities and differences in the structures different teammates identified.

Here are some things to think about:

• Be specific when naming the elements. Don’t forget about the relations!

• Think about the module structures: What methods or classes are used? Do the classes live in different packages or namespaces? What dependencies are included in package managers or build scripts?

• Think about the C&C structures: Does the software interact with other processes or systems at runtime? Who calls the system and how does it change in response?

• Think about the allocation structures: Who is responsible for building different parts of the software? How is the software deployed?

Reason about Quality Attributes (and Other System Properties)

Say you’re building a calculator app and you want to add two numbers together. Sounds easy, right?

Wait. Did you want a calculator that adds two numbers and is fast, reliable, scalable, and maintainable? Why didn’t you say so! If we hadn’t asked about these quality attributes, we might have designed the wrong system altogether.

A quality attribute is any externally visible characteristic by which stakeholders judge a software system’s goodness. Some examples include scalability, availability, maintainability, and testability. You experience quality attributes when you interact with the software.

When you choose an architectural structure, you are choosing the quality attributes you want to be promoted in the software system. Thinking about software architecture makes sure you design a software system that supports the quality attributes you want within the context of all the other concerns vying for attention.

Quality attributes make software unique. The circumstances of every system are different—different team, different budget, different market conditions, even different technology trends. As a result, no two architectures will ever be the same even if the feature sets are identical.

Up for the challenge? In the next section, you’ll learn some strategies for becoming your team’s architect.