Dieser Artikel ist auch auf Deutsch verfügbar
- Part 1: Building, purpose, aesthetics
- Part 2: Terms (this article)
In the first article, we examined architecture as it pertains to buildings and explained some of the terms and challenges involved in this discipline. Now we turn to information technology and explain what software architecture means.
What is software architecture?
In everyday parlance, we use the term architecture primarily for the design and appearance of buildings.
In the field of IT, we use architecture in at least the following areas (not necessarily a complete list):
- Organization and structure of software systems
- Organization and structure of combinations of hardware and software (also called system architecture)
- Organization of the information technology within organizations (also called enterprise IT architecture)
- Structure and technical details of integrated circuits, especially of CPUs (central processing units) – in this series, I will not be discussing this special interpretation of “architecture,” such as ARM or x86 architecture
- Other areas, depending on the company or organization
A practical definition
In my opinion, the best and most pragmatic definition of “software architecture” can be found in the standard IEEE 1471 (see also [1]).
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.
System, components, relationships, principles – these are all terms commonly encountered in everyday speech, but I would like to explain what they mean specifically in connection with architecture. As everyone knows, a shared understanding of terms is essential for mutual comprehension. So let’s get started.
System
The Merriam-Webster dictionary defines a system as a “a regularly interacting or interdependent group of items forming a unified whole.”
This definition is so abstract as to cover every conglomeration of arbitrary elements that either interact or are even simply mixed together.
In particular, a system can take any size, such as
- an individual software system of the kind we so often complain about,
- a mixture of hardware and software in a complex device, such as a controller in a car or even a smartphone,
- a collection of servers and networks, which we often refer to as a cloud,
- a gigantic multinational corporation, which includes both hardware and software, and so on.
In software, we typically have components (see below) that cooperate together in order to satisfy specific requirements. As an alternative to the term system, we often speak of an application or program.
Every system is embedded in an environment and interacts with one or more other systems (see “environment” further below).
To avoid confusion surrounding this central concept, it is therefore important to clarify exactly the scope that characterizes the system in question. In other words, when we speak about systems, we should clearly state what exactly we mean in the specific case.
But let’s return to the definition of software architecture and clear up a few other terms:
Components
Here we have another everyday term that we need a definition for. Wikipedia defines a system component as follows:
An entity with discrete structure within a system considered at a particular level of analysis.
In software, we encounter a wide range of structural units: applications, subsystems, services, modules, classes, functions. It is important to note that components can also come from other sources, such as third-party components or services.
With respect to software development, I like to replace component with the more general term building block – as used in the terminology of arc42. Components generally consist of source code in a programming language, but they can also be other artifacts, such as configurations. The source code of the entire system consists of multiple such components.
From the perspective of infrastructure and operations, we also count servers, containers, firewalls, and other (physical or virtual) hardware units as components. In arc42, we find such infrastructure components in the deployment view.
In typical architecture diagrams, we find components depicted as boxes.
Relationships
Interfaces, dependencies, associations – many names for the same phenomenon: Components must interact with other components, otherwise no separation of interests (division of responsibility) would be possible. The main problem: Designing good interfaces is extremely difficult, and misunderstandings regarding interfaces are known to be the cause of many problems in software systems. As you are likely already familiar, relationships are typically indicated in diagrams with arrows.
Relationships also have their corresponding concepts in terms of infrastructure and hardware. In this case, the relationships consist of the physical connections between infrastructure components, frequently realized as networks or buses.
Environment
Every system has an environment. From this environment come data, events, and commands. Conversely, events flow back into this environment. These outside relationships are called external interfaces.
One part of the environment is formed by other IT systems, software, or even hardware. The other part of the environment consists of actors that utilize, operate, configure, or otherwise interact with the system.
The context view of software highlights the significance of these external interfaces. The following example comes from arc42 by Examples and shows the application itself in yellow and the adjacent systems in gray).
Components + relationships = structures
Although the term “structure” is not included at all in the practical definitions above, I would like to address it here. As usual, let’s start with a definition:
The structure of a thing is how the parts of it relate to each other, how it is “assembled.”
When working with architecture, we often talk about structural decisions when we refer to the segmentation or decomposition of the system into components and their relationships, in other words the internal organization.
Structures consist of elements (components or building blocks) and their relationships, both to each other and to the environment. You are sure to be familiar with structures from the typical architecture diagrams, i.e. boxes (a.k.a. components or building blocks) with their relationships.
A quick teaser: The combination of components and relationships (i.e. the structure) will become particularly important an the next article of these series. Specifically, I predict that you will be much occupied with this combination in practice.
Principles (synonym: concepts):
Principles are rules, patterns, or other high-level decisions that apply to multiple aspects or even the entire system. I prefer the term concept over principle: Concepts are the foundation of conceptual integrity or consistency, in my opinion one of the most important properties of software systems (I have written in detail about this in a blog post).
In everyday life, for example, the door and window handles within a building have a uniform appearance, and the same applies to the type of window frames and light switches. In the following diagram, you can see three different concepts for windows that have been utilized uniformly for a given system (building). Uniformity doesn’t necessarily mean that they are all perfectly identical but that they follow similar principles, patterns, or rules.
Examples of concepts in IT systems
- Build and deploy on GitLab with GitOps
- All graphical interfaces are implemented with React Native
- All public APIs are penetration tested for possible weaknesses by a third party before every major release
- Application data is generally saved in PostgreSQL
Concepts offer uniform solutions for problems or tasks that arise regularly in software.
Teams can design and implement concepts as part of the system-specific development process. However, concepts are often reusable, such as storing data with the help of Spring Data. In other words, teams can adopt concepts from other systems. Concepts frequently reference specific technology or product decisions (for example: Spring Boot, Hibernate, .NET Core, Angular, React, PostgreSQL). In addition, concepts can involve specific methodologies for development or deployment of systems, such as penetration testing in the box above)
Specific quality requirements (such as performance, scalability, robustness, or security) or conditions (such as budget or statutory requirements) can determine the selection and character of such concepts.
Design and evolution
High-level and system-side decisions in software architecture are made both during the initial design process and during the ongoing development (evolution) of systems. Architecture can therefore be viewed as something that changes over the course of a project. Decisions relevant to the architecture can arise at any time, whenever changes are required to the system, its immediate environment (see context above), or its infrastructure.
We have now sufficiently defined the key terms involved in software architecture. Before we move on to the specific tasks and activities required, there are a few more topics to be considered when it comes to software architecture.
What else must be considered with respect to architecture?
In addition to the topics listed above (components, interfaces, and concepts), there are a few other things to keep in mind regarding software architecture:
- (Architectural) decisions often have a very long-lasting influence and involve critical or complicated problems. It is therefore important to identify explicit decision criteria and to communicate these accordingly. I find the Architectural Significance Test from Olaf Zimmermann to be very useful here.
- Since systems often remain in use for a long time, you should communicate and/or document the architecture appropriately, with a scope based on the specific system. The practical and proven arc42 template simplifies this enormously.
- Architectural styles and patterns provide orientation and can serve to an extent as sample solutions. Examples patterns include clean architecture, microservices, and self-contained systems.
- Fundamental design principles such as simplicity, modularity, loose coupling and high cohesion, separation of responsibilities, encapsulation, and others.
- Technical aspects such as frameworks, libraries, and programming languages, protocols, networks, and infrastructure (cloud, on-premises, or custom hardware). These supply important ingredients for systems and their architecture.
- Methodologies for structuring systems, such as domain-driven design, help with identifying suitable components (see above) and their interfaces.
- The consideration of make-or-buy, in other words the decision of whether a team should develop something itself or purchase it from a third party. Classic quality requirements play a role here, as do topics such as risk assessment, time-to-market, lifespan, and licensing and support costs.
Now you have a rough idea of what you should pay attention to when you want to create software architecture. We examine all this in somewhat more detail in the next article in the series, which is about the tasks and activities of the role of “software architect.”
The most important rule: It depends
************One size doesn’t fit all. Microservices are not appropriate for every project, and <tool X> (where X is any IT tool of your choice) will not solve all problems. There are no universal standard solutions in software and system development, in other words there is no silver bullet. Many patterns, approaches, methodologies, and even technologies will often work well enough in many cases, but in specific situations, you will sometimes need to make case-specific decisions. It all depends on the situation, the team and its level of experience, the risks and criticality of the system, the funding or budget, the available time, technologies, and infrastructure, the development, testing, and operating processes, and certainly other factors as well.
It is intrinsic to the design of software architecture that this variable of “it depends” must be assigned values that are appropriate to the specific situation and context. But that already touches on the content of the next article.
Outlook
In the third part of this mini-series, we explain which specific tasks and activities (can) systematically lead to appropriate architectures.
Until then, may you be blessed with the ability to make suitable decisions.
Acknowledgements
Many thanks to “m”, Martin Weck, and Benjamin Wolf for their thorough reviews!
Image references
-
Mark Maier, David Emery and Rich Hilliard: Introducing the IEEE 1471, IEEE Computer April 2001, West–Virginia University. ↩