Architecture November 2026 · 5 min read

From experience to method: what the iSAQB Foundation Level added to my architecture work

Why I took the iSAQB CPSA Foundation Level after more than ten years of designing engineering software, how the exam works, how I prepared by self-study, and the ideas from it I use most.

Sunkuru Jagabandhu Patro · Software Engineer & Architect

For most of my career I designed software architecture without calling it that. Layered CAN/UDS stacks at Hyundai Mobis, a multi-brand diagnostic platform at Continental, measurement-data platforms at Valeo: each needed structure, interfaces and trade-offs. In July 2025 I passed the iSAQB Certified Professional for Software Architecture – Foundation Level (CPSA-F), preparing entirely by self-study. This article explains why, how the exam works, how I prepared, and what I took from it.

Why a certification after years of practice?

A shared vocabulary. When I discuss a design with architects from other teams or companies, terms like quality goals, building blocks or cross-cutting concepts save long explanations.
Method instead of instinct. I knew from experience which designs aged well. The curriculum explains why, and gives a repeatable way to get there.
A foundation for AI architecture. CPSA-F is the entry point to the iSAQB Advanced Level. In July 2026 I added the module SWARC4AI (Software Architecture for AI).

What the Foundation Level covers

The iSAQB curriculum is vendor- and technology-neutral. In short:

The architect's role: what architecture is, and the architect's tasks across the whole lifecycle.
Requirements and constraints: especially quality requirements such as maintainability, performance or reliability, which shape the structure far more than features do.
Design: decomposition into building blocks, coupling and cohesion, architectural and design patterns, and cross-cutting concepts such as error handling or logging.
Communication and documentation: views (context, building blocks, runtime, deployment) and templates such as arc42, so others can understand and continue the work.
Evaluation: checking an architecture against its quality goals, for example with concrete quality scenarios.

The exam

iSAQB defines the curriculum and the rules; independent certification bodies run the exams. I took mine with Certible.

Format: about 40 multiple-choice questions, each worth 1 or 2 points depending on difficulty.
Time: at most 75 minutes, or 90 minutes if you take it in a language that isn't your native one.
Question types: single choice (one correct answer), pick-from-many (choose a given number of answers) and allocation (assign each statement to one of two categories, such as "applies" or "doesn't apply").
Scoring: wrong answers can cost points, but only within the same question, never below zero for that question.
Passing: at least 60% of the total points. No aids are allowed, and the exam can be retaken without a waiting period.

How I prepared: self-study

An accredited training course is an option, but not a requirement. I prepared on my own, with the free official iSAQB material:

The curriculum: every learning goal and term, chapter by chapter. It defines exactly what the exam can ask.
The glossary: precise definitions of the terms the curriculum uses. Many questions depend on these exact meanings.
The mock exam and its solutions: 38 questions in the style of the real exam, which is the best way to get used to the question types and their scoring.
The examination rules: duration, question types and scoring, explained with examples.

My advice for self-study: read the curriculum with your own projects in mind. Every learning goal becomes easier to remember once you can name a system where you applied it, or where you wish you had.

Four ideas I use most

1. Quality goals decide the structure. The modernization of the CRETA export workflow at Valeo is a good example. The main goals were changeability (several customers, each with its own variant) and robustness (large files, network storage). They led directly to the structure: one module per customer variant behind small interfaces, an Anti-Corruption Layer around the legacy API, and retries with exponential backoff for transient failures.

2. Make boundaries and dependencies explicit. Low coupling and high cohesion sound abstract, but they decide how expensive the next change is. In the Measurement Class Library, every data format (MDF/MF4, Parquet, MAT) enters through the same interface, so analysis code never depends on a specific file format. Adding a format means adding an adapter, not changing the analyses.

3. The same principles across very different systems. I have designed the architecture of very different kinds of software, in several languages:

Windows desktop applications: C#/.NET with WPF/MVVM for diagnostic data tooling, and C++/Qt for a touch-optimized workshop tester.
Calibration and monitoring tools: a layered CAN/UDS communication stack with a C# tool for calibration, monitoring, diagnosis and ECU flashing.
ETL and data pipelines: Python pipelines that turn raw exports into forecasts, and MATLAB workflows that run on an HPC cluster.
Libraries and frameworks: an object-oriented MATLAB class library that unifies all measurement formats, and a VBA reporting framework.

The languages and platforms change; the principles don't. Layers with clear responsibilities, small interfaces, patterns such as Factory, Adapter or Facade, and tests that make change safe apply in C#, C++, Python and MATLAB alike. The curriculum's technology-neutral view matches this experience.

4. Generate what you can from models. Wherever a model exists, I prefer to generate code from it rather than write it by hand. At Hyundai Mobis I designed the stack in UML from customer requirements; at Continental diagnostic sequences were generated from ODX and OTX models; at Valeo I generated a typed C# client from the OpenAPI description of the CRETA API with Kiota. Generated code stays consistent with its source, which removes a whole class of integration errors.

What a certificate doesn't do

The Foundation Level teaches methods, not answers. It doesn't replace experience with real constraints: legacy systems, deadlines, hardware and teams. For me its value is in connecting both: my projects provide the context, and the curriculum provides the method and the vocabulary to explain and defend a design.

Takeaways

Quality goals first: they shape the architecture more than any feature list.
Explicit boundaries: interfaces and adapters keep change local, in any language.
Self-study works: with the official curriculum, glossary and mock exam, a training course is optional.

References

My certificate and its credential ID are listed under Certifications.