0.

Introduction
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

tectrain | Zied Chtioui

Blended-Learning-Workshop
in preparation for the CPSA-F® certification
CPSA-F-C0_v1.0.0-EN-1_2023-08-15
Contributors and Acknowledgements

Author Further contributions and improvements

‣ Alexander Lorz

Co-authors
‣ Bernd Hauck, Dehla Sokenou

Reviewers
‣ Peter Götz, Peter Hruschka, Ulrich Becker, Roger Rhoades

Slide contributions by
‣ ITech Progress GmbH
‣ iSAQB Working Group Universities
Jörg Hettel, Michael Sperber,
Benjamin Wolf, Holger Tiemeyer
We appreciate your feedback and suggestions for
Design and Support improvement. Please contact us by e-mail:
‣ Änne Fitzner, Ricarda Pilz, Mirko Hillert [email protected]

iSAQB CPSA-F – 0. Introduction 2

Overview

Introduction: Training Provider & Trainer

Examination Procedure

What Is Software Architecture?

Why Should Software Architecture Be Performed?

iSAQB and CPSA Certification

Training Contents and Structure

iSAQB CPSA-F – 0. Introduction 3

Introducing Your Training Provider resp.
University
tectrain
‣ Swiss IT consulting and training company
‣ iSAQB Foundation and Advanced Level
‣ ISAQB and IREB licensed
We provide solutions for
‣ Strategy development
‣ Organizational consulting
‣ Change management
[email protected]

iSAQB CPSA-F – 0. Introduction 4

About Your Trainer
Zied Chtioui
‣ Lead Software Architect @Linedata (Multinational fintech company)
‣ iSAQB Member and Accredited Trainer
[email protected] | [email protected]

Responsabitlies:
-Crafting strategic solutions that empowers our Fund accounting products
-Designing and leading the most critical project, full of risk and uncertainties
-Setting the technological roadmap for the next 2, 5 and 10 years
-Mentoring and training…
Philosophy:
A result-driven approach with purpose and rationale-driven decision-making.

Interest
Chess, Piano, cooking, Brain games, Personal development staff…

iSAQB CPSA-F – 0. Introduction 5

Examination Procedure
• External examiner
• 75 minutes for native speakers, 90 for non-
native speakers
• Approx. 44 questions, multiple-choice only ‣ Be there 10 minutes in advance
• Exam types: On-site (paper-based or ‣ Have a photo ID ready
tablet), Online Remote Proctoring, Test ‣ Take your time
Center − Read questions carefully
− Review your answers
• 1-3 points/question, 60% to pass
‣ “Best fit” questions
‣ Incorrect answers reduce points given for
that specific question. Lowest number of ‣ Ask questions during exam
points for each question is 0 points. ‣ Use notes, books, phone, etc.
‣ Blank answers: no points will be ‣ Leave room during exam
given or subtracted. ‣ Disseminate content of exam
When in doubt, answers can be omitted.
iSAQB CPSA-F – 0. Introduction 6
Certification Benefits

Facilitates the selection Documentation of skills,

of suitable applicants qualification and competencies

Certification?

Interesting for potential

Keep up-to-date with employers and customers
new and continuously
changing technologies
Strong demand
in IT sector

iSAQB CPSA-F – 0. Introduction 7

 “Life was simple
What Is Software Architecture? before World War II.
Origin and Meaning of the Term After that,
Software crisis in the 1960ies we had systems.”
‣ Increasing size and complexity of — Grace Hopper
software
‣ High failure rate of projects
‣ Engineering solutions required

“Real” architecture
‣ Planning, designing & constructing
buildings
‣ Greek: arkhi-chief + tekton builder
‣ Provide rules and structure

iSAQB CPSA-F – 0. Introduction Fig. C0.1: Colossus by Jon

8 Callas, flick
Do We Really Need
Software Architecture?
Too expensive.
Slows us down.
The truth is in the code!
Good coders don‘t need this.
It‘s just management <#$@>!
Just get it done.
Make it pretty later on!

iSAQB CPSA-F – 0. Introduction Fig. C0.2: Winchester Mystery House (modified from image by HarshLight,
9 flickr)
What Is “Good” Architecture?

Fig. C0.4: piqsels

Fig. C0.3: by TREEAID, flickr Fig. C0.5: piqsels Fig. C0.6: piqsels
iSAQB CPSA-F – 0. Introduction 10
iSAQB e.V.

International Software Architecture Qualification Board

‣ Founded 2008, non-profit, volunteers
‣ Professionals from industry, consulting, training, academia
‣ Standardize training of software architects internationally
‣ Standardized scheme of knowledge (curriculum)
‣ Quality control for trainings and examinations

Trainings and exams are provided by a variety of separate, independent entities.

Quality control:
Contact [email protected] to provide anonymous and
confidential feedback independent of trainer and training provider.

iSAQB CPSA-F – 0. Introduction 11

CPSA-Training Certification Scheme

Foundation Level
‣ Discusses fundamental concepts
EXPERT

Advanced Level ADVANCED

‣ Evaluates in-depth knowledge in ARCEVAL AGILA WEB IMPROVE
selected areas
DDD FLEX ADOC REQ4ARC

Expert Level WEBSEC FUNAR EAM SOFT

‣ Under development EMBEDDED BLOCKCHAIN CLOUDINFRA

further information:
www.isaqb.org/certifications/ FOUNDATION

iSAQB CPSA-F – 0. Introduction 12

Agenda and Training Structure
Curriculum
Basic Concepts of Software
Architecture
Design and Development
of Software Architectures
Specification and Communication
of Software Architectures
Software Architecture and Quality
Examples of Software Architectures

iSAQB CPSA-F – 0. Introduction Fig. C0.7: Approximate Distribution of Learning Content 13

Agenda and Training Structure
Learning Goal Relevance

You should be able

R1 to put this topic into practice.
definitely

You should understand

R2 this topic.
maybe

You should be aware of this topic

R3 to learn more as required.
no

iSAQB CPSA-F – 0. Introduction 14

Agenda and Training Structure
Training Outline / Agenda
1. Basic Concepts 6. Additional design considerations
‣ Definition(s), Goals and Benefits ‣ Cross-Cutting Concerns, Interfaces
‣ Key Terms and Concepts ‣ Achieving Quality Goals

2. Roles, Responsibilities, and Activities of Architects 7. Design Approaches and Methods

‣ Expected Output and Results ‣ Architecture Development Approaches
‣ Role, Tasks, Responsibilities, Skills ‣ Architecture Design Methods

3. Deriving Quality Goals and Design Constraints 8. Documentation and Communication

‣ Requirements, Constraints, Influencing Factors
9. Software Architecture Evaluation
4. Design Principles ‣ Modelling and Describing Quality
‣ Architecture Evaluation
5. Patterns

iSAQB CPSA-F – 0. Introduction 16

 Course Prerequisites
Knowledge and Experience Prerequisites
Knowledge of higher Basics of
Practical experience programming languages algorithms
in software and data structures
development required
useful Practical experience in
object-oriented
Basic concepts of Prerequisites programming
software
modeling and abstraction
Experience in designing and
implementing client/server
Basics of UML systems, web applications,
Experience in
etc.
writing technical
documentation
iSAQB CPSA-F – 0. Introduction 17
Out of Scope:
What Not to Expect From This Training

Specific implementation technologies, frameworks, or libraries

Programming exercises or discussions about programming languages
Specific software development process models
Fundamentals of modelling or modelling notations (e.g., UML)
System analysis and requirements engineering → IREB
Software testing → ISTQB
Project or product management
Introduction to specific software tools

iSAQB CPSA-F – 0. Introduction 18

Recommended Reading,
Literature Recommendations
M. Gharbi, A. Koschel, A. Rausch:
L. Bass, P. Clements,
Software Architecture Fundamentals:
R. Kazman: Software
A Study Guide for the Certified
Architecture in Practice
Professional for Software Architecture®
Addison-Wesley, 2021.
– Foundation dpunkt.verlag, 2019.

M. Richards, N. Ford: G. Starke, A. Lorz: Software Architecture

Fundamentals of Software Foundation – 2nd edition - CPSA-F®
Architecture: An Engineering Exam Preparation Van Haren, 2023.
Approach O'Reilly, 2020.

N. Rozanski, E. Woods: Software

At least skim Glossary + Curriculum → exam preparation
Systems Architecture – Working
see [iSAQB-Glossary] and [iSAQB-Curriculum]
with Stakeholders Using
Viewpoints and Perspectives
More literature: www.isaqb.org/certifications/literature
Addison Wesley, 2011.

iSAQB CPSA-F – 0. Introduction 19

Summary
What Have We Covered So Far?

Introduction: Your training provider and your trainer

What can be expected from the exam?
Where does the term “Software Architecture” originate?
Yes, we need architecture to provide structure!
“Good” architecture depends on requirements and context.
iSAQB and certification path
Curriculum, training structure, organizational stuff
Prerequisites and Scope of the training

iSAQB CPSA-F – 0. Introduction 20

Please Introduce Yourself

Who are you?

What motivated you to take the class?
What do YOU expect from this training?

iSAQB CPSA-F – 0. Introduction Fig. C0.8: http://geek-and-poke.com/geekandpoke/2011/1/27/nosql.html 21

References

Table of Figures
‣ C0.1: Jon Callas. (2008). Colossus. www.flickr.com/photos/19745294@N06/2717063851. CC BY 2.0. Last visited: 2021-02-13
‣ C0.2: HarshLight. (2009). Winchester Mystery House (modified, cropped). https://www.flickr.com/photos/harshlight/3669393933. CC BY 2.0.
Last visited: 2023-04-16
‣ C0.3: TREEAID. (2006). Village granary near Fada, Burkina Faso. www.flickr.com/photos/53871588@N05/5092313365. CC BY 2.0. Last
visited: 2021-02-12
‣ C0.4: granary field Asturias Spain. www.piqsels.com/en/public-domain-photo-fbasa. CC0. Last visited: 2021-02-12
‣ C0.5: red granary Bydgoszcz mill island Poland. www.piqsels.com/en/public-domain-photo-fvzkq. CC0. Last visited: 2021-02-12
‣ C0.6: silo wheat storage wheat storage. www.piqsels.com/en/public-domain-photo-znymm . CC0. Last visited: 2021-02-12
‣ C0.7: iSAQB. (2020). Foundation Level Curriculum, Version 2019.2-EN from June 16, 2020. p.7. https://isaqb-org.github.io/curriculum-
foundation/foundation-curriculum-en.pdf. Last visited: 2021-02-12
‣ C0.8: Geek & Poke. (2011). How to write a CV. http://geek-and-poke.com/geekandpoke/2011/1/27/nosql.html. CC BY 3.0. Last visited: 2021-
02-12.

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 0. Introduction 22

References

Websites
‣ [iSAQB1]: International Software Architecture Qualification Board – iSAQB. http://www.isaqb.org/. Last visited: 2021-02-12
‣ [iSAQB2]: International Software Architecture Qualification Board – iSAQB. www.isaqb.org/certifications/. Last visited: 2021-02-12
‣ [iSAQB-Curriculum] International Software Architecture Qualification Board – iSAQB. https://public.isaqb.org/curriculum-foundation/.
Last visited: 2023-04-16
‣ [iSAQB-Glossary] iSAQB Glossary of Software Architecture Terminology. https://public.isaqb.org/glossary/. Last visited: 2023-04-16
‣ [iSAQB4]: International Software Architecture Qualification Board – iSAQB. www.isaqb.org/certifications/literature. Last visited: 2021-02-12
‣ [IREB1]: International Requirements Engineering Board – IREB. http://www.ireb.org/. Last visited: 2021-02-12
‣ [ISTQB1]: International Software Testing Board – ISTQB. http://www.istqb.org/. Last visited: 2021-02-12

iSAQB CPSA-F – 0. Introduction 23

1. Basic Concepts
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C1_v1.0.0-EN-1_2023-07-26
Overview

Software Architecture: Definition(s)

Architecture in the Software Life Cycle

Goals and Benefits

Key Terms and Concepts

Architectural Domains

Conceptual Model of Architecture Description

How Does a Software Architecture Take Form?

iSAQB CPSA-F – 1. Basic Concepts 25

What Are Software-Intensive Systems?
IEEE 24765-2017

Software-intensive system
A system for which software is a major technical
challenge and is perhaps the major factor that
affects system schedule, cost, and risk

System
Combination of interacting elements organized
to achieve one or more stated purposes

Software
Computer programs, procedures and possibly
associated documentation and data pertaining
to the operation of a computer system

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.1: (some exemplary) dimensions of a software system, from [Gharbi+2019] 26
What Is Software Architecture?
Significance of Software Architecture for Software-Intensive Systems

Software architecture is about the organization of a software

system and the impact it has on the system's qualities
‣ Modifiability, security, performance, etc.

Software architecture provides structure to the system, influences

its quality attributes, and constrains the system
‣ Often it is orthogonal to the system's functionality

Software architecture is the result of numerous design decisions

‣ Make design decisions explicit
‣ Explain requirements and rationale behind design decisions

iSAQB CPSA-F – 1. Basic Concepts 27

Definitions of Software Architecture

Software Architecture ANSI/IEEE 1471

The fundamental organization of a system embodied
in its components, their relationships to each other
and to the environment, and the principles guiding its
design and evolution.

Architecture ISO/IEC/IEEE 42010

Fundamental concepts or properties of a system in its
environment embodied in its elements, relationships,
and in the principles of its design and evolution.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.2: Key Terms in Definitions of Software Architecture 28
Definitions of Software Architecture

There are many other valid definitions of

software architecture.

Essential key concepts are

‣ Building blocks (components, packages, …)
‣ Relationships between building blocks
‣ Relationship building blocks ⇄ environment
‣ Principles, rules, and guidelines

iSAQB CPSA-F – 1. Basic Concepts 29

Software Architecture
as Part of the Software Life Cycle
“When is software architecture performed?”
Common software development processes
‣ Waterfall, Iterative, Agile, Model-driven, …

‣ One or more “design-intensive” phases

→ Primary focus of architectural activities

‣ But: architect’s tasks integrate into most other activities, e.g.

− Consider consequences of changes in requirements,
technologies, operations, or business goals
− Support developers, provide feedback on implementation

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.3: derived from [Gharbi+2019] 31

Software Architecture
as Part of the Software Life Cycle
Requirements Software Detailed Design
Architecture Klasse1 Klasse3

Design
Klasse2 Klasse4

Influencing Factors Realization

Operatio
nal
behavior
Temper Producti
ature vity
Sensor Niveau

Size / Softwar
complex e
ity of the Architect Type of
Softwar ures Architect
e ure
Architect
ure
Quality
Operatio of
nal
Architect
Aspects
ure

Project Planning Test

WWWWW

More detail on
WWWWW WWWWW
architecture
formation later
in this chapter.
This is not a linear process!
iSAQB CPSA-F – 1. Basic Concepts Fig. C1.3b: Architecture design as part of the SDLC 32
 Goals and Benefits
Principles for Good Architecture
useful
‣ Fulfill functional and quality
requirements
stable
‣ Reliable, mature, maintainable
graceful
venustas ‣ Well-structured design
firmitas

‣ Great user experience

utilitas

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.4: Caryatides 33

Goals and Benefits
What Is a “Good” Software Architecture?
Shows that functional and quality
requirements will or can be
Helps the stakeholders
fulfilled over the entire system life
to understand the system
cycle

Specifies necessary
Creates a meaningful implementation measures
division of components Good Software
‣ Abstraction from Architecture
Defines design guidelines to
complex details ensure conceptual integrity
‣ Isolate cross-cutting
concerns

Documents and provides rationale

for design decisions
iSAQB CPSA-F – 1. Basic Concepts 34
Objectives and Benefits of Software
Architecture
Objectives Benefits
‣ Determine high-level system structure ‣ Ensure that requirements and quality
‣ Select the central design paradigms goals are met
‣ Map functionality to system building ‣ Ensure a consistent solution:
blocks similar problems are solved similarly
‣ Achieve quality requirements ‣ Ensure understandability of the system
‣ Support the creation, maintenance, and design decisions
and implementation of the system ‣ Focus on system longevity and
‣ Help stakeholders to understand the facilitates system maintenance
system ‣ Support the entire life cycle of a
software system
‣ Enable reuse

iSAQB CPSA-F – 1. Basic Concepts 35

Short- and Long-Term Goals

Project Goals
Architecture Goals

Short-term goals Long-term goals, e.g.

‣ Implement functional ‣ Fulfill quality requirements
requirements (e.g., maintainability, extensibility)
‣ Implement quality goals over the entire software life cycle
‣ Deliver high-quality ‣ Business investments
software on time and
(infrastructure, know how)
within budget

iSAQB CPSA-F – 1. Basic Concepts 36

Key Terms and Concepts

Before we proceed, …

… a shared understanding of the key terms and concepts is required.

iSAQB CPSA-F – 1. Basic Concepts 37

Key Terms and Concepts
Building Block / Component
consists of

Building Block

Programming Library, Configuration,

Package
Construct Framework Declaration

Class, Layout /
Component, Data Structure,
Module, Script Mapping
Program DB-Table
Function Definition

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.5: Examples of building blocks [Gharbi+2019] 38
Key Terms and Concepts
Building Block / Component
Unit of hierarchical (de)composition and encapsulation
Component ISO/IEC 25010:2011
“entity with discrete structure, such as an assembly or software module, within a
system considered at a particular level of analysis”
Components provide (static) structure
Different sizes
‣ Small (data structure, function)
‣ Medium (library)
‣ Large (framework, container cluster)

iSAQB CPSA-F – 1. Basic Concepts 39

Key Terms and Concepts
Interface
Components “do things” with each other → dynamic system behavior
Interface ISO/IEC 2382:2015
“shared boundary between two functional units, defined by various characteristics
pertaining to the functions, physical signal exchanges, and other characteristics”

“Contract” that components must abide to.

Well-defined access point to a component (or system).
Provide a precise and comprehensive description of interfaces:
‣ Syntax, data structures, functional behavior, error behavior, quality characteristics,
technologies, protocols, constraints, semantics, …

iSAQB CPSA-F – 1. Basic Concepts 40

Key Terms and Concepts
Interface
Interfaces imply connections, relationships, and
dependencies between components
→ YOU can decide how they will be structured!
What building blocks use other building blocks?
Which building blocks depend on other building blocks?

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.6: derived from katemangostar 41

Key Terms and Concepts
Black Box / White Box
What do you know about the internal properties of a component?
What do you WANT to know?
What CAN you specify?

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.7: Black and White Box Components 42
Key Terms and Concepts
(De-)Composition and Refinement
Components can be further decomposed
into subcomponents according to, e.g.,:
‣ Important data types
‣ Layers
‣ Customer journey
‣ Smallest piece of self-contained functionality
‣ ...

Refinement should be free of redundancy

Generally (but not always):
‣ Black box components with strong dependencies
→ aggregated in a common white box component.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.8: derived from [Gharbi+2019] 43

Key Terms and Concepts
Stakeholder Concern and Cross-Cutting Concern
Stakeholder concern ISO/IEC/IEEE 15288:2015
“interest in a system relevant to one or more of its stakeholders”
‣ Abstract concept for: What interests or bothers someone about a system or a component.
(e.g., goals, interests, required functionality, expectations, fears, need for regulation, …)
‣ Separating concerns is good for you.
Note the different meanings!
Stakeholder concerns and cross-
Cross-cutting concern cutting concerns are both terms
‣ Impacts many components of the system used in software architecture but
are independent of one another.
‣ Difficult to isolate
‣ Often related to technical constraints or solutions or to functionality that is “required in many
places” (e.g., logging, caching, persistence, …)

