What is Software Architecture?

Author: Gernot Starke
Posted by Team Marketing at Van Haren Publishing

As the importance of software continues to increase in our everyday lifes, 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.

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.

Let us move towards a more precise and comprehensive definition of architecture – which will tell us “what” to do (no definition evers 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.

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

Fig. 1: Environment / Context example

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). 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) arc42 overview of software architecture tasks, please see the mindmap below for an overview:

Fig. 2: 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 idea 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 you move on.

Moving on

In a follow-up post I will explain some reasons, why software architecture continous to be highly relevant for succesful IT systems, and why architecture is the foundation for achieving quality requirements, like performance, maintainability, security and robustness.

References

• iSAQB – the International Software Architecture Qualification Board, https://iSAQB.org
• arc42 – the free and open-source solution for software architecture communication and documentation: https://arc42.org

About the author

Dr. Gernot Starke, INNOQ fellow, has been developing, architecting and improving software systems since more than 30 years. After studying computer science at the Technical University of Aachen, he received his PhD on Software Engineering from the J.Kepler University in Linz, Austria.

Since 1990 he has worked in various technical roles in software development, from architecture, requirements engineering, testing and project management.

He was lead architect in several mid- to large size information systems in logistics, telecommunications, finance and the public sector. He’s co-founder of the free arc42 architecture template, the aim42 architecture improvement method and founding member of the iSAQB (International Software Architecture Qualification Board).

He published a dozen books on architecture, patterns and development methodology.

Find more info on https://gernotstarke.de and https://innoq.com.

Acknowledgements

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