Architektur November 2026 · 5 Min. Lesezeit

Von der Erfahrung zur Methode: was mir der iSAQB Foundation Level für meine Architekturarbeit gebracht hat

Warum ich nach über zehn Jahren Entwicklung von Engineering-Software den iSAQB CPSA Foundation Level abgelegt habe, wie die Prüfung abläuft, wie ich mich im Selbststudium vorbereitet habe und welche Ideen daraus ich am häufigsten nutze.

Sunkuru Jagabandhu Patro · Softwareentwickler & -architekt

Den größten Teil meiner Laufbahn habe ich Softwarearchitekturen entworfen, ohne es so zu nennen. Geschichtete CAN/UDS-Stacks bei Hyundai Mobis, eine Multi-Brand-Diagnoseplattform bei Continental, Messdatenplattformen bei Valeo: Jedes System brauchte Struktur, Schnittstellen und Abwägungen. Im Juli 2025 habe ich die iSAQB-Zertifizierung Certified Professional for Software Architecture – Foundation Level (CPSA-F) bestanden, vorbereitet vollständig im Selbststudium. Dieser Artikel erklärt, warum, wie die Prüfung abläuft, wie ich mich vorbereitet habe und was ich mitgenommen habe.

Warum eine Zertifizierung nach Jahren der Praxis?

• Ein gemeinsames Vokabular. Wenn ich einen Entwurf mit Architekten anderer Teams oder Unternehmen bespreche, ersparen Begriffe wie Qualitätsziele, Bausteine oder Querschnittskonzepte lange Erklärungen.
• Methode statt Bauchgefühl. Aus Erfahrung wusste ich, welche Entwürfe gut altern. Der Lehrplan erklärt, warum, und bietet einen wiederholbaren Weg dorthin.
• Eine Grundlage für KI-Architektur. CPSA-F ist der Einstieg in den iSAQB Advanced Level. Im Juli 2026 kam das Modul SWARC4AI (Softwarearchitektur für KI) hinzu.

Was der Foundation Level abdeckt

Der iSAQB-Lehrplan ist hersteller- und technologieneutral. Kurz zusammengefasst:

• Die Rolle der Architektin oder des Architekten: was Architektur ist und welche Aufgaben über den gesamten Lebenszyklus anfallen.
• Anforderungen und Randbedingungen: vor allem Qualitätsanforderungen wie Wartbarkeit, Performance oder Zuverlässigkeit, die die Struktur weit stärker prägen als einzelne Funktionen.
• Entwurf: Zerlegung in Bausteine, Kopplung und Kohäsion, Architektur- und Entwurfsmuster sowie Querschnittskonzepte wie Fehlerbehandlung oder Logging.
• Kommunikation und Dokumentation: Sichten (Kontext, Bausteine, Laufzeit, Verteilung) und Vorlagen wie arc42, damit andere die Arbeit verstehen und fortführen können.
• Bewertung: die Prüfung einer Architektur gegen ihre Qualitätsziele, zum Beispiel mit konkreten Qualitätsszenarien.

Die Prüfung

Der iSAQB legt Lehrplan und Regeln fest; die Prüfungen führen unabhängige Zertifizierungsstellen durch. Ich habe meine bei Certible abgelegt.

• Format: etwa 40 Multiple-Choice-Fragen mit je 1 oder 2 Punkten, je nach Schwierigkeit.
• Zeit: höchstens 75 Minuten, oder 90 Minuten, wenn die Prüfung nicht in der eigenen Muttersprache abgelegt wird.
• Fragetypen: Single Choice (eine richtige Antwort), Pick-from-many (eine vorgegebene Anzahl von Antworten wählen) und Zuordnung (jede Aussage einer von zwei Kategorien zuordnen, etwa „trifft zu“ oder „trifft nicht zu“).
• Bewertung: Falsche Antworten können Punkte kosten, aber nur innerhalb derselben Frage und nie unter null für diese Frage.
• Bestehen: mindestens 60 % der Gesamtpunkte. Hilfsmittel sind nicht erlaubt, und die Prüfung kann ohne Wartezeit wiederholt werden.

Wie ich mich vorbereitet habe: Selbststudium

Eine akkreditierte Schulung ist möglich, aber keine Voraussetzung. Ich habe mich selbst vorbereitet, mit den kostenlosen offiziellen Unterlagen des iSAQB:

• Der Lehrplan: alle Lernziele und Begriffe, Kapitel für Kapitel. Er legt genau fest, was in der Prüfung gefragt werden kann.
• Das Glossar: präzise Definitionen der Begriffe aus dem Lehrplan. Viele Fragen hängen genau an diesen Bedeutungen.
• Die Probeprüfung mit Lösungen: 38 Fragen im Stil der echten Prüfung; der beste Weg, sich an die Fragetypen und ihre Bewertung zu gewöhnen.
• Die Prüfungsregeln: Dauer, Fragetypen und Bewertung, erklärt an Beispielen.