We will come back to Separation of Concerns (SoC) and how to deal with cross-cutting
concerns later.
iSAQB CPSA-F – 1. Basic Concepts 44
Key Terms and Concepts
Stakeholder
Stakeholder ISO/IEC/IEEE 24765:2017
‣ “Individual or organization having a right, share, claim, or interest in a system or in its
possession of characteristics.”
‣ “An individual, group, or organization who may affect, be affected by, or perceive itself
to be affected by a decision, activity, or outcome of a project.”

Essentially: Concept for grouping people and organizations into categories according to
their concerns and influence.

More on stakeholders, stakeholder analysis, and the documentation of stakeholders in

later chapters.

iSAQB CPSA-F – 1. Basic Concepts 45

Key Terms and Concepts
Functional vs. Quality Requirements
Stakeholder concerns (usually) will lead to
requirements

Be precise about
“What is this requirement related to?”
‣ Requirements are interconnected
‣ A requirement for one thing can lead to
a requirement for another.

Distinguish between
‣ Functional requirement
‣ Quality requirement
‣ Constraints More on requirements and
constraints in Chapter 3.
iSAQB CPSA-F – 1. Basic Concepts Fig. C1.9: Requirements 46
Key Terms and Concepts
Functional vs. Quality Requirements

Functional Requirement Quality Requirement

What shall X do? How shall X be?

“required feature” “required constraint”

When A happens, the system The system (or architecture or component)

shall do B. shall be secure (or maintainable or
efficient or …)

… do happen and
can be managed CHANGES … might happen and can
imply significant risks.

iSAQB CPSA-F – 1. Basic Concepts 47

Key Terms and Concepts
Common Quality Requirements and Their Meanings
Performance
‣ Work done per unit of time.
Efficiency
‣ Work done in relation to resources used.
Scalability
‣ Potential to increase performance
‣ Scalability will not automatically increase performance but will allow you to do so.
‣ Horizontal scaling vs. vertical scaling
Elastic Scalability
‣ Ability to increase performance when needed and to decrease it when it’s no longer required
to save on resources.
‣ Systems might be scalable without providing elastic scalability.

iSAQB CPSA-F – 1. Basic Concepts 48

Key Terms and Concepts
Complexity
Complexity ISO/IEC/IEEE 24765:2017
“degree to which a system’s design or code is difficult to
understand because of numerous components or
relationships among components”

→ Amount of human effort required to understand

something in order to change or extend it.
Complexity kills software systems.
Complexity does not go away on its own.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.10: http://geek-and-poke.com/geekandpoke/2012/4/16/sometimes-its-that-simple.html 49

Key Terms and Concepts
Application Domain / Business Domain
Domain ISO/IEC/IEEE 24765:2017
1. “distinct scope, within which common characteristics are exhibited”
2. “problem space”
3. “area of knowledge or activity characterized by a set of concepts and terminology
understood by practitioners in that area”
Each of these meanings will apply.

Application Domain / Business Domain

‣ “Parts of the real world” that are modelled and/or governed by our IT-System
‣ “WHICH part do we describe?” – “WHAT happens in the real world?”
‣ Technology agnostic: regardless of the IT systems we use for this
It is generally a good idea to have a computation-independent description of a system.

iSAQB CPSA-F – 1. Basic Concepts 50

Key Terms and Concepts
Business Logic
Business Logic (aka “Domain Logic”)
‣ Model/encode real-world entities and processes.
‣ How do real-world entities interact?
‣ Enforce consistency of our model of reality.

Separate business logic from

implementation details and technologies!
presentation layer

logic layer
Business logic
data layer
goes here.

iSAQB CPSA-F – 1. Basic Concepts 51

Key Terms and Concepts are composed of
Summary
(de-)composition
access Component
Interface =
via Building Block hard to isolate
describe as impacts
multiple
Cross-cutting
Black & White Box
Concern
separate Performance
Efficiency
lead to Functional ←→ Quality
Stakeholder (Elastic) Scalability
Requirement Complexity
Concern
has describes
models (Application)
Stakeholder Business Logic
Domain
iSAQB CPSA-F – 1. Basic Concepts 52
 Architectural Domains
Let us step back and consider architecture as a general term.
What Do We Mean by
“Architectural Domains”?

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.11: Architectural Domains 54

What Do We Mean by
“Architectural Domains”?
Architectural “domains” are problem spaces with a distinct scope.
→ See the definitions of the term “domain”.

At first, we will briefly introduce architectures of systems where …

‣ software-intensive systems are just one part of a larger context; or
‣ interdependencies between software-intensive systems exist
(e.g., hardware, enterprises, infrastructure, …).

Afterwards we will describe problem spaces (domains) within software architecture:

‣ Different levels or aspects of an architecture description.
‣ Essentially, it’s about “sorting different aspects of software architecture into boxes” and the
question of “Which sorting criteria do we want to use?”

iSAQB CPSA-F – 1. Basic Concepts 55

 Architectural Domains
Software architecture is only one architectural domain among others.
Other Architectural Domains
Beyond Software Architecture
Dern’s architecture pyramid establishes a
hierarchical relationship between different
architectural domains of an enterprise.

software
Other architectural domains: architecture
‣ Enterprise IT architecture goes here
‣ Business process architecture
‣ Hardware architecture
‣ Processor architecture
‣ …

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.12: Dern‘s Architecture Pyramid, illustration derived from [Lehner+2007] 57
Other Architectural Domains
Subdomains of Enterprise Architecture
Enterprise Architecture
Business Architecture
‣ Goals, strategies, KPIs ‣ Processes
‣ Organization (structure, skills, knowledge, location) ‣ Partners and suppliers

Information Architecture Application Architecture

‣ Business objects ‣ Applications (landscape)
‣ Information flow ‣ Interfaces Software Architecture
(per application)
‣ Data governance ‣ System-wide integration

Technology or Infrastructure Architecture

‣ Software and hardware servers and processors
‣ Storage and network components
‣ Data centers

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.13 by Roger Rhoades, according to [TOGAF2018] 58
Architectural Domains
Domains Within Software Architecture.
Architectural Domains
Functional vs. Technical Architecture

WHAT does the IT system HOW does it work from the

do from the perspective of the perspective of someone who is
application domain? implementing or operating the
system?

Features and functionalities Technologies and frameworks

Transfer $money Use framework X to map

from account accounts to DB tables and
Foo to account bar. ensure transaction safety.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.14 60

Architectural Domains
Abstract vs. Concrete Architecture
Which rules help to structure and constrain functional and technical components?

Use microservices that

communicate via an event bus.

The following microservices

must be provided: …

Which concrete functional and technical components can be identified?

iSAQB CPSA-F – 1. Basic Concepts 61
Architectural Domains
“Levels” or “Aspects” of Software Architecture
abstract

Architectural Technical
style infrastructure
ABSTRACTION

rules and constraints

Functional Technical
architecture architecture
level level
concrete

functional PERSPECTIVE technical

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.15: derived from [Gharbi+2019] 62

 Architectural Domains
How to describe those Conceptual Model of Architecture Description
aspects (subdomains)
of the architecture of
a specific IT system? .
Describing Software Architecture
What Do We Need to Describe?
Different software architecture design methods provide their individual
approaches for categorizing information:
‣ ADD, S4V, RUP 4+1, BAPO, ASC

What do those approaches have in common?

Is there a generic, universal approach?
→ Which aspects of software architecture do we want to describe?
→ What is the relation between those aspects?
→ How do we organize all those aspects and their relations in a useful and efficient way?

iSAQB CPSA-F – 1. Basic Concepts 64

Conceptual Model of Architecture Description

ISO/IEC/ IEEE 42010 :2011

(p 5, detail of fig. 2)

We want to organize
things into views.

What is a view?
iSAQB CPSA-F – 1. Basic Concepts Fig. C1.16 65
Conceptual Model of Architecture Description

ISO/IEC/ IEEE 42010 :2011

(p 5, detail of fig. 2)

Views consist of models.

What is a model?
iSAQB CPSA-F – 1. Basic Concepts Fig C 1.17 66
What Is a Model?

A model is a lie!
Fig. C1.18 Fig .C1.19

Abstraction of reality
‣ For specific purpose (viewpoint)
‣ Explain or predict reality
‣ Omit certain aspects of reality
‣ Reduced complexity Fig. C1.20 Fig. C1.21

Different kinds of models

‣ Graphs, XML, pseudo-code, informal, textual
description, …
Fig. C1.22 Fig. C1.23

iSAQB CPSA-F – 1. Basic Concepts 67

What Is a View?

“Sorts models into boxes”

‣ According to viewpoints

“Views are projections of the software

architecture”
[Gharbi et al., Software Architecture Fundamentals]

Which “boxes” do we need or use?

‣ Depends on architecture design method
(ADD, S4V, RUP 4+1, BAPO, ASC)
‣ Let’s apply a general approach in the
upcoming slides.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.24: illustration from [Gharbi+2019] 68

Software Architecture Views

context view

building-block view run-time view deployment view

More on these views in Chapter 8.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.25: Software Architecture Views 69
Architecture Formation
How is the architecture design created?
How does it evolve?

High-Level Overview
Architecture Formation
How Does a Software Architecture Take Form?
Prerequisites
‣ Essential quality requirements are known.
‣ (Core) functional requirements are known. ← “It depends”
‣ Most important influencing factors are known.

When?
‣ Starts at project begin.
‣ Continues during the development and maintenance of the system.

Formation
‣ Incremental refinement and extension.
‣ In small teams.
‣ Through experience and application of “best practices”.

iSAQB CPSA-F – 1. Basic Concepts 71

Architecture Formation
Systematic Design: An Idealized Design Cycle

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system Unfortunately, real projects
Clarify requirements
are a bit more complicated.
and influencing
factors

Review the Monitor the Communicate

End: architecture Implementation architecture
System
delivery

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.26: Systematic Design 72

Architecture Formation
The Architecture Influence Cycle
Feedback from the
design/implementation

Requirements, Design
Stakeholders,
Constraints

Implementation
Context, Architect Experience
Organization Developers gained

Feedback acquired by using

the system

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.27: The Architecture Influence Cycle according to [Starke2020] and [Bass+2021] 73
Architecture Formation
Iterative Development of Architectures
Architecture design is an iterative process! Architecture, stakeholders, and IT system
influence each other. Requirements and
Initially influencing factors can change.
‣ Analyze requirements
‣ Design a high-level architecture Influencing
Refine software architecture in iterations Requirements
factors
‣ Analyze requirements in more detail influences
‣ Consider feedback
‣ Extend software architecture changes Architecture changes
design
→ Identify design problems early
→ Deliver high-value functionality early Context &
Customer
stakeholders

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.28: Mutually Influencing Factors 74

Architecture Formation
IKIWISIs and the Twin Peaks Model

Beware of IKIWISIs!
“I know it when I see it.”

They are
everywhere!
But we can manage them.

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.29: derived from iconcheese Fig. C1.30 : The Twin-Peaks model, illustration derived from [Nus2001] 75
Architecture Formation
Refinement of Requirements
An architecture is the result of many design decisions.
Analyze and explicate requirements to derive architecture decisions from them!
Quantify requirements whenever possible, e.g.:
‣ Mean Time Between Failure (MTBF)
‣ Average response time, load behavior, and scalability
‣ Specification of quality scenarios
→ Not helpful: “often”, “many”, “safe”, “fast”
Consider system behavior in abnormal and fault situations
What are the things that you don’t know?
Do you know how stable your requirements are?
We come back to this in
more detail in Chapter 3.
iSAQB CPSA-F – 1. Basic Concepts 76
Architecture Formation
Consider the Future
Software architecture design is “informed clairvoyance”

Which requirements are likely to change in the future?

‣ System environment
‣ Extensions to the system
‣ Middleware, frameworks, technologies

Are my decisions sustainable?

‣ Remember the Y2K problem?

Always compare costs and benefits of decisions!

Avoid over-engineering!

iSAQB CPSA-F – 1. Basic Concepts 77

Architecture Formation
Is It Reasonable to Design the Architecture …

‣ … by meeting every Tuesday at 15:00 in the same meeting room?

‣ … isolated from the needs of customers, contractor, project

management, or implementation team?

‣ … on colorful marketing slides?

‣ … as an isolated aspect (e.g., Microservice, database …)?

iSAQB CPSA-F – 1. Basic Concepts 78

Architecture Formation
Is There a “Standard Approach”?
There are many industry-standard software architecture design methods, e.g.
ADD, S4V, RUP 4+1, BAPO, ASC
May or may not fit your project/application domain. → What do they have in common?

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.31: According to Hofmeister et al. “A general model of software architecture design …” [Hof2007] 79
Architecture Formation
The Software Life Cycle

iSAQB CPSA-F – 1. Basic Concepts Fig. C1.32: Versioned staged model for the software life cycle according to Rajlich and Bennett [Raj2000] 80
Basic Concepts
Summary / Wrap Up
What have we covered so far?
‣ Software-intensive systems, definitions of software architecture
‣ Software architecture as part of the software life cycle
‣ Objectives and benefits of software architecture, long-term vs short-term goals
‣ Key terms and concepts
‣ Architectural domains (within and external to software architecture)
‣ Conceptual model of architecture description, models and views
‣ Architecture formation

What’s next?
‣ Chapter 2: Roles and responsibilities of architects
‣ Chapter 3: How to derive quality goals and constraints from requirements

iSAQB CPSA-F – 1. Basic Concepts 81

References

Table of Figures
‣ C1.1: from [Gharbi+2019]
‣ C1.2: own work
‣ C1.3: derived from [Gharbi+2019]
‣ C1.3b: derived from ITech Progress slide deck
‣ C1.4: Caryatides (From the edition of Vitruvius by Fra Giocondo, Venice, 1511) ) as it appeared in Ten Books on Architecture by Vitruvius,
translated by Morris Hicky. (1914). Source: http://www.gutenberg.org/files/20239/20239-h/29239-h.htm. Author: Herbert Langford Warren &
Nelson Robinson. https://commons.wikimedia.org/wiki/File:Caryatides_from_the_edition_of_Vitruvius_by_Fra_Giocondo.jpg. CC0. Last
visited: 2021-02-11
‣ C1.5: ITech Progress slide deck, also published in [Gharbi+2019]
‣ C1.6: derived from katemangostar. (2020). Set geschäftsleute mit klemmbrettern Kostenlosen Vektoren. https://de.freepik.com/vektoren-
kostenlos/set-geschaeftsleute-mit-klemmbrettern_5562386.htm#page=4&position=35. CC0. Last visited: 2021-02-11
‣ C1.7: own work
‣ C1.8: derived from [Gharbi+2019]
‣ C1.9: own work
‣ C1.10: Geek & Poke. (2012). Sometimes it´s that simple. http://geek-and-poke.com/geekandpoke/2012/4/16/sometimes-its-that-simple.html.
CC BY 3.0. Last visited: 2021-02-11
‣ C1.11: own work
‣ C1.12: derived from [Lehner+2007]
‣ C1.13: by Roger Rhoades, according to [TOGAF2018]
‣ C1.14: own work
‣ C1.15: derived from [Gharbi+2019]
iSAQB CPSA-F – 1. Basic Concepts 82
References

Table of Figures
‣ C1.16: from ISO/IEC/ IEEE 42010 :2011 (p 5, detail of fig. 2)
‣ C1.17: from ISO/IEC/ IEEE 42010 :2011 (p 5, detail of fig. 2)
‣ C1.18: mallard water bird duck blue. https://www.piqsels.com/en/public-domain-photo-snyzh. CC0. Last visited: 2021-02-12
‣ C1.19: A. Konby (?). (1899). Imaginary rendering of Vaucanson's digesting duck in Scientific American. https://en.wikipedia.org/wiki/Digesting_Duck#/media/File:Digesting_Duck.jpg. Public domain.
Last visited: 2021-02-12
‣ C1.20: lego duck drake mallard. https://www.piqsels.com/en/public-domain-photo-zrrjr. CC0. Last visited: 2021-02-12
‣ C1.21: own work
‣ C1.22: Disneyland paris Disneyland paris theme. https://www.piqsels.com/en/public-domain-photo-fwnxq. CC0. Last visited: 2021-02-12
‣ C1.23: bath duck close up cute duck. https://www.piqsels.com/en/public-domain-photo-zbjzk. CC0. Last visited: 2021-02-12
‣ C1.24: from [Gharbi+2019]
‣ C1.25: Software Architecture Views. illustration from WG Universities slide deck
‣ C1.26: Systematic design: derived from ITech Progress slide deck
‣ C1.27: The Architecture Influence Cycle according to [Starke2020] and [Bass+2021]
‣ C1.28: Mutually Influencing Factors. from ITech Progress slide deck
‣ C1.29: derived from iconcheese. Monster. https://thenounproject.com/search/?creator=2793072&q=monster. CC0. Last visited: 2021-02-12
‣ C1.30: The Twin-Peaks model, illustration derived from [Nus2001]
‣ C1.31: derived from [Hof2007], but annotated and extended
‣ C1.32: according to [Raj2000], own drawing but derived from this source

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 1. Basic Concepts 83

References

Literature Sources
‣ [Bass+2021] Len Bass, Paul Clements, Rich Kazman: Software Architecture in Practice. Addison-Wesley; 4th edition, 2021.
‣ [Booch+1999] Booch, G., Rumbaugh, J. and Jacobson, I. (1999). The Unified Modeling Language User Guide. Bonn, Germany: Addison-
Wesley.
‣ [Gharbi+2019] Mahbouba Gharbi, Arne Koschel, Andreas Rausch: Software Architecture Fundamentals - A Study Guide for the Certified
Professional for Software Architecture®,dpunkt.verlag, 2019.
‣ [Hof2007] Hofmeister, C., Kruchten, P., Nord, R. L., Obbink, H., Ran, A., & America, P.(2007). A general model of software architecture
design derived from five industrialapproaches. Journal of Systems and Software, 80(1), 106-126.
‣ [Lehner+2007] Lehner, F.; Wildner, S.; Scholz, M.: Wirtschaftsinformatik: Eine Einführung. Carl Hanser Verlag, München 2007, p. 185 f; and
Keller W.: IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen IT-Unterstützung. dpunkt.verlag, Heidelberg2007., p. 22]
‣ [Nus2001] Nuseibeh, B. (2001). Weaving together requirements and architectures. Computer, 34(3), 115-119.
‣ [Raj2000] Václav T. Rajlich, Keith H. Bennett: A staged model for the software life cycle. Computer 33.7 (2000)
‣ [Starke2020] Gernot Starke: Effektive Softwarearchitekturen: Ein praktischer Leitfaden. 9.Auflage, Hanser, 2020.
‣ [TOGAF2018] The Open Group: TOGAF® Standard, Version 9.2, 2018.https://pubs.opengroup.org/architecture/togaf9-doc/arch/

iSAQB CPSA-F – 1. Basic Concepts 84

2. Roles, Responsibilities, and
Activities of Software Architects
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C2_v1.0.0-EN-1_2023-07-26
Overview

Expected Output and Results

Tasks and Responsibilities

Role and Skills

Interfaces to Other Roles

Fig. C2.1: http://geek-and-poke.com/geekandpoke/2012/1/28/simply-explained.html

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 86

Expected Output and Results
What Do Architects Deliver?
Obviously:
‣ The architecture design for the
desired IT system.

To deliver on expectations:
‣ Ensure fulfillment of functional and ensure
quality requirements …
‣ … in alignment with project/product Architecture
goals and business objectives. Goals

