What is "Software Architecture”

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.

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
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 neighbours. The Context view of software emphasizes the importance of these external interfaces. The following example shows the application itself in yellow and the neighbouring systems in grey.

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 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, a non-profit standardization body, has defined a curriculum describing several sub-disciplines of software architecture.
That’s congruent to the (open-source) arc 42 overview of software architecture tasks, please see the mind map below for an overview.

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 favourite 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 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.