iSAQB Glossary of Software Architecture Terminology
Table of Contents
Introduction
This book contains a glossary of software architecture terminology.
It can serve as a reference for preparation for the iSAQB e.V. examination Certified Professional for Software Architecture - Foundation Level©.
Please be aware: This glossary is not intended to be a primer or course book on software architecture, just a collection of definitions (and links to further information).
Furthermore, you find proposals for translations of the iSAQB terminology, currently between English and German (and vice-versa).
Finally this book contains numerous references to books and other resources, many of which we quoted in the definitions.
This book is work in progress.
Errors or omissions can also be reported in our issue tracker on Github, where the authors maintain the original sources for this book.
Terms Can Be Referenced
All terms in the glossary have unique URLs to the (free) online version of the book, therefore they can be universally referenced, both from online- and print documentation.
Our URL scheme is quite simple:
- The base URL is
https://leanpub.com/isaqbglossary/read
- We just add the prefix
#term-
in front of the term to be referenced, then the term itself, with hyphens (“-“) instead of blanks.For example our description of the term software architecture can be referenced (hyperlinked) with
https://leanpub.com/isaqbglossary/read#term-software-architecture
Nearly all terms are hyperlinked with their full names, with very few examples that are referenced by their (common) abbreviations, like UML or DDD.
License