Project /
Product Goals
help to achieve
iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.2 87
Tasks of Software Architects
Overview
Tasks and responsibilities of
software architects extend far
beyond the scope of “only”
designing the system’s
architecture.

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.3: according to [Starke2020] and [Bass+2021] 88
Tasks of Software Architects
Establish a Business Case for the System
IT projects should be based on a business case.
‣ Consider expected costs and desired benefits.
‣ Business value from customer perspective. The primary owner of the business case is
‣ What is YOUR business model? the project sponsor, but architects should
at least be consulted and provide input.

Tasks of software architects:

‣ Create and elaborate economically
viable solutions.
‣ Shape and constrain future requirements
(context, influencing factors).

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 89

Tasks of Software Architects
Clarify and Understand Requirements
Identify, gather, clarify, refine, and scrutinize:
‣ Functional requirements (required features).
‣ Quality characteristics (leading to required constraints).
‣ Influencing factors (business context, stakeholders)

Analyze feasibility and identify contradictions.

Identify missing and implicit requirements.
→ Make them explicit!
Estimate (and improve) stability of requirements.

Derive architecturally relevant requirements.

… more in Chapter 3

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 90

Tasks of Software Architects
Design or Select the System’s Software Architecture 1/2
Select candidate architecture(s) from existing solutions:
‣ Compare costs and benefits.
‣ Consider integration with existing solutions and systems.
‣ Align design with existing systems’ architectures and hardware.
‣ Develop alternative or extended designs.

Choose technologies:
‣ Reuse proven frameworks, libraries, and components.
‣ Consider developers’ experience and skill set.

Take the tool stack into account:

‣ Which tools are already used? Which are needed?

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 91

Tasks of Software Architects
Design or Select the System’s Software Architecture 2/2
Design the system and thereby its architecture
‣ Decompose into building blocks (domain layer, technology layer)
‣ Define dependencies and interfaces
‣ Decide on cross-cutting concerns High-level system model
(e.g., persistence, communication, GUI, …)

… more in Chapter 4–7

Provide rationale for design decisions!

‣ Trade-offs between requirements, interests, and goals

Test architecture concepts with prototypes. Distribution of

responsibilities Different views

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.4 92
Tasks of Software Architects
Document + Communicate Software Architecture
Create a shared understanding via:
‣ Conceptualization and illustrative representations
‣ Depiction of functionality and technical elements

Document and communicate software architecture based on

‣ views,
‣ architectural patterns,
‣ cross-cutting concerns.

Always explicitly specify assumptions and prerequisites!

→ Implicit assumptions will cause misunderstandings.

Documentation and communication

complement each other.
iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 93
Tasks of Software Architects
Guide + Support Implementation
Support realization and implementation of the architecture.
‣ Ensure compliance of implementation with system’s software architecture (code reviews, tests)
‣ Integrate feedback from relevant stakeholders into the architecture.
‣ Specify and improve development and test tools.
‣ Analyze architecturally-relevant issues and technical problems.
‣ Coordinate with stakeholders of other projects or peripheral systems.
‣ Support testers (e.g., conditions and constraints for test cases).

Lead and guide developers

‣ Communicate with them. Support them.
Identify skilled developers and learn from them.
Consult and support project leadership
‣ Effort estimations, development status, risks

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 94

Tasks of Software Architects
Evaluate Architecture
Analyze and evaluate software architecture and architectural decisions
‣ Quantitative and qualitative assessment
‣ Adherence to requirements, constraints, and architecture goals.
‣ Identify and mitigate risks, especially concerning quality requirements.

Identify, highlight, and justify consequences of

architectural decisions to other stakeholders.

Derive solutions and strategies to mitigate risks.

→ Coordinate with other stakeholders

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 95

Tasks of Software Architects
Iterative and Incremental Approach
Depending on your development method, there
will be numerous iteration cycles.

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 96

Role(s) and Skills of Software Architects

Consider all aspects of the software Responsibilities

development lifecycle: analysis, design, ‣ Design systems
implementation, management, and ‣ Solve architecturally-relevant problems
maintenance of the software. ‣ Make architecturally-relevant decisions
‣ Envision solutions
‣ Guiding others

Architects are involved in many tasks and

communicate with a variety of
Drive main tasks of IT projects.
stakeholders.

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 97

Role(s) and Skills
Desired Skill Set of a Good Architect
Capacity for abstract thinking / system thinking Communicate
Assertiveness and decision-making abilities,
Interpersonal communication and negotiation skills Negotiate Listen
Ability to work in teams and to work independently
Knowledge in breadth (not always in depth)
→ fast learner
Organize Guide
Innovative/creative
Open and adoptable to changes

Technical Expertise
iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.5 99
Interfaces to Other Roles and Stakeholders
IT Operations
Architects often fulfill other roles
in IT projects (especially in SMEs).

PRO Project Manager

‣ Improved understanding of
additional concerns.
Security Expert
CON
Customer or
‣ Conflicts of interests User
‣ Neglecting documentation Software Architect

Strive for a clear distribution of

responsibilities and well-defined Analyst or
Requirements
communication paths among all roles! Developer
Engineer Tester

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.6: adapted from arc42 [arc42] 100
Interfaces to Other Roles
Analyst / Requirements Engineer / Product Owner
Accepts requirements from analyst, requirements engineer or product owner
‣ Examines the feasibility of requirements
‣ Detects inconsistencies
‣ Asks for possible changes in requirements to improve architecture.

Requirements

Change requests
Analyst, requirements Software architect
Analyst
engineer, or product owner Softwarearchitekt

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.7: adapted from arc42 [arc42] 101
Interfaces to Other Roles
Customer
“Lawyer” of the customer
‣ Ensures that requirements are sensible and feasible
‣ Ensure that the requirements are fulfilled from an architectural perspective

Requirements

Results; Feedback
Customer
Anwender Software architect
Softwarearchitekt

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.8: adapted from arc42 [arc42] 102
Interfaces to Other Roles
Project Manager
“Advisor" of the project management
‣ Support project planning, including the creation of work packages
‣ Risk analysis and prevention

Project goals, constraints

Status feedback,
Project Manager architectural/technical risks, Software architect
Projektleiter Softwarearchitekt
solutions

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.9: adapted from arc42 [arc42] 103
Interfaces to Other Roles
Developer
Contact person for the developers
‣ Architecture guidelines, possibly development specifications
‣ Know-how transfer
‣ Code Reviews to check compliance to the architecture guidelines

Status, Change requests

Architecture Guidelines
Developer Software architect
Entwickler Softwarearchitekt

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.10: adapted from arc42 [arc42] 104
Interfaces to Other Roles
Tester
Contact person for the testers
Architecture guidelines and constraints regarding testing.
Support the testers with, e.g.
‣ Test constraints
‣ Test cases
‣ Sequence and dependencies during testing
‣ Prioritization of tests

Feedback: e.g., stability, performance

Guidelines, constraints
Tester Software architect
Tester Softwarearchitekt

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.11: adapted from arc42 [arc42] 105
Interfaces to Other Roles
IT Operations
Contact person for the operators of the system
‣ Considers operational framework
(Network topology, available hard- and software, operating systems)
‣ Defines deployment structure
‣ Defines configuration guidelines

Operational constraints

Deployment, Configuration
IT Operations Software architect
Betrieb Softwarearchitekt

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects Fig. C2.12: adapted from arc42 [arc42] 106
Summary
Roles, Responsibilities, and Activities
Architects are responsible for ensuring the fulfillment of requirements.

His/her activities extend far beyond “just design”.

Special skills and intensive cooperation with many other roles and stakeholders are
required to accomplish these tasks.

If you take on additional roles, you should be able to identify the specific responsibilities
associated with the role of the architect.

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 107

References

Table of Figures
‣ C2.1: Geek & Poke. (2012). Simply Explained. http://geek-and-poke.com/geekandpoke/2012/1/28/simply-explained.html. CC BY 3.0. Last visited: 2021-02-
11
‣ C2.2: own work
‣ C2.3: own work derived from [Starke2020] and [Bass+2021]
‣ C2.4: ITech Progress slide deck
‣ C2.5: own work
‣ C2.6 – C2.12: icons from ITech Progress slide deck, adapted from arc24 [arc42]

Literature Sources
‣ [arc42] arc42 - Template for Software Architecture Documentation. Open-Source, published on https://arc42.org. Created by Peter Hruschka and Gernot
Starke.
‣ [Bass+2021] Len Bass, Paul Clements, Rich Kazman: Software Architecture in Practice. Addison-Wesley; 4th edition, 2021.
‣ [Starke2020] Gernot Starke: Effektive Softwarearchitekturen: Ein praktischer Leitfaden. 9.Auflage, Hanser, 2020.

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 2. Roles, Responsibilities, and Activities of Software Architects 108

3. Deriving Quality Goals
and Design Constraints
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C3_v1.0.0-EN-1_2023-07-26
Overview

Requirements and Constraints

System Context
To
From
Influencing Factors Quality
Requirement
Goals and
s and
Quality Requirements Design
Context
Constraints
Impact of Stakeholders

Uncertainty and Risks

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 110

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.1 111
What Is a Requirement?

Requirement ISO/IEC/IEEE 24765:2017

‣ Condition or capability that must be met or possessed by a system,
system component, product, or service to satisfy an agreement,
standard, specification, or other formally imposed documents
‣ Statement that translates or expresses a need and its associated
constraints and conditions
‣ Requirements include the quantified and documented needs, wants,
and expectations of … stakeholders.

Requirement Types
‣ Functional Requirement
Note the different possible
‣ Quality Requirement meanings of this term.
‣ Constraint
iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 112
What Is a Constraint?

Constraint ISO/IEC/IEEE 24765:2017

‣ Externally imposed limitation on system requirements, design, or implementation or
on the process used to develop or modify a system

A constraint is a requirement that limits the solution space beyond what is necessary
for meeting the given functional requirements and quality requirements. [Pohl+2016]

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 113

Origins of Requirements
… and What Is Influenced by Them

identify influencing factors

system context relevant requirements derive influencing factors

and constraints during analysis and design

may concern

architecture IT system implementation

IT project

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.2: some details derived from [Hof2007] 114
System Context

“The part of reality that is relevant for

the requirements of a system.”
[Pohl+2016]
People
stakeholders or groups
of stakeholders

Systems in operation
other technical systems Documents
or hardware laws, standards,
system documentation
Events
technical or physical Processes
technical, physical,
business processes
iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.3: System context according to Pohl et al. [Pohl+2016] 115
 Influencing Factors
Categories

Consider mutual interdependencies,

conflicts, and changes of factors and
their importance over time!

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.4: according to Hofmeister et al. [Hof+2005] and Starke [Starke2020] 116
Organizational Influencing Factors
Organization and Structure
Organizational structure of the company
Organizational structure of project team
Decision makers
Partnerships / Cooperation
Internal or external (e.g., outsourced) development
Commercial product or internal usage

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.5 118
Organizational Influencing Factors
Conway’s Law

“Organizations which design systems … are constrained to

produce designs which are copies of the communication
structures of these organizations.”
Conway, Melvin E. (1968)
"How do Committees Invent?", Datamation, 14 (5): 28–31

Communication structures in or between teams influence structure

and interfaces of the system they build.
‣ (Overly) simplified: A system built by 5 teams will probably consist
of 5 large building blocks.
‣ Often there is NO technical necessity for this.

Quality of communication between the teams influences the quality

and type of system interfaces.
iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.6 119
Organizational Influencing Factors
Standards, Resources, Legal
Standards
‣ Process model, Quality standards
‣ Test, approval, and release process
‣ Tools (dev, config, version control, test, …)
Resources (Budget, Time, Staff)
‣ Contract: fixed-price / time and material
‣ Time schedule and release plan : flexible / fixed deadline
‣ Priorities: deadline / scope of functions
‣ Project budget: fixed / variable
‣ Team: number of employees, skill set, commitment, availability
Legal
‣ Liability issues, Burden of proof
‣ Privacy laws, data protection, international legal issues

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.7 Fig. C3.8 120
 Technological Influencing Factors

Software-Infrastructure Programming
Guidelines
Hardware-Infrastructure

Programming Language
Data Structures
Technological
Communication Factors
Protocols Operating Environment

Graphical User Interface Reference Architectures

Programming Interfaces Libraries, Frameworks, and Components

Availability of Runtime Environment

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.11 121
Product-Related Influencing Factors

Functional requirements
‣ Describe desired functionalities, data, or behavior
of the system or product
(what the system should / can do).

Quality requirements
Those are important, so
‣ Describe desired quality attributes of
we will discuss them in detail!
the system or product.
(how the system should be)

Possibly many more

‣ Product cost, product service, licensing, business
model, …

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.12 122
Quality Requirements
Why Are They So Important?
Often neglected (in contrast to functional requirements)
High impact on fundamental architectural design decisions
→ Must be explicit to derive design goals.

Changing quality requirements can lead to …

‣ ... difficult and costly design changes
‣ … a fundamentally different architecture

Architecture can not be designed without essential quality requirements!

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 123

Quality Requirements
Analyze and Specify Explicitly!
Quality requirements can be based on quality models,
which define specific quality attributes (e.g., ISO/IEC 25010).

Quality goals might

‣ (Inadvertently) contradict project goals.
‣ Support or contradict each other.

Quality requirements should be precise and measurable, for example:

‣ New business rules can be defined in less than 4 hours.
‣ Files are parsed within 5 seconds or less.
‣ Application can be run with 1 Gigabyte of RAM. More on quality
models in Chapter 9.
iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 124
Quality Requirements
Utilize a Quality Model
Attributes1 of the
IEC 25010
hierarchic quality
model.

1 also called
“quality characteristics”

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.13: own drawings based on IEC 25010 125
Quality Requirements
Derive a Specific Quality Tree

Support requirements management with

Quality models, quality trees,
‣ Selecting applicable quality attributes,
and scenarios will be discussed
‣ Prioritizing requirements, and
in more detail in Chapter 9.
‣ Complementing these with scenarios.
iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.14: own drawings based on IEC 25010 and [arc42] 126
Correlations and Trade-Offs

Quality goals, can Examples

‣ align with, or contradict, each other ‣ Performance vs. reusability
‣ support or compete with other ‣ Consistency vs. availability
influencing factors (e.g., project or ‣ Security vs. ease-of use
business goals) ‣ Development time vs. performance
‣ Fast time-to-market vs.
sustainability
cost maintainability

flexibility

time-to-market simplicity

performance

Fig. C3.15: Rubberband-Model according to [Starke2020]

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 127
 Correlations and Trade-Offs
Some More Examples

Adaptability, Flexibility High Performance Memory Usage  CPU Utilization

Configurability  Robustness Flexibility

Testability
✓
Quality Attributes

Simplicity ✓ Understandability High Performance  Delivery Date

Security  Usability Efficiency  Maintainability/Adaptability

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 128

Impact of Stakeholders

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.16: adapted from [Bass+2021] 129
Impact of Stakeholders
Some Examples

Stakeholder Concern
deployment approach
failure handling
administrator
monitoring
available hardware
easy to hire new developers
management
architecture matches organizational structure
QA architecture meets quality requirements

customer system interoperates with existing software

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 130

Impact of Stakeholders
Stakeholder Analysis
Which stakeholders are relevant?
What are their particular characteristics and interests?
‣ Name and description
‣ Expectations from the project towards the stakeholder
‣ Stakeholder expectations toward the project
‣ Power and influence (project acceptance, political, ...)
‣ Proximity to the project (active/passive)
‣ Expected conflicts

Derived from the

PRINCE2 stakeholder
analysis matrix.
iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 131
Impact of Stakeholders
Mandated Design Decisions
Stakeholders sometimes (attempt to) impose design decisions
‣ E.g., “do not use Java”, “use framework X and database Y”

Ask questions:
‣ What is the motivation/reasoning of the stakeholder?
‣ How does this impact the design space and architecture?
‣ Does it create risks for the project?
‣ Is this request feasible? Is it negotiable?

Uncover possible “hidden requirements” or wrong assumptions.

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 132

Architectural Uncertainty
Changing and Unstable Requirements
Inherent uncertainty in requirements
‣ Vague/ambiguous project goals
‣ Changing requirements

Architects can manage this by

‣ Providing and regularly getting
stakeholder feedback
‣ Making decisions iteratively
‣ Evaluating and predicting risks

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.17 133
Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.1 134
Identifying and Managing Risks
What Are Risks?
Threat to the successful fulfillment of project or architectural goals.
‣ Probability of an adverse event  amount of harm
‣ High degree of uncertainty, may depend on chance

Architects must
‣ Recognize risks
‣ Communicate risks
‣ Assess and limit risks

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 135

 Identifying and Managing Risks
Typical Risks

Limited availability of resources

Tight schedule

Lack of prioritization Limited suitability of resources

Contradictions Limited availability of expertise

Typical Risks
Ambiguity
New, untested products
Lack of documentation
Critical external interfaces
High rate of change of requirements
Availability of technical infrastructure
Inadequate requirements

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.18 136
Identifying and Managing Risks
Risks by Category

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints Fig. C3.19 137
Identifying and Managing Risks
Implicit Influencing Factors
Very risky: implicit influencing factors and assumptions
‣ “… it should have been clear to everyone that …”
‣ “… we always assumed that …”

Anticipate and address possible implicit assumptions.

‣ “<component> is responsible for …” is sometimes not enough
‣ Be explicit: “<component> is not responsible for …”

Explicit! Not implicit.

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 138

Identifying and Managing Risks
Strategies for Organizational Risks
Close cooperation with project management.
(concerns e.g.: time, budget, knowledge)
‣ Provide information concerning risks timely and openly
‣ Propose alternative solutions to meet deadlines

Clarify impact of critical requirements.

Negotiate changes with stakeholders (possibly leading to redefined requirements)
‣ Prioritization
‣ Costs
‣ Quality

Determine risks of architectural decisions, e.g., make-or-buy.

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 139

Identifying and Managing Risks
Experience From Large Projects
Nobody works more productive or faster under high pressure
→ Increasing error rate, quick-and-dirty solutions

Hiring more people for a delayed project, delays it further.

Murphy‘s Law: Additional problems always arise.

‣ Be a pessimist: Prefer to plan too many rather than too few resources.
‣ Calculate safety margins.
‣ Expect unknown unknowns.

If the political issues are not managed, the system development will never be successful.

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 140

 Summary
Quality Goals and Design Constraints
At the end of this chapter, you should be able to explain
how requirements, constraints, and influencing factors
lead to quality goals and design constraints.
‣ Sources of requirements (and constraints) To
From
‣ The role of the system context Quality Goals
Requirements
‣ Different categories of influencing factors and Design
and Context
Constraints
‣ Quality Requirements, Quality Models,
Quality Trees, and Scenarios
‣ The impact of stakeholders on requirements
‣ Different types of risks and possible mitigation
strategies

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 141

References

