Architecture

The word is of Greek origin: ἀρχιτέκτων (arkhitekton), meaning both process and product of planning, designing and constructing buildings and other stuff [1].

some terms related to software architecture
some terms related to software architecture

In everyday language, architecture means „building“.

In IT, we use Architecture in the following areas:

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.

„Software Architecture“

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 [2] below shows the application itself in yellow and the neighboring systems in gray).

Sample of Context View
Sample of Context View

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:

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:

Activities/Tasks of Software Architects
Activities/Tasks of Software Architects

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.

More Details…

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

Common Misunderstandings

In my 20+ years of practical work in software architecture, I encountered numerous misunderstandings and confusion regarding „architecture“:

  1. 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!

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

  5. 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…

Thank you

Thanx for reading – and may the forces of simplicity and effectiveness be with you and your architectural decisions!

Sources and Further References

Acknowledgments

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.

  1. Wikipedia on „architecture“  ↩

  2. Diagrams from the eBook arc42 by Example.  ↩

TAGS