Mein Tipp für das Selbststudium: den Lehrplan mit den eigenen Projekten im Kopf lesen. Jedes Lernziel bleibt leichter hängen, wenn man ein System nennen kann, in dem man es angewendet hat, oder in dem man es sich gewünscht hätte.

Vier Ideen, die ich am häufigsten nutze

1. Qualitätsziele bestimmen die Struktur. Die Modernisierung des CRETA-Export-Workflows bei Valeo ist ein gutes Beispiel. Die wichtigsten Ziele waren Änderbarkeit (mehrere Kunden mit jeweils eigener Variante) und Robustheit (große Dateien, Netzwerkspeicher). Daraus ergab sich direkt die Struktur: ein Modul pro Kundenvariante hinter kleinen Schnittstellen, ein Anti-Corruption Layer um die Legacy-API und Wiederholungen mit exponentiellem Backoff bei vorübergehenden Fehlern.

2. Grenzen und Abhängigkeiten explizit machen. Lose Kopplung und hohe Kohäsion klingen abstrakt, entscheiden aber, wie teuer die nächste Änderung wird. In der Measurement Class Library gelangt jedes Datenformat (MDF/MF4, Parquet, MAT) über dieselbe Schnittstelle hinein, sodass der Analysecode nie von einem bestimmten Dateiformat abhängt. Ein neues Format bedeutet einen neuen Adapter, keine Änderung an den Analysen.

3. Dieselben Prinzipien in sehr unterschiedlichen Systemen. Ich habe die Architektur sehr unterschiedlicher Software entworfen, in mehreren Sprachen:

• Windows-Desktopanwendungen: C#/.NET mit WPF/MVVM für Werkzeuge rund um Diagnosedaten und C++/Qt für einen touch-optimierten Werkstatttester.
• Kalibrier- und Monitoring-Tools: ein geschichteter CAN/UDS-Kommunikationsstack mit einem C#-Tool für Kalibrierung, Monitoring, Diagnose und ECU-Flashing.
• ETL- und Datenpipelines: Python-Pipelines, die Rohdatenexporte in Prognosen verwandeln, und MATLAB-Workflows, die auf einem HPC-Cluster laufen.
• Bibliotheken und Frameworks: eine objektorientierte MATLAB-Klassenbibliothek, die alle Messdatenformate vereinheitlicht, und ein VBA-Reporting-Framework.

Sprachen und Plattformen ändern sich, die Prinzipien nicht. Schichten mit klaren Verantwortlichkeiten, kleine Schnittstellen, Muster wie Factory, Adapter oder Facade und Tests, die Änderungen sicher machen, gelten in C#, C++, Python und MATLAB gleichermaßen. Die technologieneutrale Sicht des Lehrplans passt genau zu dieser Erfahrung.

4. Generieren, was sich aus Modellen generieren lässt. Wo es ein Modell gibt, generiere ich Code lieber daraus, statt ihn von Hand zu schreiben. Bei Hyundai Mobis habe ich den Stack aus Kundenanforderungen in UML entworfen; bei Continental wurden Diagnosesequenzen aus ODX- und OTX-Modellen generiert; bei Valeo habe ich mit Kiota aus der OpenAPI-Beschreibung der CRETA-API einen typisierten C#-Client generiert. Generierter Code bleibt konsistent mit seiner Quelle und beseitigt so eine ganze Klasse von Integrationsfehlern.

Was ein Zertifikat nicht leistet

Der Foundation Level vermittelt Methoden, keine fertigen Antworten. Er ersetzt nicht die Erfahrung mit echten Randbedingungen: Legacy-Systeme, Termine, Hardware und Teams. Sein Wert liegt für mich in der Verbindung beider Seiten: Meine Projekte liefern den Kontext, der Lehrplan die Methode und das Vokabular, um einen Entwurf zu erklären und zu begründen.

Fazit

• Qualitätsziele zuerst: Sie prägen die Architektur stärker als jede Funktionsliste.
• Explizite Grenzen: Schnittstellen und Adapter halten Änderungen lokal, in jeder Sprache.
• Selbststudium funktioniert: Mit offiziellem Lehrplan, Glossar und Probeprüfung ist eine Schulung optional.

Quellen

• Lehrplan Foundation Level (PDF, Englisch)
• Glossar der Softwarearchitektur-Begriffe (PDF, Englisch)
• Probeprüfung (PDF, Englisch)
• Lösungen der Probeprüfung (PDF, Englisch)
• Prüfungsregeln mit Beispielen (PDF, Englisch)
• Downloads zum Foundation Level (iSAQB, auch auf Deutsch)
• Certible: Prüfung iSAQB CPSA-F

Mein Zertifikat und die Credential-ID finden Sie unter Zertifizierungen.