Table of Figures
‣ C3.1: derived from ITech Progress slide deck
‣ C3.2: some details derived from [Hof2007]
‣ C3.3: System context according to Pohl et al. [Pohl+2016]
‣ C3.4: own drawing according to Hofmeister et al. [Hof+2005] and Starke [Starke2020]
‣ C3.5 - C3.7: derived from WG Universities slide deck
‣ C3.8: derived from Viktor Vorobyev. tools. https://thenounproject.com/term/tools/561840/. CC BY. Last visited: 2021-02-17, derived from
Jemis mali. paper. https://thenounproject.com/term/paper/968444/. CC BY. Last visited: 2021-02-17
‣ C3.9: derived from Srinivas Agra. Wealth. https://thenounproject.com/search/?q=2536858&i=2536858. CC BY. Last visited: 2021-02-17,
derived from Normansyah. Stopwatch. https://thenounproject.com/search/?q=3426071&i=3426071. CC BY. Last visited: 2021-02-17
‣ C3.10: derived from Alena Artemova. Libra. https://thenounproject.com/search/?creator=2412371&q=libra&i=967626. CC BY. Last visited:
2021-02-17
‣ C3.11: ITech Progress slide deck
‣ C3.12: own work
‣ C3.13: own drawings based on IEC 25010
‣ C3.14: own drawings based on IEC 25010 and [arc42], the examples of the WG Universities slide deck
‣ C3.15: Rubberband-Model from WG Universities slide deck ”Adapted with permission from: Gernot Starke – Effektive Software-
Architekturen”
‣ C3.16: Stakeholders from slide deck WG Universities, adapted from [Bass+2021]

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 142

References

Table of Figures
‣ C3.17: own drawing derived from WG Universities slide deck
‣ C3.18: derived from ITech Progress slide deck
‣ C3.19: own work

Literature Sources
‣ [Bass+2021] Len Bass, Paul Clements, Rich Kazman: Software Architecture in Practice. Addison-Wesley; 4th edition, 2021.
‣ [Hof+2005] Hofmeister, C., Nord, R. L., & Soni, D. (2005). Global analysis: moving from software requirements specification to structural views of the
software architecture. IEE Proceedings-Software, 152(4), 187-197.
‣ [Hof2007] Hofmeister, C., Kruchten, P., Nord, R. L., Obbink, H., Ran, A., & America, P.(2007). A general model of software architecture design derived from
five industrial approaches. Journal of Systems and Software, 80(1), 106-126.
‣ [Pohl+2016] Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals, 2nd Edition: A Study Guide for the Certified Professional for Requirements
Engineering Exam -Foundation Level, Rocky Nook, 2016.
‣ [Starke2020] Gernot Starke: Effektive Softwarearchitekturen: Ein praktischer Leitfaden. 9.Auflage, Hanser, 2020.

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 3. Deriving Quality Goals and Design Constraints 143

4. Design Principles
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C4_v1.0.0-EN-1_2023-07-26
Overview

Architect’s “Toolbox”

Establishing Context

From To
General Design Principles
WHAT? HOW?
SOLID Principles

iSAQB CPSA-F – 4. Design Principles 145

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 4. Design Principles Fig. C4.1 146

The “Toolbox” of Architects

iSAQB CPSA-F – 4. Design Principles Fig. C4.2 147

From “WHAT?” to “HOW?”

Refined Requirements High-Level Design

Quality Goals ‣ Overall structure of the system
architecture, subsystems, interfaces, …

From To Low-Level Design

WHAT? HOW? ‣ Detailed structure of the system
component design, data structures, …

Design Constraints
Influencing Factors

iSAQB CPSA-F – 4. Design Principles 148

Establish Domain and
Technological Contexts
What is the core task of the system?
Interactive Online System
Operational System
To which category does the system belong? Decision support
Data warehouse
‣ Reference architectures provide a template Business intelligence system
for solutions. Mobile System
Offline-/Batch- System
Often systems belong to multiple categories. Machine Control
Embedded System
→ Corresponding subsystems, belonging to Real Time System
one category (usually, but not always possible) Cloud Native System

iSAQB CPSA-F – 4. Design Principles 149

Design Principles
Purpose and General Objective
Generalized knowledge that (often) helps to make design decisions.
Proven conventions and best practices.

Objectives
‣ Reduce unwanted complexity
‣ Achieve quality requirements
(e.g., increase flexibility, changeability, and adaptability)

iSAQB CPSA-F – 4. Design Principles 150

Design Principles
Rule #1: Know When to Break the Rules
You are responsible and paid for the …
‣ fulfilment of requirements
‣ solution of the problem at hand
Not for perfect adherence to principles.

Principles can contradict each other or specific requirements.

‣ Weigh specific requirements against principles.
‣ Know (long-term) consequences of violating design principles.

iSAQB CPSA-F – 4. Design Principles 151

 David L. Parnas
Design Principles [Parnas1972]
Information Hiding Principle
Encapsulating complexity in components improves
flexibility, stability, testability, and understandability

Treat components as “Black boxes”

‣ Hide internal details from clients.
Account
‣ No direct access to internal data and structures
→ Access only via defined interfaces +name : String
‣ Expose only what is needed, hide everything else. -transactions : List<Transaction>

+addTransaction(Transaction)
Breaking encapsulation leads to unwanted dependencies. +getBalance()
→ Higher complexity

iSAQB CPSA-F – 4. Design Principles Fig. C4.3: http://hyperboleandahalf.blogspot.com/2010/06/this-is-why-ill-never-be-adult.html Fig. C4.4 152
Design Principles
SoC – Separation of Concerns
Objective: Manage different
problems separately.
Separate Concerns
‣ Domain, sub-domains, sub-tasks, …
‣ Persistence, logic, behavior,
presentation, …

Split complex systems according to

responsibilities.
‣ Implemented in a lot of patterns.

iSAQB CPSA-F – 4. Design Principles Fig. C4.5 153

Design Principles
SoC and Modularity
SoC + Information Hiding → Modularity

Modules
‣ Encapsulate responsibilities
‣ Expose well defined interfaces only
‣ Can be developed, maintained, and tested
independently
‣ Objective: Can be replaced without side effects

Fig. C4.5b

iSAQB CPSA-F – 4. Design Principles 154

Design Principles
Loose Coupling
Components do interact with each other
‣ Inherent property of each system
‣ Necessary and inevitable relationships (and dependencies)
‣ Each dependency and relationship increases complexity

Aim for loose coupling:

‣ Keep the number of dependencies low
‣ Keep dependencies simple

Goal: Few, well-defined, well-structured, and explicit dependencies.

iSAQB CPSA-F – 4. Design Principles 155

Design Principles – Loose Coupling
Types of Coupling

Call

HOW are components Inheritance Message

coupled to each other?

Coupling
Execution
Creation
Location

Time Data

iSAQB CPSA-F – 4. Design Principles Fig. C4.6 156

Design Principles – Loose Coupling
Types of Coupling: Call

Note: Invocation dependencies depend on the direction of the call.

‣ E.g., if “building block A" calls “building block B",
then "A" is dependent on "B" but not vice versa
Cyclical relationships are a special type of call coupling

iSAQB CPSA-F – 4. Design Principles Fig. C4.7 157

Design Principles – Loose Coupling
Types of Coupling: Message

iSAQB CPSA-F – 4. Design Principles Fig. C4.8 158

Design Principles – Loose Coupling
Types of Coupling: Creation

iSAQB CPSA-F – 4. Design Principles Fig. C4.9 159

Design Principles – Loose Coupling
Types of Coupling: Data Structure

iSAQB CPSA-F – 4. Design Principles Fig. C4.10 160

Design Principles – Loose Coupling
Types of Coupling: Time

iSAQB CPSA-F – 4. Design Principles Fig. C4.11 161

Design Principles – Loose Coupling
Types of Coupling: Execution Location

iSAQB CPSA-F – 4. Design Principles Fig. C4.12 162

Design Principles – Loose Coupling
Types of Coupling: Inheritance

Inheritance is a very
strong type of coupling.

iSAQB CPSA-F – 4. Design Principles Fig. C4.13 163

 Design Principles – Loose Coupling
Types of Coupling

Call invoke another building block

use attributes and send/receive messages

methods of parent
Inheritance Message
from/to other building block

Coupling
require same hardware, create another
Execution
runtime environment, Creation building block
Location
or network segment

shared data structures

temporal sequence of activities Time Data or call parameters

iSAQB CPSA-F – 4. Design Principles Fig. C4.6 164

Design Principles
Benefits of Loose Coupling
Loosely coupled components
‣ Can interact, but need to know very little about
each other
‣ Introduce fewer “side effects” on changes
Strong coupling

Degree of dependency for involved components is as

low as possible
‣ Easier to comprehend
‣ Easier to re-use
‣ Easier to replace, more flexible
‣ Changes are local, not global Loose coupling

iSAQB CPSA-F – 4. Design Principles Fig. C4.14 165

Design Principles
High Cohesion
Cohesive components contain Goal: High cohesion
strongly related sub-components

Criteria for cohesion

SoC + loose coupling → high cohesion. depend on context.
→ Explicit design decision!
Purpose: reduce complexity
increase maintainability

‣ Coupling: Dependency between modules

‣ Cohesion: Dependency within a module
iSAQB CPSA-F – 4. Design Principles Fig. C4.15: adapted from [arc42], [Starke2020], and [Starke+2023] 166
Design Principles
As Simple as Possible – KISS & YAGNI
“Make things as simple as possible, but not simpler.”
Goal: Prefer simple,
‣ Easier to comprehend and to maintain
less complex solutions
‣ Less error prone

What is the minimum viable product? Perfect is the enemy of good!

Voltaire
iSAQB CPSA-F – 4. Design Principles 167
 Goal: Duplication only
Design Principles when wanted/required
DRY

Avoid duplicate code, data, or responsibilities.

software decay
DRY helps to avoid
code smell
degenerated design.
bit rot

Downside: DRY leads to increased coupling.

iSAQB CPSA-F – 4. Design Principles Fig. C4.16: modified version of http://geek-and-poke.com/geekandpoke/2013/1/22/stackoverflow.html 168
Design Principles
Expect Errors: Murphy’s Law

What do I depend on? What can possibly go wrong?

anticipate errors – contain error impact – support error analysis.

iSAQB CPSA-F – 4. Design Principles 169

Design Principles
Robustness Principle – Postel’s Law
“Be conservative in what you do, be
liberal in what you accept from others.”

Be precise and strict when designing your

components, but:
‣ Tolerate errors in other components
‣ Be able to recover from errors
‣ Degrade gracefully
Goal: Tolerate errors

This does not come for free!

‣ There are costs and risks that come
with adhering to Postel’s Law.

iSAQB CPSA-F – 4. Design Principles Fig. C4.17: Jon Postel at work by Irene Fertik, USC News Service 170
Design Principles
Abstraction
Identify useful generalizations
‣ Emphasize common properties or functionalities
‣ Omit/hide unnecessary details

Complements SoC, DRY, information hiding

Do not depend on implementations,

depend on abstractions.
Use abstractions provided by programming
languages or libraries.

iSAQB CPSA-F – 4. Design Principles Fig. C4.18 Fig. C4.19 171

 Goal: Clear, recognizable
Design Principles concepts
Conceptual Integrity

… conceptual integrity is the most important

consideration in system design.
It is better to have a system omit certain
anomalous features and improvements, but
to reflect one set of design ideas, than to
have one that contains many good but
independent and uncoordinated ideas.
Fred Brooks
The Mythical Man-Month. Addison-Wesley 1995

Unix: everything is a file

Lisp: everything is a list
SQL: all data resides in tables
iSAQB CPSA-F – 4. Design Principles Fig. C4.20 172
SOLID Principles – Overview

iSAQB CPSA-F – 4. Design Principles 173

SOLID Principles
Single Responsibility Principle
Each component is responsible for only one clearly defined task.
‣ Contains only functions or sub-components directly contributing to this task
‣ Encapsulate this functionality
‣ “A class should have only one reason to change.”

Related to and depends on SoC

‣ Will increase cohesion
vs.
‣ Can decrease coupling

Improves: modifiability, maintainability, and reusability

iSAQB CPSA-F – 4. Design Principles Fig. C4.21 174

 Goal: Extension without
SOLID extensive changes
Open-Closed Principle
Components should be open for extension but closed for modification.
‣ Extend behavior and features without changes to source code
‣ No “side effects” from future extensions
‣ Changes do not require modifications to existing users of this component

Various implementations
‣ Stable (“closed”) interfaces
‣ Inheritance from abstract base classes
‣ Extension points, delegation
‣ Various design patterns

iSAQB CPSA-F – 4. Design Principles Fig. C4.22 175

 Goal: Lean and specific
SOLID interfaces
Interface Segregation Principle
Clients should not be forced to depend on methods they do not use.
Multiple small and specific interfaces are better than a single, large one.

Split large interfaces by semantics or by responsibility → “role interface”

Promotes loose coupling and improves maintainability and changeability.

Don’t exaggerate the use of this principle!

‣ Observe the KISS principle.
‣ Group clients into categories and design for these categories.

iSAQB CPSA-F – 4. Design Principles 178

SOLID
Dependency Inversion Principle
High-level modules should not depend
on low-level modules. Both should
depend on abstractions (e.g., interfaces).

Abstractions should not depend on details.

Details (concrete implementations) should
depend on abstractions.

“Inverts” direction of dependency

Similar to provided Interface (API) vs. required interface (SPI)

Related topics: dependency injection and inversion of control

iSAQB CPSA-F – 4. Design Principles Fig. C4.25 179
Design Principles
Summary / Wrap Up

iSAQB CPSA-F – 4. Design Principles 180

References

Table of Figures
‣ C4.1: derived from ITech Progress slide deck
‣ C4.2: own work
‣ C4.3: “All the things” meme generated by https://imgflip.com/memetemplate/X-All-The-Y; original drawing by
http://hyperboleandahalf.blogspot.com/2010/06/this-is-why-ill-never-be-adult.html (Attribution License). Last visited: 2021-02-16
‣ C4.4: “Account” by WG Universities slide deck
‣ C4.5 derived from WG Universities slide deck
‣ C4.5b NASA https://www.hq.nasa.gov/office/pao/History/SP-4205/ch2-3.html
‣ C4.6-C4.14: derived from WG Universities slide deck
‣ C4.15: WG Universities slide deck, adapted from [arc42], [Starke2020], and [Starke+2023]
‣ C4.16: modified version of Geek & Poke. (2013). Stackoverflow. http://geek-and-poke.com/geekandpoke/2013/1/22/stackoverflow.html. CC BY 3.0. Last
visited: 2021-02-16
‣ C4.17: Irene Fertik, USC News Service. (1994). Jon Postel at work. https://commons.wikimedia.org/w/index.php?curid=665678. Copyright 1994. Last
visited: 2021-02-16
‣ C4.18: own work
‣ C4.19: (2017). Metro Map Sofia. https://de.m.wikipedia.org/wiki/Datei:Metro_Map_Sofia_(German).svg. CC0. Last visited: 2021-02-16
‣ C4.20: illustration of runway numbering at Frankfurt Airport, own work
‣ C4.21: component diagram: own work
‣ C4.22 – C4.25: class diagram: own work

iSAQB CPSA-F – 4. Design Principles 181

References

Literature Sources
‣ [arc42] arc42 - Template for Software Architecture Documentation. Open-Source, published on https://arc42.org. Created by Peter Hruschka
and Gernot Starke.
‣ [Hunt+1999] Andrew Hunt, David Thomas: The Pragmatic Programmer : From Journeymanto Master, Addison-Wesley, 1999.
‣ [Starke2020] Gernot Starke: Effektive Softwarearchitekturen: Ein praktischer Leitfaden. 9.Auflage, Hanser, 2020.
‣ [Starke+2023] G. Starke, A. Lorz: Software Architecture Foundation – 2nd edition - CPSA-F® Exam Preparation Van Haren, 2023.

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 4. Design Principles 182

5. Patterns
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C5_v1.0.0-EN-1_2023-07-26
Overview

Patterns: What and Why?

Selected Patterns

Additional Patterns
HOW?

iSAQB CPSA-F – 5. Patterns 184

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 5. Patterns Fig. C5.1 185

What Are Patterns?
And Why Do We Use Them?
What patterns do:
‣ Describe reusable (abstract or concrete) solutions for common problems.
‣ Provide a recognizable structure and terminology for those solutions.

Patterns have been discovered in many fields:

‣ Software architecture
‣ Software design
‣ Analysis
‣ Building architecture
‣ Gardening, teaching, …

iSAQB CPSA-F – 5. Patterns Fig. C5.2: agricultural valleys pattern from [Alexander1977] 186
Designing With Patterns

Patterns offer approaches for Classification of (Some) Patterns (R3)

Architectural - Buschmann [Bus+1996]
‣ Decomposition of a system
‣ Adaptable Systems
‣ Distribution of responsibilities ‣ Interactive Systems
within a system ‣ Mud-to-Structure
‣ Distributed Systems

Patterns separate concerns and Design Patterns - GoF-Patterns [Gam+1994]

give structure to coupling. ‣ Creational
‣ Structural
‣ Behavioral
Patterns complement each other
‣ Refinement and combination Others: enterprise integration, enterprise
architecture, microservices, concurrency, …
‣ Alternatives vs. cooperation https://en.wikipedia.org/wiki/Software_design_pattern

iSAQB CPSA-F – 5. Patterns 187

Important Patterns
Layers
Each layer Highest level of abstraction***
‣ encapsulates details, may provide abstraction
‣ provides services to the layer above it
‣ never depends on a layer above it
System is
Dependencies only between adjacent layers** structured into
‣ Usage is directed from upper to lower layer stacked layers
of services
‣ Communication is directed in both ways

** for strict layering (closed layered architecture)

*** for abstraction layers
Lowest level of abstraction***

iSAQB CPSA-F – 5. Patterns Fig. C5.3 188

Important Patterns
Layers – Abstraction Layers Example

Application ‣ High-level APIs

Presentation ‣ “Data translator”, encryption, compression

Session ‣ Managing communication sessions

Transport ‣ Reliable transmission of data

Network ‣ Addressing, routing and traffic control

Data Link ‣ Reliable transmission of data frames

Physical ‣ RX/TX physical medium

Example: ISO Open Systems Interconnection(OSI) model

iSAQB CPSA-F – 5. Patterns 189
Important Patterns
Layers – Functionality Layers Example

‣ Control elements
Presentation Layer
‣ (Partial-) views of domain

‣ Coordination of business objects

Application Layer
‣ Delegation to business domain /infrastructure

‣ Domain-specific aspects:
Business Domain Layer
Datatypes, processing rules, etc.

‣ Encapsulate the complexity of infrastructure

Infrastructure Layer
‣ Can be further decomposed

iSAQB CPSA-F – 5. Patterns 190

Important Patterns
Layers – Pros & Cons
PRO CON

‣ Layers are independent ‣ Layers are overhead when they only pass
− For development information to following layers to deliver a
(distribution of tasks) specific service.
− In production ‣ Loose layering:
(installation, maintenance) − Allows for skipping layers
− Implementations are interchangeable (open layered architecture)
‣ Unidirectional dependencies − But increases dependency
(no circular dependencies) ‣ Some changes (e.g., adding a data field)
‣ The Layers pattern is easy to understand. may require changes to all layers.

iSAQB CPSA-F – 5. Patterns 191

Important Patterns
Pipes-and-Filters
Pipes
‣ Transport data/messages between filters
‣ Can buffer data

Filters
‣ Processing unit, unaware of other filters
‣ Transform, aggregate, or manipulate data
‣ Connects to multiple input/output pipes

Pipe Pipe Pipe Pipe

Filter Filter Filter

iSAQB CPSA-F – 5. Patterns Fig. C5.4 192

Important Patterns
Pipes-and-Filters – Pros & Cons
PRO CON

‣ Simple (linear) dependencies ‣ Difficult error tracking and handling

‣ Flexible ‣ Buffers might overflow
‣ Easily scalable ‣ Sharing global data might be difficult
‣ Filters can be developed independently

iSAQB CPSA-F – 5. Patterns 193

Important Patterns
Microservices
Divide large systems into small units.
Microservices can be individually
‣ Developed
‣ Deployed
‣ Operated
‣ Changed/replaced
‣ Scaled
Services communicate over networks.

