What is "Software Architecture"?
Tags: architecture, education, programming
Published: 2021-04-05 11:25:35


As the importance of software continues to increase in our everyday life, the underlying methodical foundation, known as _software architecture_, should become common developer knowledge and skill.

In a short series of blog posts, we like to briefly introduce this topic.

## An overly general definition of _architecture_
Let’s start with an explanation of the term architecture itself – Wikipedia helps us out:

> The word is of Greek origin: ἀρχιτέκτων (arkhitekton), meaning both process and product of planning, designing and constructing buildings and other stuff. In everyday language, architecture means either “designing buildings” or the “design of buildings”.

In information technology (IT), we use Architecture in a different way. For us it encompasses at least the following topics:

* organization of (single) software systems
* combinations of hardware and software (called system architecture)
* organization of information technology within organizations (called enterprise IT architecture)

The IT-related semantics of architecture obviously has its roots in the analogy to building and real-estate architecture - where architects design and construct immobile and rather rigid structures.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/boxi6qlt40fxuckj38yp.png)
Some terms in context of _software architecture_
 

## An IT-specific definition of _software architecture_

Let us move towards a more precise and comprehensive definition of software architecture – which will tell us “_what_” to do (no definition ever tells us “_how_” to do something – we need a little more room for answers to that question.)

>Software Architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.
>[IEEE Standard 1471](https://en.wikipedia.org/wiki/IEEE_1471)


Let me explain some key terms of this definition:

**System**
The Merriam-Webster dictionary defines a system as “a regularly interacting or interdependent group of items forming a unified whole”.
This definition is so abstract, it covers every conglomerate of arbitrary items either interacting or just being stuck together.

In software, we usually have interacting building blocks (== code) cooperating with each other to fulfil some system requirements. An alternative term could be application or program.

Every system is embedded into some environment (see below).
Systems can have arbitrary sizes, e.g. 
* the software system we’re often ranting about, 
* the system of servers and networks we like to call cloud, 
* the huge multinational corporation that’s owning both hard- and software, and so on.

The term _system_ can quite easily become a source of severe misunderstanding, when people remain vague about the concrete scope of the system they are currently thinking about. 

**Components** 
Subsystems, modules, classes, functions – for which I usually prefer the term _building block_ as a generalized version of the structural elements of software: Components are usually implemented in source code in a programming language, but can also be other artifacts that (together) make up the system.


**Relationships** 
Interfaces, dependencies, associations - many names for the same feature: Components need to interact with other components, otherwise no separation of concerns (division of responsibility) would be possible. The downside: Designing good interfaces is really difficult, and misunderstandings at the interface level are the source of many problems in software systems.

**Environment** 
Every system has some relationships (aka interfaces, dependencies) to its environment: data, control flow or events are transferred to and from maybe different kinds of neighbors. The [context view](https://docs.arc42.org/section-3/) of software emphasizes the importance of these external interfaces. The following example shows the application itself in yellow and the neighboring systems in grey.

![Context view](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/33n77u4u7kdf5rug66e9.png)
A simple system with its (business or logical) environment
 
**Principles** 
A rule that holds for the whole system or several parts of it. Some decision or definition, usually valid for several elements of the system. I prefer the term concept instead of principle: Concepts are the foundation for conceptual integrity or consistency – in my opinion, one of the most important qualities of software systems (I’ve [written about them](https://www.innoq.com/de/blog/whats-in-a-name-consistency/)). Concepts can be developed and modified during development, they are often driven by specific quality requirements (like performance, scalability, robustness or security).

**Design and Evolution** 
Cross-cutting and system-wide decisions might become necessary during both initial design and ongoing evolution and maintenance of systems. Most non-trivial systems require such decisions taken at key points during their lifecycle, definitely not restricted to the initial design and implementation phase.

## How to design/develop Software Architectures?

The [International Software Architecture Qualification Board](https://isaqb.org), a non-profit standardization body, has defined a curriculum describing several sub-disciplines of software architecture. 

That’s congruent to the (open-source) [arc42](https://arc42.org) overview of software architecture tasks, please see the mindmap below for an overview.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yx8m1aafi5uoj2iezx3e.png)
Tasks of Software Architects

Architecture is an inherently iterative endeavor which requires feedback on several levels (to name just a few: technical, structural, conceptual, methodical, personal). Therefore I strongly believe in architecture as a team or group activitiy, instead of delegating all the tasks to a single person, in order to improve feedback and quality. 

## Common Misunderstandings

In my 20+ years of practical work in software architecture, I encountered several recurring misunderstandings regarding “_architecture_”. The most critical of these: People sometimes have different reference points when talking about architecture, especially with respect to the system under consideration:

1. Some people refer to the system as a single (yet often quite large!) piece of software. Their understanding of architecture refers to this scope. This is my favorite interpretation. 
2. Other people interpret the system as the underlying hardware: These people often name the discipline System Architecture, and their building blocks or main architectural elements consists of physical infrastructure (or at least virtualized infrastructure). I prefer to call this discipline infrastructure architecture to avoid the ambigious term “system”.
3. A third category interprets the system as a combination of hardware and software. Often, they call their discipline System Architecture, containing hardware- and software-architecture as sub-disciplines. I heard this interpretation from people constructing and building embedded systems, e.g. refrigerators, washing machines, airports or airplanes.
4. Some organizations introduced the role of _Solution Architects_. Nobody could ever explain to me what the difference between software- and solution architects is, but the term exists anyhow. I personally have not the faintest idea why one should need a second term (_solution architecture_) with exactly the same semantic as the (proven and established) term _software architecture_. If you encounter this term, make sure you understand what’s meant by _solution_ before starting to work on it :-)


## Additional References
* [iSAQB](https://isaqb.org) – the International Software Architecture Qualification Board.
* [arc42](https://arc42.org) – the free and open-source solution for software architecture communication and documentation. Extensive documentation:  [docs.arc42.org](https://docs.arc42.org) resp. [faq.arc42.org](https://faq.arc42.org)


 
## Ackwnowledgements

Thanx to Dr. Alexander Lorz for intensive and productive discussions on software architecture – which ultimately lead to our upcoming book “Software Architecture Foundation”.