This book is licensed under a Creative Commons Attribution 4.0 International License. The following is only a brief summary and no substitution for the real license.
The cc-4.0-by license means that you might:
- Share — copy and redistribute the material in any medium or format
- Adapt — remix, transform, and build upon the material for any purpose, even commercially.
- The licensor cannot revoke these freedoms as long as you follow the license terms.
You must:
- Give appropriate credit,
- Provide a link to the license (https://creativecommons.org/licenses/by/4.0/)), and
- Indicate if (and which) changes were made with respect to the original.
Acknowledgements
Several parts of this glossary have been contributed by the following volunteers and sponsors:
- The definitions of about 120 terms have been donated by Gernot Starke, originally compiled for one of his books.
- A number of definitions in context of system improvement and evolution was contributed by the aim42 open source project.
Contributing
Your input is highly appreciated by the authors.
Glossary of Terms
Abstraction
A view of an element that focuses on the information relevant to a particular purpose and ignores the remainder of the information.
Category: Design-Principle
Abstractness
Metric for the source code of object oriented systems: The number of abstract types (interfaces and abstract classes) divided by the total number of types.
Category: Metric
ACL
Access Control Lists are a way to organize and store permissions of an principal for a specific entity. Beside implementations on an application level a typical example for an ACL is the management of file permissions on unix based operating systems.
Since ACLs don’t scale well on a large base it is common to model access control based on roles (RBAC).
Category: Security
Adapter
The adapter is a design pattern that allows the interface of an existing component to be used from another interface. It is often used to make existing components cooperate with others without modifying their source code.
Category: Design-Pattern, Foundation.
Aggregate
Aggregate is a building block of Domain-Driven Design. Aggregates are complex object structures that are made of entities and value objects. Each aggregate has a root entity and is regarded as a unity when it comes to changes. An aggregate ensure consistency and integrity of its contained entities with invariants.
Category: DDD
Aggregation
A form of object composition in object-oriented programming. It differs from composition, as aggregation does not imply ownership. When the element is destroyed, the contained elements remain intact.
Category: Foundation
Appropriateness
(syn: adequacy) Suitability for a particular purpose.
arc42
Free template for communication and documentation of software architectures. arc42 consists of 12 (optional) parts or sections.
Category: Communication, Documentation
Architecture
Category: ISO-IEC-IEEE-42010
Architectural Decision
Decision, which has an sustainable or essential effect on the architecture.
Example: Decision about database technology or technical basics of the user interface.
Following ISO/IEC/IEEE 42010 an architectural decision pertain to system concerns. However, there is often no simple mapping between the two. A decision can affect the architecture in several ways. These can be reflected in the architecture description (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Architecture description
Work product used to express an architecture (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Architecture description element
An architecture description element is any construct in an architecture description. architecture description elements are the most primitive constructs discussed in ISO/IEC/IEEE 42010. All terms defined in ISO/IEC/IEEE 42010 are a specialization of the concept of an architecture description element (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Architecture description language
An architecture description language (ADL) is any form of expression for use in architecture descriptions (as defined in ISO/IEC/IEEE 42010).
Examples are Rapide, Wright, SysML, ArchiMate and the viewpoint languages of RM-ODP [ISO 10746].
Category: ISO-IEC-IEEE-42010
Architecture evaluation
Quantitative or qualitative assessment of a (software or system) architecture. Determine if an architecture can achieve its target qualities or quality attributes?
See Assessment
In our opinion the terms architecture analysis or architecture assessment are more appropriate, as evaluation contains value, implying numerical assessment (which is usually only part of what you should do in architecture analysis).
Architecture framework
Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders (as defined in ISO/IEC/IEEE 42010).
Examples are:
- Generalised Enterprise Reference Architecture and Methodologies (GERAM) [ISO 15704] is an architecture framework.
- Reference Model of Open Distributed Processing (RM-ODP) [ISO/IEC 10746] is an architecture framework.
Category: ISO-IEC-IEEE-42010
Architecture goal
(syn: Architectural quality goal, Architectural quality requirement): A quality attribute that the system needs to achieve and the quality attribute is understood to be an architectural issue.
Hence, the architecture needs to be designed in a way to fullfill this architectural goal. These goals often have long term character in contrast to (short term) project goals.
Category: Fundamental
Architecture model
An architecture view is composed of one or more architecture models. An architecture model uses modelling conventions appropriate to the concerns to be addressed. These conventions are specified by the model kind governing that model. Within an architecture description, an architecture model can be a part of more than one architecture view (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Architecture objective
See architecture goal.
Architectural (architecture) pattern
“An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined sub- systems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them” (Buschmann+1996, page 12). Similar to Architecture style
Examples include:
- Model-View-Controller
- Layers
- Pipes-and-Filter
- CQRS
Architecture quality requirement
See architecture goal.
Architecture rational
Architecture rationale records explanation, justification or reasoning about architecture decisions that have been made. The rationale for a decision can include the basis for a decision, alternatives and trade-offs considered, potential consequences of the decision and citations to sources of additional information (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Architecture style
Description of element and relation types, together with constraints on how they can be used. Often called architecture patterns. Examples: Pipes-and-Filter, Model-View-Controller, Layers.
Architecture view
A representation of a system from a specific perspective. Important and well-known views are:
- Context view,
- Building block view
- Runtime view
- Deployment view
[Bass+2012] and [Rozanski+11] extensively discuss this concept.
Following ISO/IEC/IEEE 42010, an architecture view is a work product expressing the architecture of a system from the perspective of specific system concerns (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Architecture viewpoint
Work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Artifact
Tangible by-product created or generated during development of software. Examples of artifacts are use cases, all kinds of diagrams, UML models, requirements and design documents, source code, test cases, class-files, archives.
Asset
“In information security, computer security and network security an Asset is any data, device, or other component of the environment that supports information-related activities. Assets generally include hardware (e.g. servers and switches), software (e.g. mission critical applications and support systems) and confidential information”
(quoted from Wikipedia)
Category: Security
Assessment
See also Evaluation.
Gathering information about status, risks or vulnerabilities of a system. Assessment might concerning potentially all aspects (development, organization, architecture, code etc.)
Association
Defines a relationship between objects (in general: between modules). Each association can be described in detail by cardinalities and (role-)names.
See coupling, dependency and relationship
Category: Foundation
Asymmetric Cryptography
Asymmetric cryptography algorithms are designed that the key which is used for encryption is different from the key used for decryption. The key for encryption is called “public-key” the key for decryption is called “private-key”. The public key can be published and used by anyone to encrypt information only readable by the party owning the private-key for decryption. See Schneier, Public-Key Algorithms, page 17.
Asymmetric cryptography is fundamental for PKI and digital signatures.
Category: Security
ATAM
Architecture Tradeoff Analysis Method. Qualitative architecture evaluation method, based upon a (hierarchical) quality tree and concrete quality scenarios. Basic idea: Compare fine-grained quality scenarios (“quality-requirements”) with the corresponding architectural approaches to identify risks and tradeoffs.
Attack Tree
Formal way to describe different approaches of an attacker to reach certain goals. The tree is usally structured with the attack goal on top and different approaches as child nodes. Each approach is likely to have dependencies which are again listed as child nodes. The possibiliy of a certain way to attack an IT-system can be analyzed by assigning additional attributes to each node. Examples could be the estimated costs of an attack or if an attack approach is possible or not by referencing countermeasures.
See Bruce Schneier on “Modeling security threats”.
Category: Security
Authentication
Authentication is the process of confirming the claim of an identity by a given entity. Usually this is done by verifying at least one of the authentication factors which is known by the system:
- knowledge (e.g. password)
- ownership (e.g. security token)
- inherence (e.g. biometrics)
For a stronger authentication mutiple factors can be requested or at least factors of two categories.
Category: Security
Authorization
“Authorization or authorisation is the function of specifying access rights to resources related to information security and computer security in general and to access control in particular. More formally, “to authorize” is to define an access policy.”
(quoted from Wikipedia)
Category: Security
Availability
One of the basic Security Goals describing a system that can provide desired information when its needed. From a security perspective for example denial-of-service-attacks may prevent availability.
Category: Security
Blackbox
View on a building block (or component) that hides the internal structure. Blackboxes respect the information hiding principle. They shall have clearly defined input- and output interfaces plus a precisely formulated responsibility or objective. Optionally a blackbox defines some quality attributes, for example timing behavior, throughput or security aspects.
Category: Foundation
Bottom-up Approach
Direction of work f(or strategy of procesing) or modeling and design. Starting with something detailed or concrete, working towards something more general or abstract.
“In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems.” (quote from Wikipedia)
Bounded Context
Bounded Context is principle of the strategy design of Domain-Driven Design. “A bounded context explicitly defines the context within which a domain model for a software system applies. Ideally, it would be preferable to have a single, unified model for all software systems in the same domain. While this is a noble goal, in reality it typically fragments into multiple models. It is useful to recognize this fact of life and work with it.” (quote from Wikipedia)
“Multiple domain models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confusing. It is often unclear in what context a model should not be applied. Therefore: Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.” (quote from Wikipedia)
Category: DDD
Bridge
Design pattern in which an abstraction is decoupled from its implementation, so that the two can vary independently. In case you find that incomprehensible (as most people) - have a look here
Category: Design-Pattern
Broker
An architecture pattern used to structure distributed software systems with decoupled components that interact by (usually remote) service invocations.
A broker is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions.
Category: Architecture-Pattern
Building Block
General or abstract term for all kinds of artifacts from which software is constructed. Part of the statical structure (Building Block View) of software architecture.
Building blocks can be hierarchically structured - they may contain other (smaller) building blocks.
Some examples of alternative (concrete) names for building blocks: Component, module, package, namespace, class, file, program, subsystem, function, configuration, data-definition.
Building Block View
Shows the statical structure of the system, how its source code is organized. Usually a hierarchical manner, starting from the context view. Complemented by one or several runtime scenarios.
Business Architecture
A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.
CA
A Certificate Authority issues digital certificates to a given subject in a PKI. Usually there is a trust established to this authority which results in the same trust level to the issued certificates.
An example is the widely used TLS-PKI where every browser includes the root-certificates of a defined list of CAs. These CAs then check the identity of a given internet domain owner and digitally sign his certificate for the use with TLS.
Category: Security
Cardinality
Describes the quantitative rating of an association or relationship. It specifies the number of participants (objects, instances, modules etc) of the association.
CIA Triad
See Security Goals
Category: Security
Cloud
“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”
Definition quoted from NIST (National Institute of Standards and Technology).
The NIST definition contains the following five characteristics (quoted but abbreviated from the aforementioned NIST source too):
- On-demand self service: A consumer can unilaterally provision computing
capabilities, such as server time and network storage,
without requiring human interaction with each service provider. - Broad network access: Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous client platforms.
- Resource pooling: The provider’s computing resources are pooled to serve
multiple consumers using a multi-tenant model, with different physical and
virtual resources dynamically assigned and reassigned according to consumer demand. There is location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).
Examples of resources include storage, processing, memory, and network bandwidth. - Rapid elasticity: Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
- Measured service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
Cohesion
The degree to which elements of a building block, component or module belong together. It measures the strength of relationship between pieces of functionality within a given component. In cohesive systems, functionality is strongly related. It is usually characterized as high cohesion or low cohesion. Strive for high cohesion, because high cohesion often implies reusability, low coupling and understandability.
Command
Design pattern in which an object is used to encapsulate an action. This action might be invoked or executed at a later time.
Complexity
“Complexity is generally used to characterize something with many parts where those parts interact with each other in multiple ways.” (quoted from Wikipedia.)
- Essential complexity is the core of the problem we have to solve, and it consists of the parts of the software that are legitimately difficult problems. Most software problems contain some complexity.
- Accidental complexity is all the stuff that doesn’t necessarily relate directly to the solution, but that we have to deal with anyway.
(quoted from Mark Needham)
Architects shall strive to reduce accidental complexity.
Component
See Building block. Structural element of an architecture.
Composition
Combine simpler elements (e.g. functions, data types, building blocks) to build more complicated, powerful or more responsible ones.
In UML: When the owning element is destroyed, so are the contained elements.
Concept
Plan,principle(s) or rule(s) how to solve a specific problem.
Concepts are often crosscutting in a sense that multiple architectural elements might be affected by a single concept. That means that implementors of e.g. implementation units (building blocks) should adhere to the corresponding concept.
Concepts form the basis for conceptual integrity.
Concern
“A concern about an architecture is a requirement, an objective, a constraint, an intention, or an aspiration a stakeholder has for that architecture.” (quoted from [Rozanski+11], chapter 8)
Following ISO/IEC/IEEE 42010 a concern is defined as (system) interest in a system relevant to one or more of its stakeholders (as defined in ISO/IEC/IEEE 42010).
Note, a concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.
Category: ISO-IEC-IEEE-42010
Confidentiality
One of the basic Security Goals describing a system to disclose and make information only available to authorized parties.
Category: Security
Context (of a system)
“Defines the relationships, dependencies, and interactions between the system and its environment: People, systems, and external entities with which it interacts.” (quoted from Rozanski-Woods)
Context View
Shows the complete system as one blackbox within its environment, either from a business perspective (business context) or from a technical or deployment perspective (technical context). The context view (or context diagram) shows the boundary between a system and its environment, showing the entities in its environment (its neighbours) with which it interacts.
See Context.
Correspondence
A correspondence defines a relation between architectural description elements. Correspondences are used to express architecture relations of interest within an architecture description (or between architecture descriptions) (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Correspondence rule
Correspondences can be governed by correspondence rules. Correspondence rules are used to enforce relations within an architecture description (or between architecture descriptions) (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Coupling
Coupling is the kind and degree of interdependence between building blocks of software; a measure of how closely connected two components are.\ You should always aim for low coupling. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a well-structured system. When combined with high cohesion, it supports understandability and maintainability.
CPSA
Certified Professional for Software Architecture® – the common name for different levels of certification issued by the iSAQB. The most common known certifications are the foundation level (CPSA-F) and the advanced level (CPSA-A).
CQRS
(command query responsibility segregation): Separate the elements manipulating (command) data from those just reading (query). This separation enables different optimization strategies for reading and writing data (for example, it’s much easier to cache data that’s read-only than to cache data that’s also altered.)
There’s an interesting eBook by Mark Nijhof on this subject.
Crosscutting concept
See concept.
Synonym: principle, rule.
Crosscutting concern
Functionality of the architecture or system that affects several elements. Examples of such concerns are logging, transactions, security, exception handling, caching etc.
See also concept.
Cyclomatic complexity
Quantitative measure, number of independent paths through a program’s source code.
It roughly correlates to the number of conditional statements (if
, while
) in the code +1.
A linear sequence of statements without if
or while
has the cyclomatic complexity of 1.
Many software engineers believe that higher complexity correlates to the number of defects.
Category: Metric.
Decomposition
(syn: factoring) Breaking or dividing a complex system or problem into several smaller parts that are easier to understand, implement or maintain.
Dependency
See coupling.
Dependency Injection (DI)
Instead of having your objects or a factory creating a dependency, you pass the needed dependencies to the constructor or via property setters. You therefore make the creation of specific dependencies somebody else’s problem.
Dependency Inversion Principle
High level elements should not depend upon low level elements. One of the SOLID principles, nicely explained by Brett Schuchert.
Deployment
Bring software onto its execution environment (hardware, processor etc). Put software into operation.
Deployment view
Architectural view showing the technical infrastructure where a system or artifacts will be deployed and executed.
“This view defines the physical environment in which the system is intended to run, including the hardware environment your system needs (e.g., processing nodes, network interconnections, and disk storage facilities), the technical environment requirements for each node (or node type) in the system, and the mapping of your software elements to the runtime environment that will execute them.” (as defined by Rozanski+2011)
Design pattern
General or generic reusable solution to a commonly occurring problem within a given context in design. Initially conceived by the famous architect Christopher Alexander, the concept of design patterns was taken up by software engineers.
In our opinion, every serious software developer should know at least some patterns from the pioneering Gang-of-Four book by Erich Gamma (Gamma+1994) and his three allies.
Design principle
Set of guidelines that helps software developers to design and implement better solutions, where “better” means the avoidance of the following three bad characteristics:
- Rigidity: A system or element is difficult to change because every change potentially affects many other elements.
- Fragility: When elements are changed, unexpected results, defects or otherwise negative consequences occur at other elements.
- Immobility: An element is difficult to reuse because it cannot be disentagled from the rest of the system.
These characteristics have been formulated by Robert Martin, quoted from OODesign.com
Document
A (usually written) artifact conveying information.
Documentation
A systematically ordered collection of documents and other material of any kind that makes usage or evaluation easier. Examples for “other material”: presentation, video, audio, web page, image, etc.
Documentation Build
Automatic build process that collects artifacts into a consistent documentation.
Domain-Driven Design (DDD)
“Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.” (quoted from DDDCommunity). See Evans-2004.
See also:
Domain model
The domain model is a concept of Domain-Driven Design. The domain model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
Drawing Tool
A tool to create drawings that can be used in architecture documentation. Example: Visio, OmniGraffle, PowerPoint, etc. Drawing tools treat each drawing as a separate thing, this causes maintenance overhead when updating an element of the architecture that is shown in several diagrams (as opposed to a Modeling Tool).
Economicalness
Embedded system
System embedded within a larger mechanical or electrical system. Embedded systems often have real-time computing constraints. Typical properties of embedded systems are low power consumption, limited memory and processing resources, small size.
Encapsulation
Encapsulation has two slightly distinct notions, and sometimes to the combination thereof:
- restricting access to some of the object’s components
- bundling of data with the methods or functions operating on that data
Encapsulation is a mechanism for information hiding.
Enterprise IT Architecture
Synonym: Enterprise Architecture.
Structures and concepts for the it support of an entire company. Atomic subject matters of the enterprise architecture are single software systems also referred to as „applications“.
Entity
Category: Entity is a building block of Domain-Driven Design. An entity is a core object of a business domain with unchangeable identity and a clearly defined lifecycle. Entities map their state to value objects and are almost always persistent.
Entropy
In information theory defined as “amount of information” a message has or “unpredictability of information content”. The entropy of a cryptosystem is measured by the size of the keyspace. Larger keyspaces have an increased entropy and if not flawed by the algorithm itself, harder to break than smaller ones. For secure cryptographic operations it is mandatory to not only use random values as input, they should have also a high entropy. The creation of high entropy on a computer system is non-trivial and can affect the performance of a system.
See 11.1 Information Theory of Schneier-1996 and Whitewood Inc. on “Understanding and Managing Entropy” or SANS “Randomness and Entropy - An Introduction”.
Category: Security
Environment
(System) Context determining the setting and circumstances of all influences upon a system (as defined in ISO/IEC/IEEE 42010).
Note, the environment of a system includes developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.
Category: ISO-IEC-IEEE-42010
Facade
Structural design pattern. A Facade offers a simplified interface to a complex or complicated building block (the provider) without any modifications to the provider.
Factory
(Design pattern) In class-based or object-oriented programming, the factory method pattern is a creational design pattern that uses factory methods or factory components for creating objects, without having to specify the exact class of the object that will be created.
In Domain-Driven Design: A factory encapsulates the creation of aggregates, entities, and value objects. Factories work exclusively in the domain and have no access to technical building blocks (e.g. a database).
Filter
Part of the pipe-and-filter architectural style that creates or transforms data Filters typically execute independent from other filters.
Fundamental Modeling Concepts (FMC)
Graphical notation for modeling and documenting software systems. From their website: “FMC provide a framework for the comprehensive description of software-intensive systems. It is based on a precise terminology and supported by a graphical notation which can be easily understood”.
Gateway
A (design or architecture) pattern: An element of that encapsulates access to a (usually external) system or resource. See also wrapper, adapter.
Global analysis
Systematic approach to achieve desired quality attributes. Developed and documented by Christine Hofmeister (Siemens Corporate Research). Global analysis is described in [Hofmeister+2000].
Heterogeneous architectural style
see hybrid architecture style.
Heuristic
Informal rule, rule-of-thumb. Any way of problem solving not guaranteed to be optimal, but somehow sufficient. Examples from Object-Oriented Design or User Interface Design.
Hybrid architecture style
Combination of two or more existing architecture styles or patterns. For example, an MVC construct embedded in a layer structure.
IEEE-1471
Standard Recommended Practice for Architectural Description of Software-Intensive Systems, defined as ISO/IEC 42010:2007. Defines a (abstract) framework for the description of software architectures.
Incremental development
see iterative and incremental development.
Information Hiding
A fundamental principle in software design: Keep those design or implementation decisions hidden that are likely to change, thus protecting other parts of the system from modification if these decisions or implementations are changed. Is one important attributes of blackboxes. Separates interface from implementation.
The term encapsulation is often used interchangeably with information hiding.
Integrity
One of the basic Security Goals which means maintaining and assuring accuracy and completeness of data. Usually this is achived by the usage of cryptographic algorithms to create a digital signature.
Category: Security
Interface
Boundary across which two building blocks interact or communicate with each other.
Interface Segregation Principle (ISP)
Building blocks (classes, components) should not be forced to depend on methods they don’t use. ISP splits larger interfaces into smaller and more (client) specific ones so that clients will only need to know about methods that they actually use.
iSAQB
international Software Architecture Qualification Board – an internationally active organization fostering the development of software architecture education. See also the discussion in the appendix.
ISO 9126
(Deprecated) standard to describe (and evaluate) software product quality. Has been superseded by ISO 25010, see below.
ISO 25010
Standards to describe (and evaluate) software product quality. “The quality model determines which quality characteristics will be taken into account when evaluating the properties of a software product.” (quote from the ISO website)
Iterative development
“Development approach that cycles through development phases, from gathering requirements to delivering functionality in a working release.” (quoted from c2-wiki).
Such cycles are repeated to improve either functionality, quality or both.
Contrast to the Waterfall development.
Iterative and incremental development
Combination of iterative and incremental approaches for software development. These are essential parts of the various agile development approaches, e.g. Scrum and XP.
Kerckhoffs’ Principle
One of the six cryptographic axioms described 1883 in an article “La cryptographie militaire” by the dutch cryptographer and linguist Auguste Kerckhoffs. This axiom is still relevant today and therefore refered to as “Kerckhoffs’ Principle”.
It describes that a cryptographic method must not need to be kept secret in order to achive the security of the encrypted messages.
“The enemy knows the system” is another expression coined by the mathematician Claude Shannon as Shannon’s Maxim.
See Bruce Schneiers Crypto-Gram, May 15, 2002
Category: Security
Layer
Grouping of building blocks or components that (together) offer a cohesive set of services to other layers. Layers are related to each other by the ordered relation allowed to use.
Liskov Substitution Principle
Refers to object oriented programming: If you use inheritance, do it right: Instances of derived types (subclasses) must be completely substitutable for their base types. If code uses a base class, these references can be replaced with any instance of a derived class without affecting the functionality of that code.
MFA
For Multi-Factor-Authentication see Authentication.
Category: Security
Microservice
An architectural style, proposing to divide large systems into small units. “Microservices have to be implemented as virtual machines, as more light-weight alternatives such as Docker containers or as individual processes. Thereby they can easily be brought into production individually.” (quoted from the (free) LeanPub booklet on Microservices by Eberhard Wolff.
Model Driven Architecture (MDA)
OMG-Standard for model based software development. Definition: „An approach to IT system specification that separates the specification of functionality from the specification of the implementation of that functionality on a specific technology platform.“
Model-driven software development (MDSD)
The underlying idea is to generate code from more abstract models of requirements or the domain.
Model kind
Conventions for a type of modeling (as defined in ISO/IEC/IEEE 42010).
Note, examples of model kinds include data flow diagrams, class diagrams, Petri nets, balance sheets, organization charts and state transition models.
Category: ISO-IEC-IEEE-42010
Modeling Tool
A tool that creates models (e.g. UML or BPMN models). Can be used to create consistent diagrams for documentation because it has the advantage that each model element exists only once but can be consistently displayed in many diagrams (as opposed to a mere Drawing Tool).
Model-View-Controller
Architecture pattern, often used to implement user interfaces. It divides a system into three interconnected parts (model, view and controller) to separate the following responsibilities:
- Model manages data and logic of the system. The “truth” that will be shown or displayed by one or many views. Model does not know (depend on) its views.
- View can be any number of (arbitrary) output representation of (model) information. Multiple views of the same model are possible.
- Controller accepts (user) input and converts those to commands for the model or view.
Module
(see also Modular programming)
- structural element or building block, usually regarded as a black box with a clearly defined responsibility. It encapsulates data and code and provides oublic interfaces, so clients can access its functionality. This meaning has first been described in a groundbreaking and fundamental paper from David L. Parnas: On the Criteria to be Used in Decomposing Software into Modules
- In several programming languages, module is a construct for aggregating smaller programming units, e.g. in Python. In other languages (like Java), modules are called packages.
Modular programming
“Software design technique that separates the functionality of a program into independent, interchangeable modules, so that each module contains everything necessary to execute only one aspect of the desired functionality.
Module have interfaces expressing the elements provided and required by the module. The elements defined in the interface are detectable by other modules.” (quoted from Wikipedia)
Node (in UML)
A processing resource (execution environment, processor, machine, virtual machine, application server) where artifacts can be deployed and executed.
Node (Node.js)
In modern web development: Short form for the open source JavaScript runtime Node.js®, which is built on Chrome’s V8 JavaScript engine. Node.js is famous for its an event-driven, non-blocking I/O model and its vast ecosystem of supporting libraries.
Non Functional Requirement (NFR)
Requirements that constrain the solution. Nonfunctional requirements are also known as quality attribute requirements or quality requirements. The term NFR is actually misleading, as many of the attributes involved directly relate to specific system functions (so modern requirements engineering likes to call these things required constraints).
Notation
A system of marks, signs, figures, or characters that is used to represent information. Examples: prose, table, bullet point list, numbered list, UML, BPMN.
Observer
(Design pattern) “… in which an object maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. The Observer pattern is a key part in the model–view–controller (MVC) architectural pattern”. (quoted from Wikipedia)
Open-Close-Principle (OCP)
„Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“ (Bertrand Meyer, 1998). In plain words: To add functionality (extension) to a system, you should not need to modify existing code. Part of Robin Martins “SOLID” principles for object-oriented systems. Can be implemented in object oriented languages by interface inheritance, in a more general way as plugins.
OWASP
The Open Web Application Security Project is a worldwide non-profit online organization founded 2001 for improving the security of software. It is a rich source for information and best practices in the field of web security. See https://www.owasp.org/.
The OWASP-Top-10 is a frequently referenced list of attack categories based on the projects data survey.
Category: Security
Pattern
A reusable or repeatable solution to a common problem in software design or architecture.
See architecture pattern or design pattern.
Perfect Forward Secrecy
Property of a cryptographic protocol were an attacker can’t gain any information about short-term session keys by compromising long-term keys.
Examples for protocols with perfect forward secrecy are TLS and OTR. If this feature is enabled for TLS and an attacker gains access to a servers private key, previously recorded communication sessions can still not be decrypted.
Category: Security
Perspective
A perspective is used to consider a set of related quality properties and concerns of a system.
Architects apply perspectives iteratively to the system’s architectural views in order to assess the effects of architectural design decisions across multiple viewpoints and architectural views.
[Rozanski+11] associates with the term perspective also activities, tactics, and guidelines that must be considered if a system should provide a set of related quality properties and suggests the following perspectives:
- Accessibility
- Availability and Resilience
- Development Resource
- Evolution
- Internationalization
- Location
- Performance and Scalability
- Regulation
- Security
- Usability
Pikachu
A yellowish mouse-like character from the (quite famous) Pokémon world. Actually, you don’t need to know that. But it does not hurt either - and you might impress your kids with this knowledge…
Pipe
Connector in the pipes-and-filters architectural style that transfers streams or chunks of data from the output of one filter to the input of another filter without modifying values or order of data.
PKI
Short for Public-Key-Infrastructure. A concept of managing digital certificates usually involving asymmetric cryptography. The term “public” refers most of the time to the used type of cryptographic key and not necessarily to infrastructure open to a public audience. To prevent semantic confusion the terms “open PKI” or “closed PKI” can be used, see Anderson, Chapter 21.4.5.7 PKI, page 672.
PKI is usually based on a CA or a Web-of-Trust.
Category: Security
Port
UML construct, used in component diagrams. An interface, defining a point of interaction of a component with its environment.
POSA
Pattern-oriented Software Architecture. Series of books on software architecture patterns.
Principal
Principals in a security context are entities which have been authenticated and can be assigned permissions to. A principal can be a user but for example also other services or a process running on a system. The term is used in the Java environment and throughout different authentication protocols (see GSSAPI RFC2744 or Kerberos RFC4121).
Category: Security
Proxy
(Design pattern) “A wrapper or agent object that is being called by the client to access the real serving object behind the scenes. Use of the proxy can simply be forwarding to the real object, or can provide additional logic. In the proxy extra functionality can be provided, for example caching when operations on the real object are resource intensive, or checking preconditions before operations on the real object are invoked. For the client, usage of a proxy object is similar to using the real object, because both implement the same interface.” (quoted from Wikipedia)
Pseudo-Randomness
Often used in conjunction with pseudo-random-number-generators. Gathering randomness with a high entropy is resource intensive and usually not required by many applications, cryptography left aside. To address this issue pseudo-random-generators are initialized with a seed of data and create random values based on this seed. The data will be generated by random, but will always be the same if the generator is initialized with an identical seed. This is called pseudo-randomness and is less performance intensive.
Category: Security
Qualitative evaluation
Finding risks concerning the desired quality attributes of a system. Analyzing or assessing if a system or its architecture can meet the desired or required quality goals.
Instead of calculating or measuring certain characteristics of systems or architectures, qualitative evaluation is concerned with risks, tradeoffs and sensitivity points.
See also assessment.
Quality
see software quality and quality attributes.
Quality attribute
Software quality is the degree to which a system possesses the desired combination of attributes (see: software quality).
Important quality attributes are performance, robustness, security, safety, flexibility, dependability, maintainability etc.. See also ISO-25010
It’s helpful to distinguish between:
- runtime quality attributes (which can be observed at execution time of the system),
- non-runtime quality attributes_ (which cannot be observed as the system executes) and
- business quality attributes (cost, schedule, marketability, appropriateness for organization)
Examples of runtime quality attributes are functionality, performance, security, availability, usability and interoperability.
Examples of non-runtime quality attributes are modifiability, portability, reusability, integratability, testability.
Quality characteristic
synonym: quality attribute.
Quality requirement
Characteristic or attribute of a component of a system. Examples include runtime performance, safety, security, reliability or maintainability. See also software quality.
Quality tree
(syn: quality attribute utility tree). A hierarchical model to describe product quality: The root “quality” is hierarchically refined in areas or topics, which itself are refined again. Quality scenarios form the leaves of these tree.
- Standards for product quality, like [ISO 25010](#term-iso-25010, propose generic quality trees.
- The quality of a specific system can be described by a specific quality tree (see the example below).

Quantitative evaluation
(syn: quantative analysis): Measure or count values of software artifacts, e.g. coupling, cyclomatic complexity, size, test coverage. Metrics like these can help to identify critical parts or elements of systems.
Randomness
See Entropy or Pseudo-Randomness.
Category: Security
Rationale
Explanation of the reasoning or arguments that lie behind an architecture decision.
RBAC (Role Based Access Control)
A role is a fixed set of permissions usually assigned to a group of principals. This allows a Role-Based-Access-Control usually to be implemented more efficient than an ACL based system and makes for example deputy arrangements possible.
Category: Security
Registry
“A well-known object that other objects can use to find common objects and services.” (quoted from PoEAA). Often implemented as a Singleton (also a well-known design pattern.)
Relationship
Generic term denoting some kind of dependency between elements of an architecture. Different types of relationship are used within architectures, e.g. call, notification, ownership, containment, creation or inheritance.
Redesign
The alteration of software units in such a way that they fulfill a similar purpose as before, but in a different manner and possibly by different means. Often mistakenly called refactoring.
Refactoring
A term denoting the improvement of software units by changing their internal structure without changing the behavior. (see
“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure.” Refactoring, Martin Fowler, 1999
Not to be confused with redesign
Repository
In architecture documentation: A place where artifacts are stored before an automatic build process collects them into one consistent document. In Domain-Driven Design: Repository is a building block of Domain-Driven Design. A repository hides technical details of the infrastructure layer to the domain layer. Repositories return entities that are persisted in the database.
RM/ODP
Reference Model for Open Distributed Processing. (Abstract) metamodel for documentation of information systems. Defined in ISO/IEC 10746.
Round-trip engineering
“Concept of being able to make any kind of change to a model as well as to the code generated from that model. The changes always propagate bidirectional and both artifacts are always consistent.” (quoted from Wikipedia).
Ruby
A wonderful programming language.
Category: Programming
Runtime View
Shows the cooperation or collaboration of building blocks (respectively their instances) at runtime in concrete scenarios. Should refer to elements of the Building Block View. Could for example (but doesn’t need to) be expressed in UML sequence or activity diagrams.
Scenario
Quality scenarios document required quality attributes. They help to describe required or desired qualities of a system, in pragmatic and informal manner, yet making the abstract notion of “quality” concrete and tangible.

- Event/stimulus: Any condition or event arriving at the system
- System (or part of the system) is stimulated by the event.
- Response: The activity undertaken after the arrival of the stimulus.
- Metric (response measure): The response should be measurable in some fashion.
SDL
A Secure-Development-Lifecycle is a companies usual software development process with additional practices of engineering secure software. This involves for example code reviews, architectural risk analyses, black/whitebox and penetration testing and many more additions. The whole lifecycle of an application should be covered by the SDL, beginning with the first requirements engineering tasks and ending with feedback from operating the released software by fixing security issues.
See McGraw “An Enterprise Software Security Program”, page 239.
Category: Security
Security Goals
The goals are the key point of information security. They are a basic set of information attributes which can be fulfilled or not depending on a systems architecture and processes.
The most common agreed set of security goals is the so called “CIA triad”:
- Confidentiality
- Integrity
- Availability
The “Reference Model of Information Assuarance and Security” (RIMAS) extends this list by Accountability, Auditability, Authenticity/Trustworthiness, Non-repudiation and Privacy.
These are typical examples for non-functional requirements related to security.
See “What is Security Engineering - Definitions”, page 11 or RMIAS.
Category: Security
SCS (Self Contained System)
An architectural style, similar to Microservices. To quote from the site scs-architecture.org:
“The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete system a collaboration of many smaller software systems. This avoids the problem of large monoliths that grow constantly and eventually become unmaintainable”
Sensitivity point
(in qualitative evaluation like ATAM): Element of the architecture or system influencing several quality attributes. For example, if one component is responsible for both runtime performance and robustness, that component is a sensitivity point.
Casually said, if you mess up a sensitivity point, you will most often have more than one problem.
Separation of concern (SoC)
Any element of an architecture should have exclusivity and singularity of responsibility and purpose: No element should share the responsibilities of another element or contain unrelated responsibilities.
Another definition is “breaking down a system into elements that overlap as little as possible.”
Famous Edgar Dijkstra said in 1974: “Separation of concerns … even if not perfectly possible, is the only available technique for effective ordering of one’s thoughts”.
Similar to the Single Responsibility Principle.
Sequence diagram
Type of diagram to illustrate how elements of an architecture interact to achieve a certain scenario. It shows the sequence (flow) of messages between elements. As parallel vertical lines it shows the lifespan of objects or components, horizontal lines depict interactions between these components. See the following example.

Service
t.b.d.
Service (DDD)
Service is a building block of Domain-Driven Design. Services implement logic or processes of the business domain that are not executed by entities alone. A service is stateless and the parameters and return values of its operations are entities, aggregates and value objects.
Singleton
“Design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.” (quoted from Wikipedia.
Single Responsibility Principle (SRP)
Each element within a system or architecture should have a single responsibility, and that all its functions or services should be aligned with that responsibility.
Cohesion is sometimes considered to by synonymous for SRP.
Software Architecture
There exist several (!) valid and plausible definitions of the term Software Architecture.
The following definition has been proposed by the IEEE 1471 standard:
The new standard ISO/IEC/IEEE 42010:2011 has adopted and revised the definition as follows:
The key terms in this definition require some explanation:
- Components: Subsystems, modules, classes, functions or the more general term building blocks: structural elements of software: Components are usually implemented in a programming language, but can also be other artifacts that (together) make up the system.
- Relationships: Interfaces, dependencies, associations - different names for the same feature: Components need to interact with other components to enable separation of concerns.
- Environment: Every system has some relationships to its environment: data, control flow or events are transferred to and from maybe different kinds of neighbours.
- Principles: Rules or conventions that hold for a system or several parts of it. Decision or definition, usually valid for several elements of the system. Often called concepts or even solution patterns. Principles (concepts) are the foundation for conceptual integrity.
The Software Engineering Institure maintains a collection of further definitions
Category: ISO-IEC-IEEE-42010
Software Quality
(from IEEE Standard 1061): Software quality is the degree to which software possesses a desired combination of attributes. This desired combination of attributes need to be clearly defined; otherwise, assessment of quality is left to intuition.
S.O.L.I.D. principles
SOLID (single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion) is an acronym for some principles (named by Robert C. Martin) to improve object-oriented programming and design. The principles make it more likely that a developer will write code that is easy to maintain and extend over time.
For some additional sources, see Martin-SOLID.
Stakeholder
Person or organization that can be affected by or have in interest (stake) in a system, its development or execution.
Examples include users, employees, owners, administrators, developers, designer, manager, product-owner, project manager,
Following ISO/IEC/IEEE 42010 a stakeholder is a (system) individual, team, organization, or classes thereof, having an interest in a system (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Structure
An arrangement, order or organization of interrelated elements in a system. Structures consist of building blocks (structural elements) and their relationships (dependencies).
Structures in software architecture are often used in architecture views, e.g. the building block view. A documentation template (e.g. arc42) is a kind of structure too.
Structural element
see Building block or Component
Symmetric Cryptography
Symmetric cryptography is based on an identical key for encryption and decryption of data. Sender and receiver have to agree on a key for communication. See Schneier, Symmetric Algorithms, page 17.
Category: Security
System
Collection of elements (building blocks, components etc) organized for a common purpose.
In ISO/IEC/IEEE Standards a couple of system definitions are available:
- systems as described in [ISO/IEC 15288]: “systems that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities”.
- software products and services as described in [ISO/IEC 12207].
- software-intensive systems as described in [IEEE Std 1471:2000]: “any system where software contributes essential inuences to the design, construction, deployment, and evolution of the system as a whole” to encompass “individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest”.
Category: ISO-IEC-IEEE-42010
System-of-Interest
System-of-Interest (or simply, system) refers to the system whose architecture is under consideration in the preparation of an architecture description (as defined in ISO/IEC/IEEE 42010).
Category: ISO-IEC-IEEE-42010
Template (for documentation)
Standardized order of artifacts used in software development. It can help base other files, especially documents in a predefines structure without prescribing the content of these single files.
A well known example of such templates is arc42
TLS
Transport-Layer-Security is a set of protocols to cryptographically secure the communication of two partys by the means of the CIA-triad. It is widely used for secure communication on the internet and the foundation for HTTPS.
TLS started as an update to its predecessor SSL (Secure Socket Layer) Version 3.0 and should be used now instead of SSL see RFC7568 “Deprecating Secure Sockets Layer Version 3.0”.
Category: Security
TOGAF
The Open Group Architecture Framework. Conceptual framework for planning and maintenance of enterprise IT architectures.
Tools-and-material-approach
t.b.d.
Top-Down
“Direction of work” or “order of communication”: Starting from an abstract or general construct working towards more concrete, special or detailed representation.
Traceability
(more precisely: requirements traceability): Document that
- all requirements are addressed by elements of the system (forward traceability) and
- all elements of the system are justified by at least one requirement (backward traceability)
My personal opinion: If you can, you should avoid traceabiltiy, as it creates a lot of documentation overhead.
Tradeoff
(syn: compromise). A balance achieved or negotiated between two desired or required but usually incompatible or contradicting features. For example, software development usually has to tradeoff memory consumption and runtime speed.
More colloquially, if one thing increases, some other thing must decrease.
Even more colloquially: There is no free lunch. Every quality attribute has a price among other quality attributes.
Ubiquitous language
A concept of Domain-Driven Design: The ubiquitous language is a language that is structured around the domain model. It is used by all team members to connect all the activities of the team with the software. The ubiquitous language is a living thing that is evolving during a project and will be changed during the whole live cycle of the software.
Unified Modeling Language (UML)
Graphical language for visualizing, specifying and documenting the artifacts and structures of a software system.
- For building block views or the context view, use component diagrams, with either components, packages or classes to denote building blocks.
- For runtime views, use sequence- or activity diagrams (with swimlanes). Object diagrams can theoretically be used, but are practically not adviced, as they become cluttered even for small scenarios.
- For Deployment views, use deployment diagrams with node symbols.
Uses relationship
Dependency that exists between two building blocks. If A uses B than execution of A depends on the presence of a correct implementation of B.
Value Object
Value Object is a building block of Domain-Driven Design. ValueObjects do not have a conceptual identity of their own and should be treated as immutable. They are used to describe the state of entities and may be composed of other value objects but never of entities.
View
see: architectural view.
Waterfall development
Development approach “where you gather all the requirements up front, do all necessary design, down to a detailed level, then hand the specs to the coders, who write the code; then you do testing (possibly with a side trip to IntegrationHell) and deliver the whole thing in one big end-all release. Everything is big including the risk of failure.” (quoted from [http://c2.com/cgi/wiki?IterativeDevelopment])
Contrast to iterative development
Web of Trust
Since a single CA could be an easy target for an attacker the web of trust delegates the establishment of trust to the user. Each user decides which other users proof of identity he trusts, usually by verifying a fingerprint of a given key. This trust is expressed by signing the key of the other user who can then publish it with the additional signature. A third user can then verify this signature and decide to trust the identity or not.
The email encryption PGP is an example for a PKI based on a web of trust.
Category: Security
Whitebox
Shows the internal structure of a system or building block, made up from blackboxes and the internal/external relationships / interfaces.
Workflow Management System (WFMS)
Provides an infrastructure for the set-up, performance and monitoring of a defined sequence of tasks, arranged as a workflow. (quoted from Wikipedia)
Wrapper
(syn: Decorator, Adapter, Gateway) Patterns to abstract away the concrete interface or implementation of a component. Attach additional responsibilities to an object dynamically.
Translations
Here you find translations of the terms between English and German (see below) and German-to-English (next section).
Several of these terms are based in the legal and organizational foundations of the iSAQB association (and therefore not related to software architecture).
The following translations are maintained1 in a simple JSON input file, contained within this books’ open source Github repository.
Translations English to German
The following tables have been automatically generated2 from JSON by Groovy and Gradle.
English | German |
---|---|
Adaption | Anpassung |
Adequacy | Angemessenheit |
Approach | Ansatz |
Appropriateness | Angemessenheit |
Architectural objective | Architekturziel |
Architectural pattern | Architekturmuster |
Architectural view | Architektursicht, Sicht |
Architecture assessment | Architekturanalyse, Architekturbewertung |
Architecture evaluation | Architekturbewertung, Architekturanalyse |
Architecture objective | Architekturziel |
Articles of assocation | Satzung des Vereins |
Artifact | Artefakt |
Aspect | Aspekt, Belang |
Assessment | Bewertung, Begutachtung, Einschätzung, Untersuchung |
Association | Verein, Beziehung |
Attack Tree | Angriffsbäume |
Availability | Verfügbarkeit |
Building block | Baustein |
Building block view | Bausteinsicht |
Business | Fachlichkeit, Domäne |
Business architecture | fachliche Architektur, Geschäftsarchitektur |
Cabinet (as methaphor for template) | Schrank (als Metapher für Template) |
Cash audit | Rechnungsprüfung |
Cash auditor | Rechnungsprüfer |
Certification authority | Zertifizierungsstelle |
Certification body | Zertifizierungsstelle |
Chairman | Vorsitzender |
Channel | Kanal |
Cohesion | Kohäsion, innerer Zusammenhalt |
Commensurability | Angemessenheit, Messbarkeit, Vergleichbarkeit |
Compliance | Erfüllung, Einhaltung |
Component | Baustein, Komponente |
Concern | Belang |
Confidentiality | Vertraulichkeit |
Constraint | Randbedingung, Einschränkung |
Context (of a term) | Einordnung (eines Begriffes) in einen Zusammenhang |
Context view | Kontextabgrenzung |
Coupling | Kopplung, Abhängigkeit |
Crosscutting | Querschnittlich |
Curriculum | Lehrplan |
Decomposition | Zerlegung |
Dependency | Abhängigkeit, Beziehung |
Deployment | Verteilung |
Deployment unit | Verteilungsartefakt |
Deployment view | Verteilungssicht |
Deputy chairman | Stellvertretender Vorsitzender |
Design | Entwurf |
Design approach | Entwurfsansatz, Entwurfsmethodik |
Design decision | Entwurfsentscheidung |
Design principle | Entwurfsprinzip |
Domain | Fachdomäne, Fachlicher Bereich, Geschäftsbereich |
Domain-related architecture | fachliche Architektur |
Drawing Tool | Mal-/Zeichenprogramm |
Economicalness | Sparsamkeit, Wirtschaftlichkeit |
Embedded | Eingebettet |
Encapsulation | Kapselung |
Enterprise IT architecture | Unternehmens-IT-Architektur |
Estimation | Schätzung |
Evaluation | Bewertung |
Examination question | Prüfungsfrage |
Examination rules and regulations | Prüfungsordnung |
Examination sheet | Prüfungsbogen |
Examination task | Prüfungsaufgabe |
Examinee | Prüfling |
Examiner | Prüfer |
Executive board | Vorstand |
Fees rules and regulations | Gebührenordnung |
General meeting | Mitgliederversammlung |
Influencing Factor | Einflussfaktor |
Information hiding principle | Geheimnisprinzip |
Integrity | Integrität |
Interdependency (between design decisions) | Abhängigkeit (zwischen Entwurfsentscheidungen) |
Interface | Schnittstelle |
Interface description | Schnittstellenbeschreibung, Schnittstellendokumentation |
Learning goal | Lernziel |
License fee | Lizenzgebühr |
License holder | Lizenznehmer |
Licensee | Lizenznehmer |
Licensing agreement | Lizenzvertrag, Lizenzvereinbarung |
Licensor | Lizenzgeber |
Local court | Amtsgericht |
Means for describing | Beschreibungsmittel |
Means for documenting | Beschreibungsmittel |
Measurability | Messbarkeit |
Members’ meeting | Mitgliederversammlung |
Modeling Tool | Modellierungswerkzeug |
Module | Komponente, Modul, Baustein |
Node | Knoten |
Non-exclusive license | Einfache Lizenz |
Non-profit | Gemmeinnützig |
Notification | Benachrichtigung |
Objective | Ziel |
Operational processes | Betriebsprozesse (von Software) |
Pattern | Muster |
Pattern language | Mustersprache, Musterfamilie |
Perspective | Perspektive |
Principle | Prinzip, Konzept |
Quality attribute | Qualitätsmerkmal, Qualitätseigenschaft |
Quality characteristic | Qualitätsmerkmal, Qualitätseigenschaft |
Quality feature | Qualitätsmerkmal, Qualitätseigenschaft |
Rationale | Begründung, Erklärung |
Real-time system | Echtzeitsystem |
Registered trademark | Marke (gesetzlich geschützt) |
Relationship | Beziehung |
Relationship (kind of) | Beziehungsart |
Repository | Ablage |
Requirement | Anforderung |
Resolution | Beschluss |
Responsibility | Verantwortlichkeit |
Rights of use | Nutzungsrecht |
Runtime | Laufzeit |
Runtime view | Laufzeitsicht |
Security Goals | Schutzziele, Sachziele |
Skill | Fähigkeit, Fertigkeit |
Specification (of software architecture) | Beschreibung (von Softwarearchitektur) |
sponsoring (board) member | materiell förderndes Mitglied |
statutory | satzungsgemäß |
Structure | Struktur |
Task | Aufgabe |
Team regulations | Arbeitsgruppenordnung |
Term | Begriff |
Thriftyness | Sparsamkeit, Wirtschaftlichkeit |
Tools | Arbeitsmittel, Werkzeug |
Tools-and-material-approach | Werkzeug-Material-Ansatz |
Tradeoff | Kompromiss, Abwägung |
Training provider | Schulungsanbieter |
Treasurer | Schatzmeister |
Uses relationship | Benutzt-Beziehung, Nutzungsbeziehung |
View | Sicht |
Workflow management | Ablaufsteuerung |
Working environment | Arbeitsumgebung |
Working group | Arbeitsgruppe |
Working group head | Arbeitsgruppenleiter |
Translations German to English
In this section we collect the iSAQB translation of the terms from German to English.
German | English |
---|---|
Abhängigkeit | Coupling, Dependency |
Abhängigkeit (zwischen Entwurfsentscheidungen) | Interdependency (between design decisions) |
Ablage | Repository |
Ablaufsteuerung | Workflow management |
Abwägung | Tradeoff |
Amtsgericht | Local court |
Anforderung | Requirement |
Angemessenheit | Adequacy, Appropriateness, Commensurability |
Angriffsbäume | Attack Tree |
Anpassung | Adaption |
Ansatz | Approach |
Arbeitsgruppe | Working group |
Arbeitsgruppenleiter | Working group head |
Arbeitsgruppenordnung | Team regulations |
Arbeitsmittel | Tools |
Arbeitsumgebung | Working environment |
Architekturanalyse | Architecture assessment, Architecture evaluation |
Architekturbewertung | Architecture assessment, Architecture evaluation |
Architekturmuster | Architectural pattern |
Architektursicht | Architectural view |
Architekturziel | Architectural objective, Architecture objective |
Artefakt | Artifact |
Aspekt | Aspect |
Aufgabe | Task |
Baustein | Building block, Component, Module |
Bausteinsicht | Building block view |
Begriff | Term |
Begründung | Rationale |
Begutachtung | Assessment |
Belang | Aspect, Concern |
Benachrichtigung | Notification |
Benutzt-Beziehung | Uses relationship |
Beschluss | Resolution |
Beschreibung (von Softwarearchitektur) | Specification (of software architecture) |
Beschreibungsmittel | Means for describing, Means for documenting |
Betriebsprozesse (von Software) | Operational processes |
Bewertung | Assessment, Evaluation |
Beziehung | Association, Dependency, Relationship |
Beziehungsart | Relationship (kind of) |
Domäne | Business |
Echtzeitsystem | Real-time system |
Einfache Lizenz | Non-exclusive license |
Einflussfaktor | Influencing Factor |
Eingebettet | Embedded |
Einhaltung | Compliance |
Einordnung (eines Begriffes) in einen Zusammenhang | Context (of a term) |
Einschränkung | Constraint |
Einschätzung | Assessment |
Entwurf | Design |
Entwurfsansatz | Design approach |
Entwurfsentscheidung | Design decision |
Entwurfsmethodik | Design approach |
Entwurfsprinzip | Design principle |
Erfüllung | Compliance |
Erklärung | Rationale |
Fachdomäne | Domain |
fachliche Architektur | Business architecture, Domain-related architecture |
Fachlicher Bereich | Domain |
Fachlichkeit | Business |
Fertigkeit | Skill |
Fähigkeit | Skill |
Gebührenordnung | Fees rules and regulations |
Geheimnisprinzip | Information hiding principle |
Gemmeinnützig | Non-profit |
Geschäftsarchitektur | Business architecture |
Geschäftsbereich | Domain |
innerer Zusammenhalt | Cohesion |
Integrität | Integrity |
Kanal | Channel |
Kapselung | Encapsulation |
Knoten | Node |
Kohäsion | Cohesion |
Komponente | Component, Module |
Kompromiss | Tradeoff |
Kontextabgrenzung | Context view |
Konzept | Principle |
Kopplung | Coupling |
Laufzeit | Runtime |
Laufzeitsicht | Runtime view |
Lehrplan | Curriculum |
Lernziel | Learning goal |
Lizenzgeber | Licensor |
Lizenzgebühr | License fee |
Lizenznehmer | Licensee, License holder |
Lizenzvereinbarung | Licensing agreement |
Lizenzvertrag | Licensing agreement |
Mal-/Zeichenprogramm | Drawing Tool |
Marke (gesetzlich geschützt) | Registered trademark |
materiell förderndes Mitglied | sponsoring (board) member |
Messbarkeit | Commensurability, Measurability |
Mitgliederversammlung | General meeting, Members’ meeting |
Modellierungswerkzeug | Modeling Tool |
Modul | Module |
Muster | Pattern |
Musterfamilie | Pattern language |
Mustersprache | Pattern language |
Nutzungsbeziehung | Uses relationship |
Nutzungsrecht | Rights of use |
Perspektive | Perspective |
Prinzip | Principle |
Prüfer | Examiner |
Prüfling | Examinee |
Prüfungsaufgabe | Examination task |
Prüfungsbogen | Examination sheet |
Prüfungsfrage | Examination question |
Prüfungsordnung | Examination rules and regulations |
Qualitätseigenschaft | Quality attribute, Quality characteristic, Quality feature |
Qualitätsmerkmal | Quality attribute, Quality characteristic, Quality feature |
Querschnittlich | Crosscutting |
Randbedingung | Constraint |
Rechnungsprüfer | Cash auditor |
Rechnungsprüfung | Cash audit |
Sachziele | Security Goals |
Satzung des Vereins | Articles of assocation |
satzungsgemäß | statutory |
Schatzmeister | Treasurer |
Schnittstelle | Interface |
Schnittstellenbeschreibung | Interface description |
Schnittstellendokumentation | Interface description |
Schrank (als Metapher für Template) | Cabinet (as methaphor for template) |
Schulungsanbieter | Training provider |
Schutzziele | Security Goals |
Schätzung | Estimation |
Sicht | Architectural view, View |
Sparsamkeit | Economicalness, Thriftyness |
Stellvertretender Vorsitzender | Deputy chairman |
Struktur | Structure |
Unternehmens-IT-Architektur | Enterprise IT architecture |
Untersuchung | Assessment |
Verantwortlichkeit | Responsibility |
Verein | Association |
Verfügbarkeit | Availability |
Vergleichbarkeit | Commensurability |
Verteilung | Deployment |
Verteilungsartefakt | Deployment unit |
Verteilungssicht | Deployment view |
Vertraulichkeit | Confidentiality |
Vorsitzender | Chairman |
Vorstand | Executive board |
Werkzeug | Tools |
Werkzeug-Material-Ansatz | Tools-and-material-approach |
Wirtschaftlichkeit | Economicalness, Thriftyness |
Zerlegung | Decomposition |
Zertifizierungsstelle | Certification authority, Certification body |
Ziel | Objective |
Categories
We use categories to add structure to the terms in the glossary. Every term might belong to zero or more of the following categories:
- Architecture-Pattern
- Name of an architecture pattern or -style from e.g. [Buschmann+96], [Fowler2003], [Hohpe+2003], [Quian+2010] or other fundamental references.
- Communication
- Used or needed to communicate information about arbitrary aspects of software architecture.
- DDD
- Keyword from the CPSA-Advanced curriculum “Domain Driven Design”
- Design-Pattern
- Name of a design pattern from e.g. [Gamma+95] or other fundamental sources.
- Design-Principle
- Name of a fundamental design principle.
- Foundation
- Terms required for or contained in the CPSA-Foundation curriculum.
- Improve
- Keyword from the CPSA-Advanced curriculum “IMPROVE”.
- iSAQB
- Official iSAQB terms, many of them used for contracts, association and other organizational stuff.
- Metric
- Defined measure to what degree a software system (or related process) possesses some property. Examples: Size (e.g. Lines-of-Code, cyclomatic complexity, coupling, mean-time-between-failure)
- Security
- Measures to reach basic principles like confidentiality, integrity, availability and non-repudation for data in an IT-system.
- ISO-IEC-IEEE-42010
- ISO/IEC/IEEE 42010:2011 Systems and software engineering � Architecture description. Note, a new version of the standard is expected to be published till the end of 2016.
References and Resources
Anderson-2008
Ross Anderson, Security Engineering - A Guide to Building Dependable Distributed Systems, 2nd edition 2008, John Wiley & Sons.
One of the most comprehensive books about information security available.
Bachmann+2000
Bachmann, Felix/Bass, Len/Carriere, Jeromy/Clements, Paul/Garlan, David/Ivers, James/Nord, Robert/Little, Reed. Software Architecture Documentation in Practice, Special Report CMU/SEI-2000-SR-004, 2000.
Bass+2012
Bass, L/Clements, P/Kazman, R.: Software Architecture in Practice
3rd edition, Addison-Wesley, 2012. Although the title suggests otherwise, a quite fundamental (and sometimes abstract) book. The authors have a strong background in ultra-large scale (often military) systems - so their advice might sometimes conflicts with small or lean kinds of projects.
Brown-2015
Brown, Simon: Software Architecture For Developers,
https://leanpub.com/software-architecture-for-developers Leanpub Publishing. Very practical and pragmatic.
Buschmann+1996
Also known as POSA-1.
Buschmann, Frank/Meunier, Regine/Rohnert, Hans/Sommerlad, Peter: A System of Patterns: Pattern-Oriented Software Architecture 1, 1st edition, 1996, John Wiley & Sons.
Most likely the most famous and groundbreaking book on architecture patterns.
Buschmann+2007
Also known as POSA-4.
Buschmann, Frank/Henney, Kevlin/Schmidt, Douglas C.: Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, Volume 4, 2007, John Wiley & Sons.
Describes a pattern language for distributed computing that guides readers through the best practices and introduce them to key areas of building distributed software systems. The book connects hundreds of stand-alone patterns, pattern collections, and pattern languages from the existing body of literature found in the POSA series.
Buschmann+2007b
Also known as POSA-5.
Buschmann, Frank/Henney, Kevlin/Schmidt, Douglas C.: Pattern-Oriented Software Architecture: On Patterns and Pattern Languages, Volume 5, 2007, John Wiley & Sons.
A meta-explanation, addresses the question of what a pattern language is and compares various pattern paradigms.
Clements+2002
Clements, Paul/Kazman, Rick/Klein, Mark: Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2001.
Clements+2010
Clements, Paul/Bachmann, Felix/Bass, Len/Garlan, David/Ivers, James/Little, Reed/Merson, Paulo/Nord, Robert. Documenting Software Architectures: Views and Beyond, 2nd edition, Addison Wesley, 2010
Evans-2004
Evans, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software, 1st edition, Addison-Wesley, 2004.
Fowler-2003
Fowler, Martin: Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.
Great support for building information systems.
Gamma+1994
Gamma, Erich/Helm, Richard/Johnson, Ralph/Vlissides, John M. Design Patterns: Elements of Reusable Object-Oriented Software, 1st edition, 1994, Addison-Wesley, 1994.
A classic on design patterns.
GoF (Gang of Four)
See Gamma+1994
Gorton-2011
Gorton, I. Essential Software Architecture, 2nd edition, Springer, 2011
Hargis+2004
Hargis, Gretchen/Carey, Michelle/Hernandez, Ann: Developing Quality Technical Information: A Handbook for Writers and Editors, IBM Press, 2nd edition, Prentice Hall, 2004.
If you need to write lots of documentation, you should have a look at this book.
Hofmeister+2000
Hofmeister, Christine/Nord, Robert/Soni, Dilip: Applied Software Architecture, 1st edition, Addison-Wesley, 1999
Hohpe+2003
Hohpe, G/Woolf, B: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison Wesley, 2003.
A very important book and timeless book for people creating integrated systems.
Kelly+2009
Steven Kelly and Risto Pohjonen: Worst Practices for Domain-Specific Modeling IEEE Software, volume 26, No. 4 July/August 2009, p22-30.
Authors explain several bad practices of domain modeling and give advice how and why to avoid those.
Kruchten-1995
Kruchten, Philippe. The 4+1 View Model of Architecture, IEEE Software, volume 12 (6), pp 45-50, 1995.
Martin-SOLID
Martin, Robert C: S.O.L.I.D.
S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin. Some of the original papers have been moved around onto various locations - see the following:
- Wikipedia on SOLID
- A nice Introduction by Samuel Oloruntoba
Martin-2003
Martin, Robert C: Agile Software Development: Principles, Patterns and Practices, Prentice Hall, 2002
McGraw-2006
Garry McGraw, “Software Security - Building Security In”, Addison-Wesley 2006
Covering the whole process of software design from a security perspective by the means of risk management, code reviews, risk analysis, penetration testing, security testing nad abuse case development.
Parnas-1972
Parnas, David: On the criteria to be used in decomposing systems into modules”, Communications of the ACM, volume 15, issue 12, Dec 1972
One of the most influential articles ever written in software engineering, introducing encapsulation and modularity.
POSA-1
Pattern-Oriented Software Architecture, Volume 1. See Buschmann+1996.
POSA-2
Pattern-Oriented Software Architecture, Volume 2. See Schmidt+2000.
POSA-4
Pattern-Oriented Software Architecture, Volume 4. See Buschmann+2007.
POSA-5
Pattern-Oriented Software Architecture, Volume 5. See Buschmann+2007b.
Quian+2010
Qian, K/Fu, X/Tao, L/Xu, C/Herrera, J: Software Architecture and Design Illuminated, 1st edition, Jones and Bartlett, 2010.
Well-structure and readable collection of architecture styles and patterns.
Rozanski+2011
Rozanski, Nick/Woods, Eoin: Software Systems Architecture - Working with Stakeholders Using Viewpoints and Perspectives, 2nd Edition, Addison Wesley 2011.
Presents a set of architectural viewpoints and perspectives.
RMIAS-2013
Yulia Cherdantseva, Jeremy Hilton, A Reference Model of Information Assurance & Security, 2013 Eight International Conference on Availability, Reliability and Security (ARES), DOI: 10.1109/ARES.2013.72 , http://users.cs.cf.ac.uk/Y.V.Cherdantseva/RMIAS.pdf
Conference Paper of Yulia Cherdantseva and Jeremy Hilton describing the RMIAS.
Schmidt+2000
Also known as POSA-2.
Schmidt, Douglas C/Stal, Michael/Rohnert, Hans/Buschmann, Frank. Pattern-Oriented Software Architecture, volume 2: Patterns for Concurrent and Networked Objects, Wiley & Sons, 2000
Schneier-1996
Bruce Schneier, Applied Cryptography, 2nd Edition 1996, John Wiley & Sons
Comprehensive suervey of modern cryptography.
Shaw+1996
Shaw, Mary/Garlan, David: Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996
Starke-2016
Starke, Gernot: Effective Software Architectures: iSAQB CPSA-Foundation©️ Certification Study Guide Leanpub, 2016. Available online https://leanpub.com/esa42.
A study guide for the CPSA-Foundation examination, not a comprehensive textbook!
Appendix A: The iSAQB e.V. Association

The International Software Architecture Qualification Board (iSAQB e.V., http://isaqb.org) is a non-profit organization with members from industry, development and consulting firms, education, academia and other organizations.
It is established as an association (e.V.) according to German law with the following objectives:
- Creating and maintaining consistent curricula for software architects.
- Defining certification examinations based upon the various CPSA curricula
- Ensuring high quality of teaching for software architects
- Ensuring a high quality of its software architecture certifications
iSAQB defines and prescribes training and examination regulations, but does not carry out any training or examinations itself. iSAQB trainings are carried out by (licensed) training and examination organizations.
iSAQB monitors and audits the quality of these trainings and all associated processes (e.g. certification procedures).
Appendix B: About the Authors
Gernot Starke

Dr. Gernot Starke (innoQ Fellow) is co-founder and longstanding user of the (open source) arc42 documentation template. For more than 20 years he works as software architect, coach and consultant, conquering the challenges of creating effective software architectures for clients from various industries.
In 2008 Gernot co-founded the International Software Architecture Qualification Board (iSAQB e.V.) and since then supports it as an active member.
2014 he founded the (open source) Architecture Improvement Method aim42.
Gernot has authored several (German) books on software architecture and related topics.

Gernot studied computer science at the Institute of Technology in Aachen (RWTH Aachen) and finished with a Diploma. He then worked as a developer and consultant for smaller software companies, before coming back to university for international research on methodical software engineering. 1995 he received his PhD from Johannes Kepler University of Linz, Austria (Prof. Gerhard Chroust for his thesis on “Software Process Modeling”.
He then joined Schumann AG in Cologne and did consulting and development work for several years. He became technical director of the “Object Reality Center”, a joint-venture of Sun Microsystems and Schumann Consulting AG and lead the first European Java Project (the Janatol project for Hypobank in Munich).
Since then he has consulted and coached numerous clients from various domains, mainly finance, insurance, telecommunication, logistics, automotive and industry on topics around software engineering, software development and development process organization.
Gernot was an early adopter of the agile movement and has successfully worked as Scrum master in agile projects.
He lives in Cologne with his wife (Cheffe Uli) and his two (nearly grown-up) kids, two cats and a few Macs.
Matthias Bohlen
Matthias Bohlen, independent expert for effective product development, started his career as a software developer in 1980. He wrote compilers for the MC68020 processor by Motorola which was quite a revolutionary device in those days where there was no IBM PC, yet. And the compilers really sold well.
Later, Matthias joined a CAD/CAM software company with 8 people and 4000 customers – this was product development from the ground up! 8 years later, after being a software developer, consulting projects were done with the CAD/CAM system, and Matthias discovered that he enjoyed to do be a consultant and work with customers.

After a few years at another 130-people consulting company, in 2001 in the middle of the dot-com bubble, he decided that it was now time to become his own boss and started to work as a freelance software architect and developer.
Since then, Matthias has worked with countless software teams, helping them to get working software out the door without losing their mind. This is what he still does today.
In times where Matthias felt his mind could use some excitement, he founded AndroMDA, an open source project and (as a co-founder with Michael Mahlberg) the Limited WIP Society Cologne, a community of Kanban practitioners.
Matthias is an active member of the International Software Architecture Qualification Board, writes a blog, is being known in the Lean/Agile field, worked as an editor for OBJEKTspektrum, regularly writes for Business Technology Magazine and speaks at conferences for software development. And he even thinks about founding another startup company – but that’s a different story.
Phillip Ghadir
Member of the board of innoQ Deutschland GmbH. Since many years, Phillip consults clients from various industries in topics around software-architecture, technology and development. He co-founded the iSAQB and regularly conducts trainings on software-architecture.
Carola Lilienthal

Dr. Carola Lilienthal is software architect at and co-founder of the WPS Workplace-Solutions. For 20 years she has been working as a developer, project manager, coach, consultant and architect. Carola was an early adopter of Domain-Driven Design and agile movement and has successfully worked for numerous clients from various domains, mainly finance, insurance and logistics.

Carola studied computer science at the University of Hamburg and finished with a diploma in 1995. She then worked for nine years as a developer and consultant for a small company, before coming back to university for international research on software architecture. In 2008 she received her PhD from University of Hamburg, Germany (Prof. Christiane Floyd for her thesis on “Complexity of Software Architecture”).
Since 2003, she has been analyzing software systems in Java, C++, C#, PHP, ABAP and gives advice to development teams how to improve the sustainability of their code. Carola speaks regularly on conferences and has written various articles as well as a book on sustainable software architecture.
Since 2008 Carola has been supporting the International Software Architecture Qualification Board (iSAQB e.V.) as an active member.
She lives in Hamburg with her French husband and her grown-up son.
Mahbouba Gharbi
Mahbouba Gharbi is CIO of iTech Progress, book author and conference speaker.

Several years ago Mahbouba became president of the iSAQB. She lives in Mannheim with her family.
Michael Mahlberg
Michael Mahlberg runs his own method consultancy in Germany and spends most of his time supporting clients in their quest for more effective ways to work. Mostly by applying lean and agile concepts.

Running his own computer and software related companies since he was 18, he quickly came to realize that software architecture and (development) processes are in a way timeless aspects of the craft.
In the late eighties of the 20th century he started to incorporate these aspectts into his business activities and has worked on software architecture in large scale systems for industries as diverse as media, aerospace, insurance, public sector, telco etc.
Nowadays a lot of his work focuses on processes and human interactions – a field in which he engages both professionally as well as pro bono (for example he is one of the people who started and run the Limited WIP Society Cologne).
Michael’s architectural work therefore tends to be dealing with the impact(s) and implications of architectural and process decisions on each other and the relative optimization strategies.
Ulrich Becker
Ulrich Becker works as principal consultant at Method Park, focussing on software architecture and application lifecycle management.

Ulrich studied computer science at the University of Hamburg and the University of Erlangen-Nürnberg. He received his PhD from the University of Erlangen-Nürnberg in 2003 for his work on model-based distribution configuration. He then became group leader for the adaptive system software group at Fraunhofer IIS.
Since 2005 Ulrich works as a trainer, consultant and coach at Method Park where he supports his clients in improving their development processes and methods. Most of his clients are from the automotive industry or other heavily regulated industries.
Ulrich is a founding member of iSAQB e.V. where he contributes to the foundation level and advanced level working groups. He lives in Erlangen with his family.
Simon Kölsch
Simon Kölsch works as a senior consultant at innoQ with a focus on web architecture and security.

Simon is enthusiastic about solutions beyond the classical monolithic enterprise application, covering the architecture of distributed systems and their infrastructure, logging and monitoring.
He is not committed to one specific technology or programming language, but has a strong JVM background.
Appendix C: Also From The Authors
Communicating Software Architectures
This practical guide shows how you can effectively apply the practical and well-proven arc42 template to design, develop and document your software architecture.

It contains more than 200 practical tips how to improve your architecture communication and documentation:
- immediately actionable tips
- arc42 for practical software development
- effective communication and documentation of software architectures
- arc42 to construct, design and implement new systems
- arc42 to document existing system
- arc42 for { large | medium | small } systems
- tools for arc42: wikis, asciidoc, modeling tools an others
- frequently asked questions around arc42
You find it on https://leanpub.com/arc42inpractice.
arc42 by Example

It contains the (arc42-based) documentation of several practical, real-life software architectures:
- A large scale CRM system with incredibly flexible configuration options.
- An (open source) web-based system to track all kinds of biking activities.
- A chess engine, optimized for understandability. Supports the full FIDE chess rules.
- A small (open source) HTML semantic checker
- and some more…
You find it on https://leanpub.com/arc42byexample.
Appendix D: About our Cause

All royalties of this book are donated to the EFF. By paying for this book, you support their cause:
“The Electronic Frontier Foundation is the leading nonprofit organization defending civil liberties in the digital world. Founded in 1990, EFF champions user privacy, free expression, and innovation through impact litigation, policy analysis, grassroots activism, and technology development. We work to ensure that rights and freedoms are enhanced and protected as our use of technology grows.
Even in the fledgling days of the Internet, EFF understood that protecting access to developing technology was central to advancing freedom for all. In the years that followed, EFF used our fiercely independent voice to clear the way for open source software, encryption, security research, file sharing tools, and a world of emerging technologies.
Today, EFF uses the unique expertise of leading technologists, activists, and attorneys in our efforts to defend free speech online, fight illegal surveillance, advocate for users and innovators, and support freedom-enhancing technologies.
Together, we forged a vast network of concerned members and partner organizations spanning the globe. EFF advises policymakers and educates the press and the public through comprehensive analysis, educational guides, activist workshops, and more. EFF empowers hundreds of thousands of individuals through our Action Center and has become a leading voice in online rights debates.
EFF is a donor-funded US 501(c)(3) nonprofit organization that depends on your support to continue fighting for users.”
(Quote from eff.org/about)
Notes
1The documentation found in https://github.com/isaqb-org/glossary contains all information required to generate the translation tables. Currently, only English and German are supported. The translation tables are maintained in JSON format, suggestions for improvements are highly welcome!↩
2133 english terms, generated on Oktober/04/2016↩