iSAQB CPSA-F – 5. Patterns Fig. C5.5 194

Important Patterns
Microservices – Pros & Cons
PRO CON

‣ Improve changeability and flexibility ‣ All CONs of distributed computing

‣ Decouple technology decisions − Network latency
‣ Multiple versions of a service can coexist − Outages/connection issues
‣ Good scalability − Bandwidth limitations
‣ Fast development, short time-to-market ‣ More sophisticated error handling
‣ More complex deployment/operations
‣ Dependency resolution at runtime may
cause hard to find errors

iSAQB CPSA-F – 5. Patterns 195

Important Patterns
Dependency Injection
Creating/managing an instance of
Remember
an abstract interface
dependency
‣ Decide which specific implementation to use inversion?
‣ Lifecycle management (create, initialize, …)

Inject the implementation

a client is depending on via
‣ Setter injection
‣ Constructor injection

iSAQB CPSA-F – 5. Patterns Fig. C5.6 196

Important Patterns
Dependency Injection – Pros & Cons
PRO CON

‣ Supports the open-closed principle, loose ‣ Hard learning curve for developers
coupling, and dependency inversion ‣ Shifts complexity to DI frameworks
‣ Manage dependencies “by configuration” ‣ Static analysis is difficult/impossible
‣ Vastly improves ‣ Things fail at run time (not compile time)
− Extensibility
− Flexibility, adaptability
− Testability (mock components)
‣ Better readability of code

iSAQB CPSA-F – 5. Patterns 197

Relationship between DIP, DI and IoC

DIP – Dependency Inversion Principle

‣ High-level modules should not depend on low-level modules.
Both should depend on abstractions.
‣ Details should depend on abstractions, not vice versa.
IoC – Inversion of Control
‣ Component registers itself with the framework, later called by the framework.
‣ Third-party libraries define the control flow rather than application-specific components.
‣ “Hollywood principle” – Don't call us, we’ll call you.
DI – Dependency Injection
‣ Creation + injection of instances for abstractions a client depends on
‣ Is a special application of IoC (for the creation of components).
‣ Other applications of IoC : callbacks, scheduler, event loops, observer pattern, …

iSAQB CPSA-F – 5. Patterns 198

Additional Patterns

Usefulness and applicability of the patterns depend on

‣ Your application domain
‣ The kind of systems you build

You should know and master at least some of them.

For additional patterns, refer to:

‣ POSA-Series (Pattern-Oriented Software Architecture)
‣ PoEAA (Patterns of Enterprise Application Architecture)

iSAQB CPSA-F – 5. Patterns 199

Additional Patterns
General Overview 1/2
Blackboard CQRS (Command-Query-Responsibility-
for problems that cannot be solved by Segregation)
deterministic algorithms but require diverse Separates read concerns from write concerns in
knowledge information systems

Broker
Event-Sourcing
coordinate communication between provider(s)
and consumer(s) in distributed systems handle operations on data by a sequence of
events recorded in an append-only store
Combinator (aka: closure of operations)
for domain object of type T, look for operations Interpreter
which both input and output type T Represent domain object or DSL as syntax.
Provide function implementing a semantic
interpretation of a domain object separately from
the domain object itself
iSAQB CPSA-F – 5. Patterns 200
Additional Patterns
General Overview 2/2
Interfacing-patterns: Adapter, Facade, Plug-In
Proxy extend the behavior of a component
integration of subsystems and/or
simplification of dependencies Ports & Adapters
(see Onion-/Hexagonal-Architecture)
MVC, MVVM, MV-Update, PAC
Separate presentation (view) from data, Remote Procedure Call
services, and their coordination remote execution of functions

SOA: Service-Oriented Architecture Template, Strategy, Visitor, Decorator,

provide abstract services rather than State, …
concrete implementations Integration and messaging patterns

Observer
asynchronous notification of consumers
iSAQB CPSA-F – 5. Patterns 201
Additional Patterns
Creational Design Patterns

🏠 Simple Factory 👷‍♀️ Builder

🏭 Factory Method 🐑Prototype
🔨 Abstract Factory 💍 Singleton
https://github.com/kamranahmedse/design-patterns-for-humans

iSAQB CPSA-F – 5. Patterns Fig. C5.7: Design patterns for humans from [kamranahmedse] 202
Additional Patterns
Structural Design Patterns

🔌 Adapter ☕️Decorator
🚠 Bridge 📦Facade
🌿 Composite 🎱Proxy
https://github.com/kamranahmedse/design-patterns-for-humans

iSAQB CPSA-F – 5. Patterns Fig. C5.8: Design patterns for humans from [kamranahmedse] 203
Additional Patterns
Behavioral Design Patterns

👮‍♀️ Command 🏃‍♀️ Visitor

➿ Iterator 💡 Strategy

😎 Observer 📒 Template
https://github.com/kamranahmedse/design-patterns-for-humans

iSAQB CPSA-F – 5. Patterns Fig. C5.9: Design patterns for humans from [kamranahmedse] 204
Additional Patterns
Model-View-Controller
Pattern for Interaction-Oriented Systems
‣ Model encapsules data
‣ View presents (renders) information from
the model
‣ Controller processes user input and system
events and then modifies the model
(behavior)
Model can be used by any number of
View-/Controller-pairs.

iSAQB CPSA-F – 5. Patterns Fig. C5.10 205

Additional Patterns
Observer (Design Pattern)
Subject is only aware of the observer’s interface
and not it’s implementation.
Decouples observer and subject
‣ Changes to one do not impact the other
‣ Both can be reused independently

iSAQB CPSA-F – 5. Patterns Fig. C5.11: according to [Gharbi+2019] 206

Additional Patterns
Broker 1/2

iSAQB CPSA-F – 5. Patterns Fig. C5.12: Broker pattern derived from [Bus+1996] and [Gharbi+2019] 207
Additional Patterns
Broker 2/2
Client Server Proxy
‣ Implements client functionality ‣ Calls services on the server
‣ Sends requests through the client ‣ System-specific functionality
proxy ‣ Mediates between the server and
Server broker
‣ Implements the services Bridge
‣ Registers itself with the broker ‣ Network-specific functionality
‣ Responses are sent through the ‣ Mediates between the local broker and
Server Proxy the bridge of a remote broker
Client Proxy Broker
‣ System-specific functionality ‣ Locates and manages the server
‣ Mediates between the client and ‣ Forwards messages
broker ‣ Handles errors, Provides APIs

iSAQB CPSA-F – 5. Patterns 208

Additional Patterns
Ports & Adapters

iSAQB CPSA-F – 5. Patterns Fig. C5.13: Ports & Adapters 209

Additional Patterns
Adapter (Design Pattern)
Also known as wrapper
Problem description:
‣ Two classes are not able to interact
together because of incompatible
interfaces

Adapter allows the adaption of interfaces

iSAQB CPSA-F – 5. Patterns Fig. C5.14: according to [Gharbi+2019] 210

Additional Patterns
Facade (Design Pattern)
Provides a simplified interface to a set of
interfaces of a subsystem
Useful, if subsystem contains many
technical classes that are rarely used from
the outside
Contains a frequently used subset of
functionalities of the subsystem
Delegates the functionality to other
classes of the subsystem

iSAQB CPSA-F – 5. Patterns Fig. C5.15: adapted from [Gharbi+2019] 211

Patterns
Summary
By now, you should be able to
‣ Explain what patterns are, how they can be applied, and how they support you to
achieve quality requirements.
‣ Explain and provide examples for
− Layers
− Pipes-and-Filters
− Microservices
− Dependency Injection
Know additional patterns, explain their relevance for concrete systems, and provide
examples
Know additional sources for patterns (POSA, PoEAA).

iSAQB CPSA-F – 5. Patterns 212

References

Table of Figures
‣ C5.1: derived from ITech Progress slide deck
‣ C5.2: derived from [Alexander1977]
‣ C5.3: ITech Progress slide deck
‣ C5.4: WG Universities slide deck
‣ C5.5 – C5.6: own work
‣ C5.7 – C5.9: kamranahmedse. Design patterns for humans. https://github.com/kamranahmedse/design-patterns-for-humans. CC BY 4.0.
Last visited: 2021-02-16
‣ C5.10: own work
‣ C5.11: derived from [Gharbi+2019]
‣ C5.12: Broker pattern, derived from [Bus+1996] and [Gharbi+2019]
‣ C5.13: Ports & Adapters from WG Universities slide deck
‣ C5.14: derived from [Gharbi+2019]
‣ C5.15: adapted from [Gharbi+2019]

iSAQB CPSA-F – 5. Patterns 213

References

Literature Sources
‣ [Alexander1977] Christopher Alexander. A pattern language: towns, buildings, construction. Oxford university press, 1977.
‣ [Bus+1996] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-Oriented Software Architecture
(POSA): A System of Patterns. Wiley, 1996.
‣ [Gam+1994] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley, 1994.
‣ [Gharbi+2019] Mahbouba Gharbi, Arne Koschel, Andreas Rausch: Software ArchitectureFundamentals- A Study Guide for the Certified
Professional for Software Architecture®,dpunkt, 2019.

Website
‣ [Wikipedia1]: Wikipedia. https://en.wikipedia.org/wiki/Software_design_pattern. Last visited: 2021-02-16
‣ [kamranahmedse]: GitHub. https://github.com/kamranahmedse/design-patterns-for-humans . Last visited: 2021-02-17

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 5. Patterns 214

6. Additional Design
Considerations
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C6_v1.0.0-EN-1_2023-07-26
Overview

Reduce Complexity

Cross-Cutting Concerns

Designing Interfaces HOW?

Degenerated Design

Achieving Quality Goals

iSAQB CPSA-F – 6. Additional design considerations 216

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.1 217

Reduce Complexity
Generative Creation of Components
Macros
Template-based generators
‣ Java Emitter Templates (JET), Java Server Pages/Faces (JSP/JSF)
‣ XSLT
Transpiler (e.g., Wt and JWt)
Cross-platform frameworks (e.g., Xamarin, React Native, Phone Gap)
API based Generators
Model-Driven generation from DSLs (e.g., Swagger)

iSAQB CPSA-F – 6. Additional design considerations 218

Reduce Complexity
Programming Languages and Paradigms

iSAQB CPSA-F – 6. Additional design considerations 219

Reduce Complexity
AOP and Annotations
conventional code
Cross-cutting concerns impact multiple components
Security
→ System-level concerns
Logging
Aspect-oriented programming – AOP
‣ DRY plus SoC plus OCP for cross-cutting concerns Persistence

‣ Weaving the logic for cross-cutting concerns into the

business logic at compile or run-time.
AOP
Annotations
‣ Decorate functions, classes, methods, or properties Security

weaving
with metadata Logging
‣ Evaluated by annotation processor at compile time
Persistence

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.2: derived from Christian Schenk 220
Cross-Cutting Concerns
Overview
Impact the entire system and often lead to additional technical constraints.
Are often a result of fulfilling quality requirements.
Cannot be easily separated into independent components and may violate DRY/SoC.
Possible Solution: AOP, annotations etc. to centralize code.

iSAQB CPSA-F – 6. Additional design considerations 221

Cross-Cutting Concerns
Persistence
Persist data from volatile memory to permanent storage
Decouple business domain and (database) infrastructure

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.3 222

Cross-Cutting Concerns
Error Handling
Predictable and adequate responses Facilitate diagnosis of error causes
‣ Depending on category and severity ‣ What went wrong?
‣ Differentiate between logical and ‣ Where did it happen?
technical errors ‣ Why did it happen?
Minimize effects of errors Error prevention
Uniform and consistent error handling ‣ Timely warning of identifiable problems
‣ Across possibly different technologies ‣ Allow for processing tolerances
400 Bad Request
401 Unauthorized
404 Not Found
405 Method Not Allowed
500 Internal Server Error
503 Service Unavailable
507 Insufficient Storage

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.4 223

Cross-Cutting Concerns
Security
Authentication Confidentiality
‣ Determine the sender's identity ‣ Restrict unauthorized data access
Authorization Non-repudiation
‣ Grant rights based on identity ‣ Authorship and validity of data
Integrity Availability
‣ Detect manipulation of data ‣ Precautions against accidental or
deliberate system failure

Security should not be retrofitted into a system.

Security also includes operational/organizational procedures!

iSAQB CPSA-F – 6. Additional design considerations 224

Cross-Cutting Concerns
Internationalization

iSAQB CPSA-F – 6. Additional design considerations 225

Cross-Cutting Concerns
Communication and Messaging

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.5 226

Cross-Cutting Concerns
User Interface and Ergonomics
User interface (required by interactive systems)
‣ Graphical, textual, voice-control, interaction through
physical objects (TUI - tangible user interface) , …
‣ Can be adaptive and/or adaptable
(e.g., device, user, situation, customer, …)
‣ Depend on framework and platform

Ergonomics: Optimize usability and user experience

‣ Interaction flow and design
‣ Reactivity (perceived performance)
‣ Availability, protection against user errors, learnability, self-
descriptiveness

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.6: http://geek-and-poke.com/geekandpoke/2010/7/31/how-to-make-enterprise-software.html 227

Cross-Cutting Concerns
Business Rules and Processes
Domain-specific: causal connections or conditional instructions
‣ “if process X is finished, then do Y”
Business rules and processes are often implemented directly in the code (“hard-coded”)
‣ Can contain complex domain knowledge → Confusing code
‣ Distributed across many components → Low maintainability
‣ Simple changes can become expensive → Hard to estimate

Better: centralized, explicit declaration

‣ Use explicit process models along with roles and permissions
‣ Use specialized sub-systems or frameworks for implementation

iSAQB CPSA-F – 6. Additional design considerations 228

Designing Interfaces
Overview

One of the most important aspects of an architecture are

interfaces and the relationships between components.

Interfaces are the backbone of the overall system

‣ Define the structure and the behavior of the system
‣ Provide a link between specialized components
‣ Coordinate and orchestrate a complex network of subsystems

Interfaces are the connection to the “outside world”

iSAQB CPSA-F – 6. Additional design considerations 229

Designing Interfaces
Basic Properties
Need SPI
Style: resource or service-oriented Architectural Style
<<implements>> ‣ Resource-oriented
Call behavior: synchronous or asynchronous
Have Provider ‣ Service-oriented
Data interfaces: sharing/exchanging data

Consider quality requirements! (async.) Messaging

(e.g., performance, robustness, …)

Internal vs. external interfaces:

Shared Database
‣ Unknown consumers
‣ Opportunities for misuse
‣ Security requirements
‣ Stability requirements -----------------
-----------------
-----
File transfer

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.7 230

Designing Interfaces
Resource-Oriented Approach
REST (REpresentational State Transfer)
Business objects are referenced as Web resources
→ URI via HTTP(S)
Various representations/formats
(content types)
Standardized interface definitions
→ HTTP methods (verbs)

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.8 231

Designing Interfaces
Service-Oriented Approach
SOAP (Simple Object Access Protocol)
XML (WS-*, WSDL)
Method calls are encapsulated
in messages
→ SOAP via HTTP(S)
Tailored interface definitions
perform distinct business functions

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.9 232

Designing Interfaces
Requirements
Fulfill user (mostly consumer) requirements
‣ Suitable functionality (fit clients needs)
→ Difficult for public APIs
Easy to learn and to use
‣ Provide IDL (e.g., by using Swagger)
‣ Use unit tests as documentation
Easily to extend
‣ Consider API versioning
Hard to misuse (intentional and unintentional)
Consistent to other interfaces in the system

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.10: http://geek-and-poke.com/geekandpoke/2012/6/6/how-to-create-a-stable-api.html 233

Designing Interfaces
Best Practices
Use it yourself, implement tests, and use the tests as a reference example
‣ How is the interface used from the perspective of consumers or extended service providers?
‣ Test for correctness
Clarify requirements with the consumer and provider
‣ Clarify different views or requirements
Hide implementation details (information hiding principle)
Use meaningful, self-descriptive names
‣ E.g., use terms from the domain model
Minimize surprises and side effects (principle of least surprise)
Provide “atomic” information units
‣ Easy to evaluate, no parsing of strings
Documentation (especially for boundary / threshold examples and errors)

iSAQB CPSA-F – 6. Additional design considerations 234

Achieving Quality Goals
Design Tactics and Solution Strategies
Tactic: design decision that influences how a system behaves to fulfill a quality requirement

Tactics to Control
stimulus System Response response

How to fulfill specific quality requirements?

‣ Develop high-level solution strategies in parallel to the detailed concepts (e.g., cross-cutting
concepts, functional and technical components, etc.)
‣ Principles, patterns, etc. support you in the creation of a solution strategy.
‣ However, there is no single approach that guarantees a suitable solution. 

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.15 235

Achieving Quality Goals
Performance and Modifiability Tactics
Performance tactics
‣ Manage resource demand Trade-offs
− Arbitrate between conflicting demands performance vs. modifiability
− Manage multiple resources
memory vs. performance
Modifiability Tactics security vs. usability
‣ Localize expected modifications
− Encapsulate parts of the system that are expected to change
‣ Restrict visibility of responsibilities
− E.g., information hiding
‣ Prevent ripple effects

iSAQB CPSA-F – 6. Additional design considerations 236

Achieving Quality Goals
Tactics to Reduce Coupling 1/2
General Instantiation dependencies
‣ Temporal and data dependencies are ‣ Factory pattern, Proxy pattern
mostly due to functional dependencies ‣ Dependency Injection
‣ Apply design principles and patterns
‣ Define concrete dependencies only at Call dependencies
runtime or installation time (defer ‣ Messaging, with asynchronous
binding) messages
‣ Avoid cyclical relationships
Structural dependencies ‣ Restrict communication
‣ Polymorphism, delegation ‣ Use abstractions (interfaces)
‣ Façade pattern, decorator pattern ‣ Use intermediaries, e.g., adapters,
brokers, proxies

iSAQB CPSA-F – 6. Additional design considerations 237

Achieving Quality Goals
Tactics to Reduce Coupling 2/2
Data or data type dependencies Dependencies on libraries and frameworks
‣ Data replication, event sourcing ‣ Dependency inversion
‣ Standardized data structures ‣ Inversion of Control

Time dependencies Dependencies on technologies and runtime

‣ Messaging, Events environments
‣ Observer pattern ‣ Apply standards (SQL, HTTP, WSDL, …)
‣ Use technology-independent protocols,
Location dependencies e.g., REST
‣ Registry, Repository ‣ Virtualization

iSAQB CPSA-F – 6. Additional design considerations 238

Achieving Quality Goals
Strategies for High Performance
Additional Hardware
(e.g., more memory)

Perform load tests

Reduce or increase
distribution
Strategies for high
performance

Compromise on
Reduce flexibility
energy efficiency
of the system
Reduce communication
between system components

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.16 239

 Achieving Quality Goals
Strategies for Adaptability and Flexibility

Keep changes local

Use polymorphism in
object-oriented systems Use configuration files

Strategies for adaptability Determine where the system should

Use Information Hiding and Flexibility
be flexible
‣ Functionality
‣ Data structures or data model
Decouple system
‣ Usage of third-party software
components
Use understandable ‣ Interfaces to other systems
as much as possible
and maintainable code ‣ User interface
‣ Target platform

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.17 240

Achieving Quality Goals
High Availability Strategies

Error prevention:
Error detection: ‣ Use transactions
‣ Monitor and analyze ‣ Store state of the system
system in operation
‣ Validate the accuracy of
results from different Strategies for high
redundant components availability

