iSAQB Foundation Level Curriculum
Education based upon the Certified Professional for Software Architecture – Foundation Level (CPSA-F) shall provide participants with the knowledge and skills required to design, specify and document software architectures adequate to fulfil the respective requirements for small and medium-sized systems.
As stated above, Foundation Level covers small to medium-sized software systems.
Based upon their individual practical experience and existing skills, participants will learn to derive architectural decisions from an existing system vision and adequately detailed requirements. CPSA-F trainings teach methods, principles and patterns for design, communication, documentation and evaluation of software architectures, independent of specific development processes. The CPSA-F curriculum is technology-neutral, therefore applicable to a borad range or
Focus is education and training of the following skills:
-
Discuss and reconcile fundamental architectural decisions with stakeholders from requirements, management, development, operations and test,
-
understand the essential activities of software architecture, and carry out those for small- to medium sized systems,
-
document and communicate software architectures based upon architectural views, architecture patterns and technical concepts
In addition, such trainings cover
-
the tasks and responsibilities of software architect
-
the term software architecture and its meaning
-
the roles of software architects within development
-
state-of-the-art methods and techniques for developing software architectures
|
|
This is copyrighted work. |
A curriculum, in contrast to a syllabus, is oriented towards teaching objectives and the course of the teaching and learning process. In addition to the teaching content, the urriculum should include regulations and options for learning processes and the organization of learning.
Freely translated from the German Wikipedia,
The following requirements should be fulfilled by every learning goal, especially for all R1-goals:
- Specific and Clear
-
Each learning goal should be clear and specific, avoiding vagueness. This means stating what the learner will know or be able to do in precise terms. For software architects, this could involve specifying particular architectural styles, patterns, methods and practices they will need to learn and apply.
- Relevant
-
Learning goals should be directly relevant to the roles and responsibilities of software architects. This means they should focus on skills and knowledge that are directly applicable to designing, evaluating, and managing software architecture. Relevance also includes ensuring that the goals are aligned with current industry standards, technologies, and practices to prepare learners for real-world challenges.
- Authoritative
-
Learning goals should be based on established content industry best practices, and proven research. This ensures that the curriculum is aligned with recognized standards and that students are learning concepts that are widely accepted and validated in the field of software architecture. Where possible and adequate, authorative sources shall be referenced.
- Measurable
-
Goals must be measurable so that both the learner and the educator can assess progress. This involves defining criteria for success, which can be quantified or qualified. For instance, a learning goal might include being able to design a complete software architecture that meets defined performance metrics or adhering to specific architectural principles.
- Achievable
-
While learning goals should be challenging, they must also be attainable within the scope of the course or program. This requires considering the learners' current skill levels and the resources available to support their learning. Goals that are too ambitious may discourage learners, while those that are too easy may not lead to significant learning or skill development.
All important terms from the curriculum shall be defined in the (freely available) glossary.
Where useful, the curriculum shall contain hyperlinks from these terms to the online version of this glossary.
Maintenance of this content shall be open and transparent, done on a public platform (like GitHub):
- Open
-
We encourage contributions from a broad community. This can include reporting issues or change-requests, submitting changes, or suggesting new content.
- Transparent
-
The processes, decisions, and discussions surrounding the development of this curriculum are open for public viewing. These transparen practices ensure that contributors and maintainers are accountable for their actions. Readers, consumers and contributors can see who made specific changes, when they were made, and why.
Together, openness and transparency shall ensure that the development of this curriculum is inclusive, collaborative, and accountable. That shall lead to a trust and acceptance of the whole content.
This curriculum is maintained in both English and German.
Additional translations are available, which are usually done by professional translators in the respective countries. Most of these translations are organized and managed by the iSAQB GmbH.
Results of these translations are stored under /docs-ext in this repository.
`
=== Repository Organization
This section provides an overview of the repository structure, detailing the contents and purpose of each directory and file.
-
build.gradle: The build configuration file for Gradle projects. -
CHANGELOG.md: Changelog for the most current version of the curriculum (currently: V.2025). Older changelogs underdocumentation/changelogs -
document.validity: Contains the date from which the current version of the curriculum is valid. Accredited trainings have to comply to this version from the date given here. -
gradle.properties: JVM args for the gradle build. Do NOT change, unless you are sure what you are doing. -
LICENSE: The licensing information for the project. -
README.adoc: This main documentation file, providing an introduction and overview of the project.
This folder contains the learning goals and everything else needed to build (generate) the final curriculum.
Contains translations of the curriculum, into e.g. Spanish (ES), Italian (IT) and Portugese (PT).
Please be advised that intensive quality assurance by the FLWG and other reviewers is only performed on the English and German versions.
-
/changelogs: (old) changelogs. The most current changelog isCHANGELOG.mdunder/ -
/decisions: contains our decision-log (started only September-2024, so not complete)
-
/release-process: the documentation of our release process, plus a graphical version.
A git submodule, containing theme the style/layout definitions for rendering the curriculum in html format.
A git submodule, containing theme the style/layout definitions for rendering the curriculum in pdf format.
Contains a small Groovy application to collect all learning goals (LGs) and prepare an asciidoc table of these LGs.
The FLWG (Foundation Level Working Group) consists of volunteer members of iSAQB who take up the responsibility of maintaining the curriculum plus the corresponding examination (including questions, question-formats and examination rules).
Currently the FLWG consists of >10 maintainers from industry and academia, with a background from many kinds of software systems.
This repository contains the curriculum for CPSA-F in the following versions:
-
(upcoming) version 2025 (will become mandatory from April 1st 2025)
-
Version 2023 (mandatory from April 1st 2023)
-
Version 2021.1 (mandatory from April 1st 2021)
-
Version 5 (mandatory from September 1st 2019 until March 31st 2021)
We follow a standardized update and release process for the curriculum and the associated examination questions.
Please note the semantics of several terms:
- Version-Identifier
-
Official versions of the curriculum are identified using a specific version-string.
V-{Release-Year}-{Update}-{Language}-{timestamp}, for example V-2023.1-EN. In preparation for releases (see below), release-candidates are produced and labelled with RC1, RC2 etc. - Revision
-
In case of typos or other minor grammatical changes, we will release revisions (aka patches) without increasing the minor version. They will be tagged as revisions (e.g.
2021.1-rev2) on GitHub and receive a new timestamp, resulting in a version in a document that looks like this:2021.1-EN-20210502(revision update on Mai 2, 2021). We strive to keep learning content and structure stable across such updates, meaning that no training provider needs to adjust training material in case of revision updates. - Update
-
In case of errors or omissions (e.g. translation issues, required updates for certain references, clarification of certain wordings or similar), an updated (aka fixed or repaired) version of the curriculum is produced. For such updates we increase the second part (minor version id) of the curriculum (e.g. going from
2021.1to2021.2). - Release
-
Every two years the FLWG releases a new version of the curriculum. Releases usually contain major changes to the content of the curriculum. For example, learning goals might be re-formulated, deleted or new content might be added.
>### How to create a new release/version > > You find a [detailed explanation here](https://github.com/isaqb-org/github-readme?tab=readme-ov-file#how-to-create-a-new-release-of-a-curriculum)
|
❗
|
Releases impact training material
Releases will impact structure and content of training material. Therefore, training providers, translation agencies and the examination commission will be notified about these releases, so they can adjust their trainings, translations or the exam questions, respectively. |
If you build the curriculum locally, the version string will be set to local build.
Nr |
Activity |
Duration |
Schedule/deadline |
1 |
Collect change requests |
continuously |
for 2025, CRs are accepted until June 15th 2024 |
2 |
We hope to get (anonymous) statistical evaluation of examinations and examination questions from certification providers. |
continuously |
none |
3 |
FLWG maintains the curriculum and associated information within this public Github repository |
||
4 |
FLWG decides internally, which changes to accept for the upcoming release. |
RD - 9M, July 1st 2024 |
|
5 |
The list of accepted changes is given to all training providers (TP) for review and request-for-comments. From that time, TP can begin to update their training material. Several accepted changes are already included in main-branch. |
RD - 9M, July 1st 2024 |
|
6 |
FLWG incorporates the accepted changes in main-branch in the Github repo. Contributors from FLWG create understandable commit messages to strive for maximum transparency. All issues with "accepted" state shall be included until this date. |
8 weeks |
RD - 7M, Sept 1st 2024 |
7 |
When all changes are included and finalized, a new version of the curriculum is generated (in both EN and DE language) - but not yet made mandatory! All training providers and trainers shall be notified of this update. This new version is published as draft on the isaqb-org.github.io website. |
4 weeks |
RD - 6M, Oct 1st 2024 |
4, 6 & 7 |
Minor corrections, hotfixes |
continuously |
|
8 |
FLWG determines which exam questions are affected by the changes in curriculum and updates the exam questions accordingly. Changes to questions are reviewed internally. This will need at least three Independent reviewers |
8 weeks |
|
9 |
Finalized questions are transformed into pdf/xml and/or other formats, appropriately labelled and securely transmitted to both EP and iSAQB GmbH (to allow translation to languages other than DE and EN) EP need to incorporate this updated version into their examination process and/or toolset until the release date RD. |
RD - 3M, Jan 15th 2025 |
|
10 |
iSAQB GmbH contracts translation of curriculum and questions to translation office (which is under strict nondisclosure agreements) |
4 weeks |
|
11 |
For every target language there need to be an expert group who can handle review of translation |
4-6 weeks |
|
12 |
EN + DE release of curriculum and examination question: Usage of new version is mandatory in all trainings given in DE or EN.
|
RD, April 1st 2025 |
|
13 |
International release of curriculum and examination questions. Usage of new version is mandatory in all trainings given in any language. |
RD + max 12 weeks |
-
RD: Release-Date (next: April 1st 2025)
-
EP: Examination Provider
-
Announcements: major versions (2019.x, 2021.x) are announced to training providers at least 3-4 month in advance—usually at the iSAQB members meeting.
-
RC1: About 4-6 month prior to release, training providers receive the first release candidate (RC1) for review and comments.
-
RC2: 6-8 weeks prior to release they receive the final release candidate RC2, which is feature frozen (meaning neither learning goals nor priorities will substantially change, only bugs and typos will be fixed).
-
Final version (e.g. 2021.1) will be made public on iSAQB.org and iSAQB.com
-
Released versions will be tagged in git.
All languages (e.g. DE and EN) will be released at the same time.
You found a bug in one of the published versions, have remarks, comments or proposals? Ideas for improvement?
We use Github issues to collect and discuss such proposals.
-
Please search the existing (open and closed) issues, before creating a new one. Maybe your topic has already been discussed.
-
If you don’t find anything: Open an issue here. A member of the working-group will contact you!
The iSAQB members association regularly elects the Foundation Level Working Group (FLWG). The FLWG is responsible for maintaining the CPSA-F Curriculum and corresponding examination questions. Major version updates are reviewed and discussed with the board and the members association prior to publication.
The current (2024/2025) FLWG members are:
-
Dr. Ulrich Becker
-
Mahbouba Gharbi
-
Dr. Peter Hruschka
-
Dr. Alexander Lorz
-
Falk Sippach
-
Bert Jan Schrijver
-
Dr. Michael Sperber
-
Dr. Gernot Starke (FLWG chair)
-
Roger Rhoades
-
Prof. Dr. Stefan Wehr
-
(Benjamin Wolf)
Work on this curriculum started way back in 2007/2008 - and numerous people contributed - either by proposing, crafting and writing content.
(alphabetical order, current FLWG members excluded)
Wolfgang Fahl, Philip Ghadir, Prof. Dieter Jungmann, Prof. Arne Koschel, Prof. Andreas Rausch, Mischa Soujon, Bettina Tacke, Holger Tiemeyer
In case we forgot your name here, please let us know!
|
❗
|
Copyrighted work
We would like to emphasise, as a matter of principle, that this curriculum is protected by copyright. |
The International Software Architecture Qualification Board e. V. (iSAQB® e. V.) has exclusive entitlement to these copyrights.
See the license and copyright for details.
Prerequisite: You need an up-to-date Java Runtime(tm) installed. Ubuntu’s default Java 11 is not sufficient, Java 21 works.
You build the output documents with gradle. That will produce both pdf and html output in German (DE) and English (EN), unless you modify the configuration. Make sure to use the Gradle Wrapper in this repository to prevent potential build errors.
./gradlew buildDocs
In case you want to change the configuration, adjust the following part of build.gradle:
task buildDocs {
group 'Documentation'
description 'Grouping task for generating all languages in several formats'
dependsOn "renderDE", "renderEN"
}In the "renderDE" certain attributes (aka variables) are defined that configure the corresponding output.
Please note: You need to include the submodules "pdf-theme" and "html-theme" in your checkout, otherwise the build will fail. You can do that with the following commands:
-
Clone the repository - including the submodule:
Via SSH: git clone git@github.com:isaqb-org/curriculum-foundation.git --recursive Via HTTPS: git clone https://github.com/isaqb-org/curriculum-foundation.git --recursive
-
Initialize and update submodules with
git submodule initandgit submodule update --recursive --remote.
If you consider the status of the curriculum worthy of a new release or release candidate, you have to create a tag with Git.
The format for a release candidate tag is as follows:
2021.1-RCX, where x is either 1 or the current release candidate number increased by one.
This tag will create a GitHub pre-release. They are [available here](https://github.com/isaqb-org/curriculum-foundation/releases) and provide you with a zip archive that contains the curriculum as PDF and HTML.
The format for a release tag is as follows:
2021.1-revX where x is either 0 (initial release), or the current revision increased by one.
This tag will create a GitHub Release. They are [available here](https://github.com/isaqb-org/curriculum-foundation/releases) and provide you with a zip archive that contains the curriculum as PDF and HTML.
In addition, the released curriculum will be published on GitHub Pages.
The particular language as well as the timestamp will be added automatically.
Example for a full version in the English curriculum PDF: 2021.1-EN-20210401
In #246 we decided to use title case for all headings:
-
capitalize: first and last word, nouns, pronouns, adjectives, verbs
-
lowercase: articles and prepositions
When in doubt, opt for Chicago Style.
To unify upper/lowercase within the (EN) version, we use the Chicago manual of style proposal":
-
short bullet items don’t get a full-stop
-
next one starts lowercase
-
if bullets are phrases or fragments, dont use punctuation
-
if and only if an item is a really long sentence which deserves a full stop, or consists of several sentences, then we use it.
-
Only then does an item start with uppercase.
For the German (DE) version, we don’t use punctuation at the end of bullet-list items, unless on ends-of-sentences.
We strive to base all content on established content by providing references to original sources.
In practice, this means that we reference the original source of a learning goal, if it is based on a book, a paper, a standard or similar. We use a distinct section for every learning goal:
===== {references}
<<starkelorz>>Example (abbreviated)
[[LG-01-01]]
==== LG 01-01: Discuss Definitions of Software Architecture (R1)
Software architects know the commonalities of many definitions of software architecture:
* ...
* ...
===== {references}
<<iso42010>>, <<bass>>, <<kruchten>>, <<starkelorz>>