The next post in this mini-series discussing overloaded terms: This time, I’ll cover architecture, a term that every person working in IT will have their own distinct opinion about.
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 “building”.
In IT, we use Architecture in the following areas:
- overall organization of (single) software systems
- overall organization of combinations of hardware and software (aka system architecture)
- overall organization of information technology within organizations (aka enterprise IT architecture)
- arbitrary technical documentation
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.
In my opinion, the best and most versatile and pragmatic definition of “software architecture” has been published by the IEEE in their standard IEEE 1471 (which was later adopted by ISO/IEC 42010).
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. But let’s get back to our software stuff:
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 example  below shows the application itself in yellow and the neighboring systems in gray).
Principles: A rule that holds for the whole system or several parts of it. Some decision, stipulation 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 in a previous post). 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.
What to Care About?
As a software architect, you need to keep in mind the aspects mentioned above, plus several more:
- (Architectural) decisions often have a long-lasting influence, and are tackling critical or complicated issues. It helps to identify explicit decision criteria.
- Architecture documentation - sometimes despised by development teams. Pragmatical approaches like arc42 facilitate documentation. Have a look at some lean and pragmatic examples (courtesy of innoQ, you can get this collection of arc42 examples for free!)
- Architectural styles and patterns, like the currently hyped Microservices or Self-Contained-Systems approaches.
- Technical aspects, like frameworks, libraries, protocols, and various infrastructure topics.
- Methodical approaches to structuring systems, like Domain Driven Design.
Now you know what to care about when you have to do software architecture. Such clear terminology and nice separation of concerns between structural and crosscutting aspects. What could be unclear here?
What to do?
The International Software Architecture Qualification Board, a non-profit standardization body, has defined a curriculum describing several sub-disciplines of software architects. That’s congruent to the (open-source) arc42 overview of software architecture tasks, please see the mindmap below for an overview:
I wholeheartedly believe that these activities shall be performed by a small team in order to improve feedback and quality. Architecture is an inherently iterative endeavor which requires feedback on several levels (to name just a few: technical, structural, conceptual, methodical, personal).
To keep this post at an acceptable length, I refrain from elaborating on these activities. The terms (like clarify requirements) should give you at least an idea what can be expected of software architects.
To get a broader view of what’s behind software architecture, you could read more definitions by various authors - the well-known Software Engineering Institute even maintains a collection of such definitions (in my opinion not really worth reading, though).
In my 20+ years of practical work in software architecture, I encountered numerous misunderstandings and confusion regarding “architecture”:
People sometimes have different reference points when talking about architecture, especially with respect to the system under consideration: Sometimes the system refers to a single (yet often quite large!) piece of software. This is my personal favorite!
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”.
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.
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 clue 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 you move on.
Some people take the metaphor of the building architect way to far: The systems they design (and which are built by bricklayers, masons and numerous other craftspeople) are physical, and neither the design nor the building process might contain all those nice agile aspects we have come to enjoy so much when crafting software…
Thanx for reading – and may the forces of simplicity and effectiveness be with you and your architectural decisions!
Sources and Further References
- Software Architecture Glossary by members of the iSAQB association. Extensive (and free!) collection of software architecture terminology, oriented towards the various iSAQB curriculae - available as eBook and online.
- Effective Software Architecture, a short eBook (written by myself), briefly explaining software architecture. Mainly a learning guide for the CPSA-Foundation curriculum.
- Len Bass et. al: Software Architecture in Practice, 3rd edition, Addision-Wesley, 2015. Written by members of the Software Engineering Institute the third edition of this (huge) book explains many facets of software architecture in detail. Beware - their argumentation is usually targeted towards ultra-large-scale projects, and in some cases conflicts with lean and agile practices.
Thanx to Phillip Ghadir and Peter Hruschka for discussing and practicing architecture with me for several years, Martin Kühl (@mkhl), Michael Krämer (@mkramerx) and Sven Johann @kaesfiehs for their valuable feedback on prior versions of this post.
Wikipedia on “architecture” ↩
Diagrams from the eBook arc42 by Example. ↩