Error handling:
‣ Create mechanisms for robust exception handling
‣ Roll back on fault
‣ Keep multiple redundant system components available
‣ Replace defective components in case of a fault

iSAQB CPSA-F – 6. Additional design considerations Fig. C6.18 241

 R3
Deployment
What to Consider

Who is involved? Staging? Tests?

What to do when things go wrong?

‣ Set up + configure operating system (versions, patch levels, ...)

‣ Users and access rights in the target system
‣ Networks, firewalls, VPNs.
‣ Cryptographic certificates
‣ Databases „automate everything“
− Configuration: schema, indexes, users, permissions, ... (when reasonable)
− Data or database migration
‣ Configuration files present and active?
‣ External libraries/frameworks correct and available?
‣ Monitoring: Deployment process, product performance, operating environment
 R3
Deployment
Deployment-Strategies

various trade-offs between simplicity, speed,cost and risks

that affect e.g. availability and performance

‣ Basic deployment (recreate deployment): Old application version is stopped and replaced by the
new version.
‣ Rolling deployment (ramped deployment): In case of multiple parallel application instances.
Old instances are gradually replaced by new version.
‣ Blue/green deployment: Old (blue) and new (green) version run in parallel. Users are redirected to
the new version.
‣ Shadow deployment: Similar to blue/green. Requests are forked and sent to both versions. Users
initially receive only the responses from the old version.
‣ Canary deployment: Only a part of the users receives the new version. Proportion is slowly
increased. (Comparable with A/B-testing for user feedback.)
Additional Design Considerations
Summary
Generative approaches, programming Designing good interfaces is not rocket
paradigms and languages, and AOP and science. We have covered some basic
annotations help architects to make and rules that support you in doing so.
implement design decisions.
Be aware of design degeneration and
Cross-cutting concerns require special refactor/redesign in time and over time!
attention. Implementation solutions for
them should be localized when feasible. Design tactics and strategies will help you
to achieve quality goals.

iSAQB CPSA-F – 6. Additional design considerations 244

References

Table of Figures
‣ C6.1: derived from ITech Progress slide deck
‣ C6.2: derived from Christian Schenk. AOP. https://www.christianschenk.org/blog/aop-with-aspectj/. Last visited: 2021-02-17
‣ C6.3 – C6.5: own work
‣ C6.6: Geek & Poke. (2010). How To Make Enterprise Software. http://geek-and-poke.com/geekandpoke/2010/7/31/how-to-make-enterprise-
software.html. CC BY 3.0. Last visited: 2021-02-17
‣ C6.7: ITech Progress slide deck
‣ C6.8 – C6.9: WG Universities slide deck
‣ C6.10: Geek & Poke. (2012). How To Create A Stable API. http://geek-and-poke.com/geekandpoke/2012/6/6/how-to-create-a-stable-
api.html. CC BY 3.0. Last visited: 2021-02-17
‣ C6.15: WG Universities slide deck
‣ C6.16- C6.18: derived from ITech Progress slide deck

iSAQB CPSA-F – 6. Additional design considerations 245

References

Literature Sources
‣ [Fowler+1999] Martin Fowler, Kent Beck: Refactoring: improving the design of existing code. Addison-Wesley Longman Publishing, 1999

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 6. Additional design considerations 246

7. Design Approaches
and Methods
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C7_v1.0.0-EN-1_2023-07-26
Overview

Architecture Development Approaches

Architecture Design Methods

HOW?

iSAQB CPSA-F – 7. Design Approaches and Methods 248

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.1 249

Architecture Development Approaches
Agile Software Development
“Traditional” (V-Model, Waterfall) approaches
‣ The next phase starts when the previous is completed
‣ High cost of late changes
Agile
‣ Early/frequent delivery
‣ Close cooperation with customers
‣ Changing requirements are embraced
‣ Simplicity
‣ Continuous improvement within the
development process
‣ “Manifesto for agile software development”

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.2: based on: https://www.digite.com/blog/waterfall-to-agile-with-kanban250
Architecture Development Approaches
Iterative and Incremental Design 1/3

Influencing factors Requirements

influences

changes Architecture design changes

Context &
Customer
stakeholders

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.3 251

Architecture Development Approaches
Iterative and Incremental Design 2/3
Iterative process
‣ Decisions may be subject to uncertainties
‣ Architectures, organizations, and systems influence each other
‣ Customers and stakeholders can change the requirements and influencing factors
‣ Feedback is incorporated in design decisions
‣ Early risk mitigation and problem prevention
‣ Improve quality with each cycle

Iterative:
Doing the same steps repeatedly

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.4: “A general model of software architecture design…” Hofmeister et al. [Hof2007]
252
Architecture Development Approaches
Iterative and Incremental Design 3/3
Incremental process
‣ Multiple smaller steps rather than one giant step
‣ Reduces complexity
‣ Partial solutions
‣ Smaller focus

Increment:
Add a (small, more manageable) amount/quantity/set,
i.e., a runnable set of functionalities that extends the
existing software system, usually created as a result
of an iteration.

iSAQB CPSA-F – 7. Design Approaches and Methods 253

Architecture Development Approaches
View-Based Architecture Development (1/7)
Many views of a system
‣ each with its own, individual focus.
In a view, certain aspects are emphasized, others are omitted.
Specialization of views → better handling of complexity.
Views are not entirely independent.
‣ Certain information may occur several times.
Views should be consistent.
‣ They should not contradict each other.

Different development approaches have their specific “opinions” as to which views are
sensible and how they are named.

iSAQB CPSA-F – 7. Design Approaches and Methods 254

Architecture Development Approaches
View-Based Architecture Development (2/7)
iSAQB architecture views
Context view Deployment view
(context demarcation) Deployment Units
Nodes
High-level view Computers
Interfaces Processes
System as a black box Networks
Architecture
Building-block view Run-time view
(static structure)
Interaction
Building blocks Performance
Interfaces Synchronization
Layers, Relations
Responsibilities
iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.5 255
Architecture Development Approaches
View-Based Architecture Development (3/7)
Different schools define their own views respectively

iSAQB Views: Context, Building Block, Runtime, Deployment

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.6 256

Architecture Development Approaches
View-Based Architecture Development (4/7)
– Context View
‣ The system being designed is depicted as a black box Context view
(context demarcation)
Deployment view
Deployment units
‣ External actors (e.g., systems, users) High-level view
Nodes
Computers

‣ All interfaces to the outside world

Interfaces Processes
System as a black box Networks
Architecture

− Interface Type (online, batch, USB, file, etc.) Building-block view

(static structure)
Run-time view

− Communication protocols
Interaction
Building blocks Synchronization
Interfaces Performance

− Communication patterns
Layers, Relations
Responsibilities

(sync/async, push/pull, …)
‣ May provide an overview of the most important use
cases of the system from an external perspective

‣ Relevance:
− Entry point and overview for the system being
designed
iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.7 257
Architecture Development Approaches
View-Based Architecture Development (5/7)
– Building-Block View
‣ Explains the static decomposition of the system into Context view
(context demarcation)
Deployment view
Deployment units

building blocks (components, sub-systems, partitions, High-level view

Nodes
Computers
Interfaces Processes
packages, classes, procedures, functions, …). System as a black box
Architecture
Networks

‣ Describes building blocks and their relationships Building-block view

(static structure)
Run-time view

Interaction
(interfaces, dependencies, associations, relations, …). Building blocks
Interfaces
Synchronization
Performance
Layers, Relations

‣ Contains static aspects of the system. Responsibilities

‣ Relevance:
− Support project management with defining work packages
− Helps stakeholders to understand the system
(especially developers)
iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.8 258
Architecture Development Approaches
View-Based Architecture Development (6/7)
– Deployment View
‣ Deployment of run-time elements to hardware Context view
(context demarcation)
Deployment view
Deployment units
components (e.g., servers, hosts, docker containers, ...) High-level view
Nodes
Computers

‣ Logical channels + physical channels they are

Interfaces Processes
System as a black box Networks
Architecture
based upon. Building-block view
(static structure)
Run-time view

‣ Technical components and their run-time attributes such

Interaction
Building blocks Synchronization
Interfaces Performance
as availability. Layers, Relations
Responsibilities

‣ Capacity of networks and memory

«device» «device»
‣ Relevance: DBServer PDA

− Communicate with operations (administrators, etc.) «deploy»

− Configure and administer the run-time environment «artifact»

Order.jar
− Recognize bottlenecks, calculate costs, identify risks «manifest» «component»
Order

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.9 259

Architecture Development Approaches
View-Based Architecture Development (7/7)
– Runtime View
‣ Building blocks participating in execution of a use Context view
(context demarcation)
Deployment view
Deployment units

case High-level view

Nodes
Computers
Interfaces Processes
‣ How the system components interact at runtime System as a black box
Architecture
Networks

‣ Which processes and threads there are, if applicable

Building-block view Run-time view
(static structure)
Interaction

‣ How the system starts and terminates orderly

Building blocks Synchronization
Interfaces Performance
Layers, Relations
Responsibilities
‣ Which building block instances are available at
runtime and their lifecycles
a:A b:B c:C
‣ Relevance: m1
m2
− Help developers to understand the system m3
− Communicate with operations (administrators, etc.)

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.10 260

Architecture Development Approaches
Top-Down and Bottom-Up 1/3

Top-down
‣ Decomposition into smaller
problems (analysis)

‣ Starting point: Vision of the

complete system ‣ Assembly of
partial solutions
and/or subsystems
(synthesis, composition)

‣ Starting point: Libraries, sub

functions, domain classes

Bottom-up
iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.11 261
Architecture Development Approaches
Top-Down and Bottom-Up 2/3
Top-Down

Advantages Disadvantages
General understanding of the (Possibly) difficult integration at the end
problem
Independent of hardware and Existing solutions might be ignored to solve at
programming language least part of the overall problem.
No getting lost in the details. Some Problems that are identified late in the process
problems might be easier to identify might cause serious and costly changes
from an overall perspective.
Consistency, clean-cut distribution of Late feedback as to whether the design is
responsibilities and interfaces. suitable
Design is visible in the product
iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.12 262
Architecture Development Approaches
Top-Down and Bottom-Up 3/3
Bottom-Up

Advantages Disadvantages
Typically, existing components are Often not all parts or functions are needed.
reused. → increased complexity, potentially more bugs
Incremental testing leads to high Orientation towards technical factors instead of
satisfaction of the users users‘ requirements
Stepwise integration (Possible) danger of premature optimization
Real sub-problems are the starting Danger of uncontrolled growth
point (“Frankenstein-Architecture”)

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.13 263

Architecture Development Approaches
Hierarchical Decomposition – Principles
When decomposing the architecture
into building blocks consider:
SOLID principles
Loose coupling and high cohesion
Designing in iterations
Reuse of established and proven
structures
Which alternative solutions for
decomposing the system or building
blocks exist?
‣ Identify and assess strengths and
weaknesses of those alternatives.

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.14: from [Gharbi+2019] 264
Architecture Design Methods
Domain Driven Design - Approach
Identify the system’s business domain.
Create a domain model using the user‘s language
Discuss the model with the domain experts
Use the domain model as a basis for the system design
Identify subdomains and map them to bounded contexts
in the solution space.

Three pillars of DDD:

‣ Ubiquitous language
‣ Strategic Design
‣ Tactical Design

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.15 265

Architecture Design Methods
Domain Driven Design – Isolating the Domain
User interface layer (presentation layer)
‣ Present information to the user
‣ Receives input and interprets user commands
Application layer
‣ Coordinates tasks and delegates work to domain objects
‣ Does not contain business rules or knowledge!
‣ State reflecting the task for users, but not on business situation
‣ Can be omitted if its tasks are accomplished in the domain layer.
Domain layer (model layer)
‣ Concepts of the business, business situation, and business rules
Infrastructure layer
‣ Comprises technical services, e.g., persistence, security, or
communications with other systems

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.16: according to Eric Evans [Evans2003] 266
Architecture Design Methods
Domain Driven Design – Elements of the Domain Layer 1/2

Entities: The core objects of a

business domain with unchangeable
identity and a clearly defined lifecycle.
Entities are almost always persistent.

Value Objects do not have an identity

of their own, they describe the state of
other objects and are immutable.
They may me composed of other
Value Objects but never of Entities.

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.17: derived from Eric Evans [Evans2003] 267
Architecture Design Methods
Domain Driven Design – Elements of the Domain Layer 2/2
Elements of the domain layer

Services implement logic or processes of the

business domain that are not executed by
Entities alone. Services are stateless.

Aggregates: complex object structures

made of Entities and Value Objects. They
have a root Entity and are regarded as a unit
when it comes to changes and define
transaction boundaries.

Factories and Repositories are responsible

for creating and persisting objects.

iSAQB CPSA-F – 7. Design Approaches and Methods 268

Architecture Design Methods
Hexagonal Architecture (Ports & Adapters)

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.18 269

Architecture Design Methods
Clean Architecture

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.19: derived from http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 270
Architecture Design Methods
Evolutionary Architecture
Incremental, guided change as the first
principle along multiple dimensions
‣ Continuous delivery
− Automate everything
− “done” = released
− Feedback from stakeholders
‣ Guide: Project-specific fitness functions
‣ Dimensions
− Technical
− Domain

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.20: from [Ford+2017] 271
Architecture Design Methods
Model Driven Software Development / Model Driven Architecture
Use models and generators/transformations
Models are:
‣ Directly interpreted by a virtual machine, or
‣ Transformed into executable applications

+ Efficient development
+ Easy changes
+ Include domain experts
+ Portability
– Complex, extensive infrastructure
(DSLs, modelling framework, generators)
MDA: levels of modeling

iSAQB CPSA-F – 7. Design Approaches and Methods Fig. C7.21 272

Summary
Summary / Wrap Up
At the end of this chapter, you should be able to explain:
‣ Iterative and incremental design
‣ View-based architecture development
‣ Top-down and Bottom-Up design approach,
‣ Architecture design methods, such as DDD, MDA,
Evolutionary Architecture HOW?

What’s next?
‣ Chapter 8: Documentation and Communication
‣ Chapter 9: Software Architecture Evaluation

iSAQB CPSA-F – 7. Design Approaches and Methods 273

References

Table of Figures
‣ C7.1: derived from ITech Progress slide deck
‣ C7.2: based on Waterfall vs. Agile. https://www.digite.com/blog/waterfall-to-agile-with-kanban. Last visited: 2021-02-17
‣ C7.3: ITech Progress
‣ C7.4: “A general model of software architecture design…” Hofmeister et al. [Hof2007]
‣ C7.5 - C7.10: WPS – Workplace Solutions GmbH
‣ C7.11 – C7.13: ITech Progress
‣ C7.14: derived from ITech Progress and [Gharbi+2019]
‣ C7.15: WPS – Workplace Solutions GmbH
‣ C7.16: according to Eric Evans [Evans2003]
‣ C7.17: derived from Eric Evans [Evans2003]
‣ C7.18: WPS – Workplace Solutions GmbH
‣ C7.19: derived from http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html. Last visited: 2021-02-17
‣ C7.20: from [Ford+2017]
‣ C7.21: MDSD generation workflow: own drawing by WPS – Workplace Solutions GmbH/Bernd Hauck

iSAQB CPSA-F – 7. Design Approaches and Methods 274

References

Literature Sources
‣ [Evans2003] Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart ofSoftware, Addison-Wesley, 2003.
‣ [Ford+2017] Neal Ford, Patrick Kua, and Rebecca Parsons. Building EvolutionaryArchitectures: Support Constant Change. O'Reilly, 2017.
‣ [Gharbi+2019] Mahbouba Gharbi, Arne Koschel, Andreas Rausch: Software ArchitectureFundamentals- A Study Guide for the Certified
Professional for Software Architecture®,dpunkt, 2019.
‣ [Hof2007] Hofmeister, C., Kruchten, P., Nord, R. L., Obbink, H., Ran, A., & America, P.(2007). A general model of software architecture
design derived from five industrialapproaches. Journal of Systems and Software, 80(1), 106-126.

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 7. Design Approaches and Methods 275

8. Documentation and
Communication
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C8_v1.0.0-EN-1_2023-07-26
Overview
Goals, Benefits and Quality of Documentation

Template Based Documentation and arc42

Document Types and Diagram Types

Use Views to Separate Architectural Concerns

Documenting Cross Cutting Concerns, Interfaces and Architecture

Decisions

Best Practices Rules

Architecture Description Frameworks

iSAQB CPSA-F – 8. Documentation and Communication 277

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.1 278

Why Architecture Documentation?

Source code is a low-level abstraction, it does not contain

‣ Overall large-scale structure
‣ Architectural decisions
‣ Rationale for those decisions
‣ Technology choices
‣ Description of cross-cutting concerns
‣ …
Over the lifetime of a system, documentation helps to In large IT systems, costs for
‣ Maintain a clear overview of the system these activities correlate with
‣ Locate and fix errors/problems quickly the quality of the architecture
documentation.
‣ Fulfill changing requirements with reasonable effort
‣ Keep up with technological changes

iSAQB CPSA-F – 8. Documentation and Communication 279

Verbal and Written Communication
Complement Each Other

Written communication Verbal communication

‣ Documents and models ‣ Explain, present, discuss
‣ Summarized and curated ‣ Quick feedback, decision making
Long-term usage Focuses on temporary information
Slower, time-consuming, exchange leading to (hopefully)
often uni-directional quicker mutual understanding.
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.2: from [Starke2020] 280
Documentation and Communication
Level of Detail
Basic Documentation
High-level architecture: Building blocks
Structure and interaction of Interaction of building blocks
components Source code structure
Technical infrastructure
Basic assumptions, decisions,
Software architecture technologies, and concepts
documentation
Additional Documentation
Different recipients:
Detailed architecture: ‣ Customers
Detailed description of components, ‣ Managers
interfaces and design decisions ‣ Developers
‣ Administrators
high risk → more extensive documentation

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.3 281

Quality Requirements for Software
Architecture Documentation
Tailor form, content, and level of detail to
stakeholders and the target audience

Strive for brevity and conciseness

Understandability can only be judged by the
readers of the document

iSAQB CPSA-F – 8. Documentation and Communication 282

Template-Based Documentation
Benefits
Explicit, well defined, re-usable structure
‣ Where do I find documentation about …?
‣ Where should documentation about … be placed?
‣ What is still missing?
Templates consolidate best practices and possibly tooling across projects
Increased efficiency during creation and use
Provides sub-templates for common artifacts
‣ Black and white boxes, interfaces, …

iSAQB CPSA-F – 8. Documentation and Communication 283

Template-Based Documentation
arc42 – Overview
Supports software- and system architects
Template for development, documentation, and communication of software architectures
Can be applied to a variety of documentation technologies and tools
Available in many languages, with and without documentation guidelines
Free, even for commercial applications.

by the way
42 → “The Answer to the Ultimate Question of Life, the Universe, and Everything”

iSAQB CPSA-F – 8. Documentation and Communication 284

Template-Based Documentation
arc42 – Contents 1/4
Chapter 1: Introduction and Goals
Essential requirements and driving forces
Top 3–5 quality goals from important stakeholders

Chapter 2: Constraints
Constraints to the design and implementation

Chapter 3: Context and Scope

Delimits your system
Overview of external interfaces
Business/domain perspective (always)
Technical perspective (not always required)

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.4: from [arc42] 285
Template-Based Documentation
arc42 – Contents 2/4
Chapter 4: Solution Strategy
Fundamental decisions and solution strategies
Technology, top-level decomposition
Approaches to achieve prioritized quality goals
and relevant organizational decisions

Chapter 5: Building Block View

Static decomposition of the system
White boxes → black boxes

Chapter 6: Runtime View

Behavior of building blocks for specific scenarios
Implementation of important use cases or features
Critical external interfaces
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.5: icon by Maxim Kulikov Fig. C8.6: images from [arc42] 286
Template-Based Documentation
arc42 – Contents 3/4
Chapter 7: Deployment View
Technical infrastructure with environments
Computers, processors, topologies
Map of building blocks to infrastructure elements

Chapter 8: Cross-cutting Concerns

System-wide principles, guidelines, and solutions
Cross-cutting concerns and concepts

Chapter 9: Architectural Decisions

Important, expensive, critical, large-scale, or risky
architecture decisions including rationale

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.7: from [arc42] 287
Template-Based Documentation
arc42 – Contents 4/4
Chapter 10: Quality Requirements
Architecturally relevant quality requirements
Relevant scenarios
Quality tree

Chapter 11: Risks and Technical Debt

Known technical risks or technical debt
Potential problems internal or external to the system

Chapter 12: Glossary

Important domain and technical terms
Translation reference

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.8: icon by Symbolon, IT Fig. C8.9: images from [arc42] 288
Template-Based Documentation
ISO-42010 Contents of an Architecture Document
Architecture description identification and overview
‣ System identification, additional information (name, change history, etc.),
‣ Architecture overview, architecture assessments, rationale for important decisions
Stakeholders and concerns
Definition of viewpoints
‣ Name of the viewpoint, mapping to stakeholder concerns, model types and conventions
Views and models
‣ Name, description, and models
Correspondences rules, correspondences, inconsistencies
Architecture decisions and rationales

iSAQB CPSA-F – 8. Documentation and Communication 289

Common Document Types 1/2

Central architectural description

All relevant information: architecture goals (vision), quality requirements, views, decisions,
patterns, and additional, necessary information. One or more centrally located documents.

Architectural overview
Summary of the central architecture description, covering only the essential points. Can serve
as a minimum substitution for the complete description.

Document Summary
A list of all architecture-related documents

Overview presentation
Set of slides to give an overview of the architecture or specific parts of the architecture

iSAQB CPSA-F – 8. Documentation and Communication 290

Common Document Types 2/2

Architecture “wallpaper”
Many aspects of the architecture on a single, very large output (e.g., printout or flipcharts) too
big to fit on a computer screen or single sheet of paper, usually hung from a wall (hence
wallpaper). It can serve as a basis for discussion between architects and developers.

Guide for Documentation

The manual explains the function and the structure of the documentation. It is also a good
place to explain the collection of notations.

Technical information
One or more documents containing important information for developers and testers. It should
contain information about development methodologies, code conventions, build and test.

iSAQB CPSA-F – 8. Documentation and Communication 291

Using Diagrams and Illustrations
Common Graphical Notations, e.g., UML, and Alternatives
Using Diagrams and Illustrations

PRO
‣ Often easier to understand
‣ Appeals to visual memory
CON
‣ High effort to create and maintain
‣ Might be misleading if not explained properly

UML is not always the best solution to

document everything.

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.10: http://geek-and-poke.com/geekandpoke/2012/1/28/simply-explained.html 293

UML 2.5 Diagrams
Overview

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.11: derived and adapted from [VisPar1] 294
UML 2.5 Diagrams
Class Diagram

R2
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.12: derived from [VisPar2] 295
UML 2.5 Diagrams
Package Diagram

R2
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.13: derived from [VisPar3] 296
UML 2.5 Diagrams
Component Diagram

R2
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.14: Component Diagram derived from [UMLD1] 297
UML 2.5 Diagrams
Composite-Structure Diagram

R3
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.15: Composition-Structure Diagram from [UMLD2] 298
UML 2.5 Diagrams
Deployment Diagram

R2
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.16: Deployment Diagram from [UMLD3] 299
UML 2.5 Diagrams
Sequence Diagram

R2
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.17: Sequence Diagram from [UMLD4] 300
UML 2.5 Diagrams
Activity Diagram

R2
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.18 301
UML 2.5 Diagrams
State Machine Diagram

R3
iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.19: State Diagram from [UMLD5] 302
Alternatives to UML

Business Process Model and Notation (BPMN)

‣ For the modeling of business processes and operational procedures
‣ Standard since 2013 in ISO/IEC 19510:2013

ArchiMate
Flow charts, (numbered) lists, pseudo code

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.20: Example BPMN Diagram303
Documenting Views
Views: Separate Architectural Concerns
Four Proven View Types
Context view Runtime view
‣ Shows the entire system in the context ‣ Shows instances of the system’s
of its environment components (building blocks) during
‣ Interfaces to neighboring systems runtime
‣ Interactions with users/external systems ‣ Describes the dynamic interaction of these
‣ Reflects the “vision” of the system run time instances

Building block view Shows Deployment view

‣ Static structure of the system ‣ Hardware components used in the system
‣ Decomposition into subsystems, ‣ Computer, processors, networks, protocols
components, and their interfaces ‣ Distribution of delivery artifacts of the
‣ Relations and dependencies system on the hardware
‣ Basis for planning work packages ‣ Perspective of IT operations

iSAQB CPSA-F – 8. Documentation and Communication 305

Interrelationship Between Views

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.21 306

Context View
Purpose
Conceptual overview of the system
“birds eye perspective”
‣ External view of the system, typically as black box
‣ May include high-level white-box views
of top-level components.

Shows
You are responsible
‣ All** external interfaces of system
‣ All** neighboring systems and exchanged data for this!
** depending on the stakeholders of the documentation

Entry point and overview of the system for all stakeholders

Initial link between requirements specification and architecture

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.22 307

Context View
Stakeholders of the Context View
Designers, architects, and developers
Project Management
Requirements engineers, product owner, and systems analysts (provide input)
Technical or domain experts (provide input)
Testers
IT Operations
Project controlling (e.g., allocation of development resources)
Sales, marketing (for IT products)

iSAQB CPSA-F – 8. Documentation and Communication 308

Context View
Elements and Notations
External view of the system being developed
List of interfaces to external systems and users User (Old)
Mainframe
system
Most important high-level use cases Reports,
Statistics
Possibly high-level abstractions of the building (original)
Account
block, runtime and deployment view (where data
appropriate). Migration
System System
Almost any notation is applicable. under
Design

(migrated)
The content of the context view depends on Account data
what is relevant for the specific system as
(New) Web
well as the stakeholder needs. Account System Data
flow

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.23: derived from [Starke2020] 309
Building-Block View
Purpose
Maps functional and non-functional requirements of the system to a static structure of
building blocks
Describes components, packages, classes, subsystems, and/or partitions as parts of the
system
‣ What are the dependencies between these building blocks?
‣ Which building blocks map to which requirements?
‣ Which building blocks are implemented, which are configured, and which are
implemented with purchased components ?

iSAQB CPSA-F – 8. Documentation and Communication 310

Building-Block View
Elements and Notations
UML Class Diagram Component diagram
‣ Classes in object-oriented systems Package diagram
Composite structure diagram
UML Package Diagram
Class diagram
‣ Subset of building blocks from a
development perspective
‣ No further concrete abstractions
‣ Will be refined in other notations
UML Component Diagram
‣ Individual modules
‣ Detailed description of the in-
and outbound interfaces

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.24 311

Building-Block View
Black Box Template
Title Content
Purpose / responsibility (black-box) component being described
Responsibility (short description)
In- and out-bound In- and out-bound interface that the black-box building block
interfaces provides to, or uses from, others. Semantics: call-return,
synchronous/asynchronous, push/pull, events
Requirements fulfilled Reference to the relevant requirements
Qualities & Constraints Quality characteristics and constraints
Location / file Source code location of the building block
Other management Author, version, date, change history
information
Open Issues Everything still needing clarification

iSAQB CPSA-F – 8. Documentation and Communication 312

Building-Block View
White Box Template
Title Content
Overview diagram A diagram showing the internal structure of the white-box
building block.
Motivation Explanation why this refinement has been chosen, potentially
also mentioning alternatives that have been considered
Internal building blocks Table or list of internal building blocks as black boxes . Their
internal structure can, in turn, be represented in an additional
refinement level.
Internal relationships Table or list of dependencies and relationships between the
internal black-box building blocks
Design decisions Reasons which led to this structure – or the rejection of
alternatives. Implications of these choices.

iSAQB CPSA-F – 8. Documentation and Communication 313

Runtime View
Purpose
Run-time instances of building blocks
How do the building blocks of the system collaborate?
‣ Data flow
‣ Control flow
How are the most important use cases executed?
How are their life cycles triggered and monitored?
How are external components triggered?
What happens when you start and stop the system?
‣ Start/stop scripts
‣ Order (dependency) for usage of subsystems
‣ Lifecycle for using external subsystems
(database, communication systems)

iSAQB CPSA-F – 8. Documentation and Communication 314

Runtime View
Elements and Notations
Software architecture building blocks which can be Activity diagram
instantiated at runtime
Sequence diagram
‣ Not valid for all building blocks, especially not for
abstractions State diagram
Process flow
Relationships between the run-time elements
BPMN diagram
‣ In the form of data and control flows
Sequential list
Pseudo code
...

iSAQB CPSA-F – 8. Documentation and Communication 315

Deployment View
Purpose
Show nodes of technical infrastructure
‣ Hardware and middleware components
‣ Channels and connections
‣ Serves as a map of the involved hardware and neighboring systems
Describe runtime environment features
‣ Operating system
‣ Application platform
‣ Configuration parameters
Characteristics of nodes and channels
‣ Memory sizes, capacities, quantity
‣ Can be used to determine potential bottlenecks
‣ Enables the documentation of limited availability (nightly backup, batch run times)

iSAQB CPSA-F – 8. Documentation and Communication 316

Deployment View
Elements and Notations
Nodes
‣ Part of technical infrastructure
‣ Physical devices (computers, processors,
firewalls, routers, or storage)
‣ Logical systems (middleware platforms)
Channels
‣ Connections between nodes Deployment diagram
(physical channels)
‣ Connections between runtime artifacts Informal diagrams
(logical channels)
Tables and lists
Runtime artifacts
‣ Executables (e.g., DLLs, .jar, .exe), ...
data (databases, configuration, …)
‣ Containing elements of the system(docker containers, virtual machines, …)
‣ Are created from the build process and installed on nodes

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.25 317

Additional (specialized) Views

Provide additional views according to stakeholder needs

‣ e.g., individual aspects of components as individual views
Examples:
‣ Depiction of the high-level architecture for communication to management
‣ Data view, security view
Consider:
‣ Implications of creating and maintaining additional views
‣ Additional detailed explanation of special notations
‣ The four presented view types are usually sufficient

iSAQB CPSA-F – 8. Documentation and Communication 318

Interdependency Between Views

Changes to one view can have an impact on other views, either positive or negative

Ensure that the architecture views are updated in each iteration of an iterative approach

Special reciprocal effects should be documented

‣ Design decisions should be traceable back to the requirements or constraints
‣ Can the impact of architectural changes be easily reflected in the different views
without a lot of effort?

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.21 319

Which Views Should Be Created First?

Views are mostly developed in parallel with incremental updates.

It depends. Usually, the context view is good point to start.

Start with the building block view when

‣ You have experience and existing knowledge with similar systems
‣ Components that are required by the system are clear.
‣ Components of a systems already exist and will only be changed.
Start with the runtime view when
‣ Essential components are known, but their interaction and responsibilities are not clear
Start with the deployment view when
‣ There are many constraints and requirements
(infrastructure, operations, administration, ...)

iSAQB CPSA-F – 8. Documentation and Communication 320

 Documentation for
Cross-Cutting Concerns, Interfaces, and Design Decisions
Document Cross-Cutting Concerns
Suggested Structure
Outline the tasks and requirements to be fulfilled by the solution approach.
Identify the constraints on the solution
Present the solution approach
‣ if possible, with code examples (“reference implementation”)
Specify, and provide the rationale for, the structures and dynamic behavior
Provide supporting references (literature, web resources, standards) as rationale for the
decisions
Specify risks, trade-offs, and side effects
Describe the alternatives that were considered and why they were rejected

iSAQB CPSA-F – 8. Documentation and Communication 322

Documentation of Interfaces
What Is Important?
Well-designed and documented internal and external interfaces are the backbone of a
maintainable architecture.

Specification of external interfaces can require a lot of effort

‣ It’s critical to specify the interfaces in the early project stages when things are easier to
change and to adapt.
‣ Plan for API evolution and versioning if necessary.
‣ Use tools (e.g., Swagger) or API description languages when appropriate.
‣ Test cases can be a resource for interface documentation (see Chapter 5)
‣ Some stakeholders may require a stand-alone interface documentation.
‣ Provide templates for interface documentation, which provide a common structure, etc.

iSAQB CPSA-F – 8. Documentation and Communication 323

Documentation of Interfaces
Example Template
Title Content
Identification Exact name and version of the interface
Provided resources Resources that are provided by the interface
‣ Syntax of resource: API, Method signature
‣ Semantic of resource
Impact of calling the resource
‣ triggered events, changed data, altered states, other side effects,
restrictions on the use of the resource
Error scenarios Description of error scenarios and their handling
Variability and Changeability or configurability of the behavior (example via
configurability configuration parameters)
Quality attributes Required quality attributes (availability, performance, security, … )
Design decisions Rationale for the interface design decisions and rejected alternatives
Notes Additional notes, usage examples

iSAQB CPSA-F – 8. Documentation and Communication 324

Documentation of Decisions and Rationale
ADR – Architecture Decision Record
Title and Decision-ID (sequential, monotone, unique)
Status
E.g., proposed/pending, accepted, rejected, superseded by ADR <nr>, deprecated, …
Context
The issue that motivates the decision or change
Decision
The change that is being proposed
Rationale
Explanation for selecting or rejecting design alternatives
Consequences
Impact of the decision, e.g., future changes will be easier or more difficult.

see https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
iSAQB CPSA-F – 8. Documentation and Communication 325
Best Practices
Documentation - Best Practices
The following slides contain best practices
for creating and maintaining an adequate
architecture documentation.
Think before you break them.
Some of the following rules are based on
Clements et al., Documenting Software
Architectures; Addison Wesley, 2011.

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.26: https://geek-and-poke.com/geekandpoke/2012/4/25/the-new-developer.html 327

Documentation Best Practices
Use a Standardized Structure
Use standardized structures and templates
‣ uniform documentation with consistent structure
‣ increases efficiency to create and use
‣ What is missing? What do I have to document? Where?
‣ Quality assurance: all aspects to be covered are defined in advance

Provide templates for e.g.

‣ Building blocks and structures (black boxes, white boxes)
‣ Architecture Decisions (ADRs)
‣ Interfaces

Ensure compliance with the structure!

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.27: derived from katemangostar 328
Documentation Best Practices
Write From the Readers’ Perspective
Will the information requirements of the reader be satisfied?
‣ Or readers may find his/her requirements
were not taken seriously
Get feedback from target groups
‣ Customers, developers, operations, …
Less is more!
‣ Time spent on concise writing is
saved when reading the documentation many times over.
Structure: write thoughts and ideas in a logical or required sequence
Use active voice and explain motivations
KISS: Avoid unnecessary technical jargon, explain technical terms

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.28: derived from katemangostar 329
Documentation Best Practices
Avoid Repetitions and Redundancy
Avoid unnecessary repetition!
Only if necessary – use sparingly and selectively:
‣ Is the variation/repetition intentional?
‣ What purpose does it serve?
(e.g., perspective of another stakeholder)

Simplifies the use of documentation

Increases efficiency
Reduces effort for maintenance and changes
Documentation from different perspectives can lead to redundancy but is necessary to
increase understandability.

iSAQB CPSA-F – 8. Documentation and Communication 330

Documentation Best Practices
Avoid Ambiguity
Ambiguity can lead to inefficient conversations due to different interpretations
Use formal description languages if applicable.
Use self-descriptive names for domain objects.
‣ Pay attention to possibly ambiguous terms in use.
Link to a glossary for an explanation of terms.
Verify if things can be misunderstood.

RED YELLOW GREEN

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.29 331
Documentation Best Practices
Provide a Rationale for Decisions
Help readers understand the architecture decisions and their implications.
‣ A decision includes the reasoning that led to that decision.
‣ Advantages/disadvantages of decisions are usually not obvious.
Provide a written justification of important decisions to
‣ Traceability back to requirement and constraints increases understanding
‣ Eliminate endlessly repetitive discussions
‣ Save time when decisions need to be reconsidered when conditions change
Also track:
‣ Explicitly discarded alternatives
‣ Analysis of advantages and disadvantages of alternatives
Pro tip: use ADRs – Architecture Decision Records

iSAQB CPSA-F – 8. Documentation and Communication 332

Documentation Best Practices
Unclutter Diagrams
Illustrations should not impress but enlighten.
Avoid too large or too complex diagrams
Consider the 7 +/- 2 rule
‣ Five to nine elements in diagrams are
an optimum for understandability
‣ Exception: “architectural wallpaper”
Provide a description for diagrams
Provide a legend
‣ Element catalogue
(table or list of elements in the diagram)

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.30: http://geek-and-poke.com/geekandpoke/2009/11/2/enterprise-architecture-made-easy-part-1.html 333

Documentation Best Practices
Keep Documentation Current
Regularly update documentation during development and maintenance!
Lack of a consistently used maintenance process for documentation leads to ...
‣ inconsistent and outdated documentation
‣ reduced benefit and usage of documentation
‣ unnecessary inquiries from other stakeholders (especially architects or developers)
‣ decreased motivation for creating and maintaining documentation
(“broken windows theory”)
→ Result: documentation is not established as an authoritative source of
information (as it should be).

Do not update the documentation too often when design decisions change often
‣ Establish fixed, timely synchronization periods
‣ Versioning of documentation is useful
iSAQB CPSA-F – 8. Documentation and Communication 334
Documentation Best Practices
Communicate Status and Validity of Documentation
Documentation evolves!
‣ How current/outdated is the given information?
‣ How stable is it? Are changes to be expected?

Pro Tip: establish a change log at the beginning of ALL documents

‣ Date and version
‣ Author of changes
‣ Sections and/or topics that were changed

Establish version control for documentation as well.

iSAQB CPSA-F – 8. Documentation and Communication 335

Documentation Best Practices
Check for Suitability
Perform reviews before publishing
‣ Only the target user group can decide whether the right information is presented in the
right way.
‣ Let representatives of the target group participate in the documentation process.
‣ New team members are a valuable source for feedback.
Implement an improvement process for documentation
‣ Periodically validate the documentation based on predefined documentation guidelines.
‣ Improve the documentation guidelines, if necessary.

iSAQB CPSA-F – 8. Documentation and Communication 336

 Additional Resources
Other Frameworks for the Description of Software Architectures
C4 Model
C4 Model for Visualizing Software Architecture
Level 1 Level 2
by Simon Brown
Context Container
Decomposition of the system
into containers and components
“Maps of code” at different level
of detail
Small, easy-to-learn set of
abstractions Level 4 Level 3
Code Components

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.31: derived from https://c4model.com/ 338
C4 Model
Level 1 - Context

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.32: derived from https://c4model.com/ 339
C4 Model
Level 2 - Container

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.33: derived from https://c4model.com/ 340
C4 Model
Level 3 - Components

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.34: derived from https://c4model.com/ 341
C4 Model
Level 4 - Code

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.35: derived from https://c4model.com/ 342
Other Architecture Description Frameworks
RM-ODP
Reference Model of Open
Distributed Processing
ISO-standard since 1996
Meta model for describing
information systems

Tailored to object-based systems

iSAQB CPSA-F – 8. Documentation and Communication Fig. C8.36 343

Summary

By now, you should be able to

‣ Describe the purpose of architecture documentation
‣ Describe the quality requirements for architecture documentation
‣ Explain how verbal and written communication complement each other
‣ Explain various document types and notations, especially UML
‣ Explain and use arc42 as a documentation template and the four views provided by it
‣ Know how to document interfaces, cross-cutting concerns, and architectural decisions
‣ Apply best practices for documentation
‣ Name other architecture description frameworks

iSAQB CPSA-F – 8. Documentation and Communication 344

References

Table of Figures
‣ C8.1: derived from ITech Progress slide deck
‣ C8.2: Development cycle derived from WG Univeraities slide deck, derived from [Starke2020]
‣ C8.3: derived from Jemis mali. paper. https://thenounproject.com/term/paper/968444/. CC BY. Last visited: 2021-02-17
‣ C8.4: from [arc42]
‣ C8.5: derived from Maxim Kulikov. Light Bulb. https://thenounproject.com/term/light-bulb/1793376/. CC BY. Last visited: 2021-02-17
‣ C8.6 – C8.7: from [arc42]
‣ C8.8: derived from Symbolon, IT. Skull. https://thenounproject.com/search/?creator=1922003&q=Skull&i=3263616. CC BY. Last visited:
2021-02-17
‣ C8.9: from [arc42]
‣ C8.10: Geek & Poke. (2012). Simply Explained. https://geek-and-poke.com/geekandpoke/2012/1/28/simply-explained.html. CC BY 3.0. Last
visited: 2021-02-17
‣ C8.11: derived and adapted from [VisPar1]
‣ C8.12: derived from [VisPar2]
‣ C8.13: derived from [VisPar3]
‣ C8.14: Component Diagram, derived from [UMLD1]
‣ C8.15: Composition-Structure Diagram from [UMLD2]
‣ C8.16: Deployment Diagram from [UMLD3]
‣ C8.17: from [UMLD4]

iSAQB CPSA-F – 8. Documentation and Communication 345

References

Table of Figures
‣ C8.18: redrawn from WG Universities slide deck
‣ C8.19: from [UMLD5]
‣ C8.20: Example BPMN Diagram, derived from https://de.wikipedia.org/wiki/Business_Process_Model_and_Notation. Last visited: 2021-02-
17
‣ C8.21 – C8.22: ITech Progress slide deck
‣ C8.23: derived from [Starke2020]
‣ C8.24 – C8.25: ITech Progress slide deck
‣ C8.26: Geek & Poke. (2012). The New Developer. https://geek-and-poke.com/geekandpoke/2012/4/25/the-new-developer.html. CC BY 3.0.
Last visited: 2021-02-17
‣ C8.27 – C8.28: derived from katemangostar. (2020). Set geschäftsleute mit klemmbrettern Kostenlosen Vektoren.
https://de.freepik.com/vektoren-kostenlos/set-geschaeftsleute-mit-klemmbrettern_5562386.htm#page=4&position=35. CC0. Last visited:
2021-02-17
‣ C8.29: own work
‣ C8.30: Geek & Poke. (2009). Enterprise Architecture Made Easy – Part 1. https://geek-and-poke.com/geekandpoke/2009/11/2/enterprise-
architecture-made-easy-part-1.html. CC BY 3.0. Last visited: 2021-02-18
‣ C8.31 – C8.35: derived from https://c4model.com/. Last visited: 2021-02-18
‣ C8.36: ITech Progress slide deck

iSAQB CPSA-F – 8. Documentation and Communication 346

References

Literature Sources
‣ [Starke2020] Gernot Starke: Effektive Softwarearchitekturen: Ein praktischer Leitfaden. 9.Auflage, Hanser, 2020.
‣ [VisPar1] Visual Paradigm: Overview of the 14 UML Diagram Types https://www.visual-paradigm.com/guide/uml-unified-modeling-language/overview-of-
the-14-uml-diagram-types/ (last visited 2021-02-03)
‣ [VisPar2] Visual Paradigm: UML Class Diagram Tutorial https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
(last visited 2021-02-03)
‣ [VisPar3] Visual Paradigm: What is Package Diagram? https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-package-diagram/
(last visited 2021-02-03)

Websites
‣ Cognitect. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions. Last visited: 2021-02-18
‣ [UMLD1] ULM Diagrams. https://www.uml-diagrams.org/component-diagrams.html. Last visited: 2021-02-18
‣ [UMLD2] ULM Diagrams. https://www.uml-diagrams.org/composite-structure-diagrams.html. Last visited: 2021-02-18
‣ [UMLD3] ULM Diagrams. https://www.uml-diagrams.org/deployment-diagrams-overview.html. Last visited: 2021-02-18
‣ [UMLD4] ULM Diagrams. https://www.uml-diagrams.org/sequence-diagrams.html. Last visited: 2021-02-18
‣ [UMLD5] ULM Diagrams. https://www.uml-diagrams.org/bank-atm-uml-state-machine-diagram-example.html. Last visited: 2021-02-18

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

iSAQB CPSA-F – 8. Documentation and Communication 347

9. Software Architecture
Evaluation
iSAQB certification program
Certified Professional for Software Architecture
Foundation Level (CPSA-F)

CPSA-F-C9_v1.0.0-EN-1_2023-07-26
Overview

Goals of Architecture Evaluation

Modelling and Describing Quality

Quantitative and Qualitative Analysis

Architecture Evaluation/Analysis Methods

iSAQB CPSA-F – 9. Software Architecture Evaluation 349

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.1 350

Why Is Quality So Important?

Evaluate suitability of a system with respect to

project goals and architecture goals.

Technical debt leads to architecture erosion

‣ Often caused by
− A lack of time and resources
− Lack of architecture refactoring
Architecture erosion leads to
‣ Decreased understandability of software
‣ Increased costs for even minor changes
‣ Decreased fulfillment of software quality goals

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.2: modified version of https://geek-and-poke.com/geekandpoke/2008/1/20/one-year-in-a-it-project-day-8.html 351
Quality and Quality Attributes
“Quality is the correspondence between the
observed properties and the previously defined
requirements of an observation unit.”
Definition of quality based on IEC 2371

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.3: http://geek-and-poke.com/geekandpoke/2010/9/7/how-to-ensure-quality.html 352

Quality Requirements
Analyze and Specify!
Derive required quality attributes from quality models (see next slide).

Quality goals might

‣ contradict project goals.
‣ support or contradict each other.

They should be exact and measurable, for example:

‣ New business rules can be defined in less than 4 hours.
‣ Files are parsed within 5 seconds or less.
‣ Application can be run with 1 Gigabyte of RAM.

iSAQB CPSA-F – 9. Software Architecture Evaluation 353

Quality Models

Describe software quality using specific criteria

Specify metrics to measure the software quality criteria
Are often called FCM models (Factor – Criteria – Metrics)
Well-known models:

1977 by Jim McCall et 1978 by Barry W. 1985 from HP International Standard

al. for US Air Force Boehm Quality attributes: ‣ replaces ISO/IEC
Three types of quality Similar to McCall, but ‣ “Functionality” 9126 (2005)
attributes: more detailed hierarchy ‣ “Usability” Guideline for System
‣ “Product revision” ‣ “As is utility” ‣ “Reliability” and software quality
‣ “Product operations” ‣ “Maintainability” ‣ “Performance”
models
‣ “Product transition” ‣ “Portability” ‣ “Supportability”
Model of Model of ISO/IEC
FURPS
McCall Boehm 25010

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.4 354

Quality Standard – ISO/IEC 25010

“… degree to which a software product satisfies stated and implied needs when used
under specified conditions.” [ISO 25010:2011]
‣ Aggregates attributes of a software product that relate to their suitability to fulfill defined
or required needs.
affects affects

Internal quality External quality Quality in use

Viewpoint of e.g., Viewpoint of e.g., Viewpoint of user in

software developers IT operations, user certain environment;
and architects Important: Context of use

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.5 355

Quality Attributes1 – ISO/IEC 250102

1 – also called “quality

characteristics”
2 – formerly ISO/IEC 9126
iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.6 356
Quality Attributes – ISO/IEC 25010

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.7 357

Quality Attributes – ISO/IEC 25010

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.8 358

Quality Trees

Quality goals can be structured as a quality tree.

Quality scenarios form the leaves of the tree, including their priorities.
A quality tree is specific to a particular system (quality model: generic)

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.9: illustration derived from [arc42] 359
Quality Scenarios

‣ Provide more detail for specific quality requirements

‣ Describe how a system should behave when a specific stimulus occurs
‣ Allow to easily measure and determine whether quality requirements are fulfilled
‣ Required for architecture quality assessments like ATAM

Three different kinds of quality scenarios: Not to be confused

with UML use cases!
‣ Usage Scenario (also called Application scenario)
‣ Growth Scenario (also called Change / Modification scenario)
‣ Exploratory Scenario (also called Boundary or Stress / Failure scenario)

iSAQB CPSA-F – 9. Software Architecture Evaluation 360

 Quality Scenarios
Usage, Growth, and Exploratory Scenarios

How does the system Modification of How should the

respond to a specific the system or its system respond to
trigger at runtime? environment extreme situations?

Exploratory Scenario
Usage Scenario Growth Scenario
(also called Boundary
(also called (also called Change or
or Stress / Failure
Application scenario) Modification scenario)
scenario)
Not to be
confused
with UML
use cases!
e.g. description of e.g. implementing an e.g. power failure
efficiency or performance additional functionality
Fig. C9.11 Fig. C9.12

Fig. C9.10

iSAQB CPSA-F – 9. Software Architecture Evaluation 361

Evaluation of Software Architecture

Is the architecture good enough?

‣ Identify risks
‣ Verify the achievement of quality goals (or lack thereof)
‣ Identify critical parts within the system
‣ Measure and compare with known (standard or past) metrics

“You cannot control what you cannot measure.”

Tom DeMarco

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.13: http://geek-and-poke.com/geekandpoke/2010/9/23/behind-the-lines.html 362

Types of Analysis and Assesment
Quantitative vs. Qualitative
1. Quantitative evaluation (software → some number)
‣ Measure, compare with known quantities
‣ (e.g. LOC, dependencies, complexity, test coverage, …)
‣ Problem cases: Concepts, structures, decisions, documents

2. Qualitative analysis and assessment

‣ Identification of risks
‣ Shows (non-)achievement of quality requirements

iSAQB CPSA-F – 9. Software Architecture Evaluation 363

Types of Analysis and Assesment
Static vs. Dynamic + Organizational
Analysis

Static: Dynamic:
‣ Metrics from static analysis ‣ Metrics from dynamic analysis
(LOC, coupling, complexity, …) (time and resource usage)
‣ Reviews of Code and Design ‣ Tests Metrics
‣ Audits of Code and Design • Performance Tests,
• Security Tests (Fuzzing)
• Usability Tests
Organizational, e.g.
‣ change/bugfix effort per subsystem
‣ number of errors per component

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.14 364

Quantitative Evaluation
Software Metrics Examples
Requirements Software process
‣ Rate of change ‣ Number of implemented / tested features over time
‣ Meeting time in relation to working time
Source Code ‣ Number of managers, developers, testers
‣ Coupling and cohesion
− Note: cohesion needs manual assesment Test
‣ Size in lines of code (LoC) ‣ Number of tests
‣ Complexity (e.g., McCabe, cyclomatic complexity) (all / per class or package / per requirement)
‣ Dependencies between building blocks ‣ Test coverage

Failure Design
‣ Mean time between failures ‣ Dependencies (inbound / outbound)
‣ Abstraction
‣ Stability
Watch out for error clusters!
‣ Distance
Components, where many errors have
been found, probably contain even more.

iSAQB CPSA-F – 9. Software Architecture Evaluation 365

Metrics
Goodhart‘s Law

“When a measure becomes a target, it ceases to be a good measure.”

Charles Goodhart

Consider:
What is the impact on e.g. test coverage and the meaningfulness of tests, if a certain
target metric is imposed for the acceptance of a merge request?

What can be done to prevent this?

Qualitative Analysis

Compare requirements and constraints against the solution (approach)

Assessments based on scenarios, they …
‣ … describe possible usages of the system by an actor
‣ … help to view architecture decisions from different perspectives
‣ … might help to identify quality criteria if there are no/poor requirements.

There are several methodologies for assessing architecture, e.g.,

‣ Architecture Tradeoff Analysis Method (ATAM)
‣ Decision Centric Architecture Review (DCAR)
‣ Cost Benefit Analysis Method (CBAM)
‣ Harris Profile

iSAQB CPSA-F – 9. Software Architecture Evaluation 367

Qualitative Analysis
ATAM
Architecture Trade-off Analysis Method
‣ Developed by the Carnegie Mellon University Software Engineering Institute
‣ Selection of a suitable software architecture for a software system
‣ Leading method in the area of software architecture evaluation
‣ Scenario-based assessment of software architecture regarding the fulfilment of quality
goals
‣ Focuses on three categories:
risks, trade-offs, and sensitivity points

iSAQB CPSA-F – 9. Software Architecture Evaluation 368

Qualitative Analysis
ATAM in a Nutshell

1
Gather information General process
about the target architecture applying to all
(i.e., quality goals) software evaluation
approaches
2
Assess actual system
concerning quality goals

3
Suggest
improvement actions

iSAQB CPSA-F – 9. Software Architecture Evaluation 369

Qualitative Analysis
ATAM Prerequisites

Architect

Required

Customer representatives, Software Architecture

or functional experts Documentation

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.15 370

Qualitative Analysis
ATAM Conceptual Scheme

Business Quality
Scenarios
Drivers Attributes
Analysis
Architectural Architectural Architectural
Plan Approaches Decisions

Tradeoffs

Impacts Sensitivity
Points

Non-Risks

Distilled into
Risk Themes Risks

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.16 371

Qualitative Analysis
The Steps of the ATAM

Phase 1 Phase 2

Presentation of Identification of
the ATAM Architectural
Method Approaches Brainstorming and
Prioritization of
Presentation of Scenarios
Generation of Presentation of
Business Quality Attribute the Results
Drivers Utility Tree Analysis of
Architectural
Approaches
Presentation of Analysis of
Architecture Architectural
Approaches

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.17 372

 Qualitative Analysis
ATAM: Quality Tree

Rick Kazman, Mark H. Klein, Paul C. Clements

ATAM: Method for Architecture Evaluation
Technical Report 08/2000
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13706.pdf

iSAQB CPSA-F – 9. Software Architecture Evaluation 373

 Qualitative Analysis
ATAM: Sample Agenda

Rick Kazman, Mark H. Klein, Paul C. Clements

ATAM: Method for Architecture Evaluation
Technical Report 08/2000
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13706.pdf

iSAQB CPSA-F – 9. Software Architecture Evaluation 374

Qualitative Analysis
ATAM: Evaluation
In small groups, together with the architect
Order according to priorities → Answering various questions

1. Which architecture decisions were made in order to achieve a scenario?

2. Which architectural approaches support the achievement of the scenario?
3. Which analysis, prototypes or studies support these decisions?
4. Were other quality features or architectural goals influenced?
5. Which compromises were made?
6. Which risks are identified?

iSAQB CPSA-F – 9. Software Architecture Evaluation 375

Proven Benefits of ATAM

Unique requirement for quality attribute

Improves architecture documentation
Documented basis for the architectural decisions
Identifies risks early in the life cycle
Improves communication between the stakeholders

iSAQB CPSA-F – 9. Software Architecture Evaluation 376

 R3
Other assessment methods
Alternatives to ATAM

Harris Profile

DCAR – Decision Centric Architecture Review

https://www.cs.rug.nl/~paris/papers/IEEESW14b.pdf
Getting Feedback from Stakeholders

Include stakeholders in the evaluation process

‣ ATAM
− Brings all stakeholders together
− Allows stakeholders to identify and prioritize the most important scenarios
− Intensifies discussion between stakeholders and the architect
‣ Prototyping is another option to get feedback from stakeholders

iSAQB CPSA-F – 9. Software Architecture Evaluation 378

Prototyping

‣ Evaluation of different approaches

− Technical spike vs. business prototype

‣ Early feedback from stakeholders → Lower risks

‣ Early quality assurance → Lower risks

− Quality assurance of requirements

‣ Helpful for quality analysis and assessment

iSAQB CPSA-F – 9. Software Architecture Evaluation 379

Kinds of Prototypes

‣ Demonstration prototype
− Acquisition
Caution,
danger!
‣ Prototype in the strict sense
− Analysis

‣ Laboratory sample
− Design questions

‣ Pilot system
− Product core

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.20: http://geek-and-poke.com/geekandpoke/2012/3/3/thank-god-not-everything-is-software.html 380

Summary
Summary / Wrap Up
At the end of this chapter, you should be
able to explain
‣ Why quality is important
‣ How to build a quality model
‣ What metrics are and how to apply them
‣ How to build quality trees and scenarios HOW?
‣ How to evaluate software architectures
using a structured analysis method

iSAQB CPSA-F – 9. Software Architecture Evaluation 381

Where Are We Now?

Start: Collect Design structures and

Identify risks
information, technical concepts
develop ideas
for system
Clarify requirements
and influencing
Tool based
factors

Architecture Implementation Communicate

End: review monitoring architecture
System
delivery

iSAQB CPSA-F – 9. Software Architecture Evaluation Fig. C9.1 382

References

Table of Figures
‣ C9.1: derived from ITech Progress slide deck
‣ C9.2: modified version of Geek & Poke. (2008). One Year In A IT Project – Day 8.
https://geekandpoke.typepad.com/geekandpoke/2008/01/one-year-in-a-i.html. CC BY 3.0. Last visited: 2021-02-19
‣ C9.3: Geek & Poke. (2010). How To Ensure Quality. http://geek-and-poke.com/geekandpoke/2010/9/7/how-to-ensure-quality.html. CC BY
3.0. Last visited: 2021-02-18
‣ C9.4: derived from ITech Progress slide deck
‣ C9.5: own work
‣ C9.6 – C9.8: WPS – Workplace Solutions GmbH
‣ C9.9: from WG Universities slide deck and derived from [arc42]
‣ C9.10 – C9.12: ITech Progress slide deck
‣ C9.13: Geek & Poke. (2010). Behind The Lines. http://geek-and-poke.com/geekandpoke/2010/9/23/behind-the-lines.html. CC BY 3.0. Last
visited: 2021-02-18
‣ C9.14: derived from ITech Progress slide deck
‣ C9.15 – C9.17: from ITech Progress slide deck
‣ C9.18: ITech Progress slide deck, contained in [Gharbi+2019], according to PHA derived from [arc42]
‣ C9.19: derived from [Gharbi+2019]

iSAQB CPSA-F – 9. Software Architecture Evaluation 383

References

Table of Figures
‣ C9.20: Geek & Poke. (2012). Thank God Not Everything Is Software. http://geek-and-poke.com/geekandpoke/2012/3/3/thank-god-not-
everything-is-software.html. CC BY 3.0. Last visited: 2021-02-18

CC BY 2.0 license, see https://creativecommons.org/licenses/by/2.0/

CC BY 3.0 license, see https://creativecommons.org/licenses/by/3.0/
CC BY 4.0 license, see https://creativecommons.org/licenses/by/4.0/

Literature Sources
‣ [arc42] arc42 - Template for Software Architecture Documentation. Open-Source, published on https://arc42.org. Created by Peter Hruschka
and Gernot Starke.

iSAQB CPSA-F – 9. Software Architecture Evaluation 384