What CPSA®-Advanced Level Exam Tasks Actually Look Like
This blog post answers the most important questions about the written part of the iSAQB Advanced Level exam.
The iSAQB entry level of the Certified Professional for Software Architecture certification, the Foundation Level (CPSA‑F), includes a multiple-choice test as an examination. At the second level, the Advanced Level (shortened: CPSA‑A), the examinee works on a paper. He (or she) then defends his (or her) solution in an interview with two examiners who reviewed and held it against criteria beforehand.
In a multiple-choice test (i. e., at CPSA‑F), it is relatively clear what is in store for the examinee. Even if individual learning objectives are difficult to check with checkbox questions, and one may not be able to actually imagine specific questions about them, this at least applies to the form of the examination. But regarding the Advanced Level, I keep hearing the same question in workshops or by email: What does such an examination task look like in terms of content? This is not so obvious immediately.
The actual exam tasks are of course confidential (just like the exam questions at Foundation Level). Therefore, I will describe below how tasks are structured – for people who will soon have to solve such a task. So, here is what you can roughly expect as an Advanced examinee…
⇒ What does a task basically look like?
⇒ The case study
⇒ Your task
⇒ An example
⇒ Frequently asked questions about exam tasks
⇒ Further information
What does a task basically look like?
The CPSA-Advanced Level examination task consists of at least 10 pages and of 25 at the most (see figure below, the page numbers are sample numbers).
Each task is assigned to a system type. These are currently:
- Information system
- Embedded system
- Web system
A candidate states the desired system type when registering for the exam and is then given a task from this field. This is to prevent an examinee from being confronted with an environment that is completely foreign to them. If requested, the examinee receives short abstracts (2–3 sentences) of two different tasks and then chooses one of them.
Each task then splits into two rough blocks: A case study in the form of content-related inputs, and the task itself. The latter is divided into subtasks. The actual examination tasks vary considerably in the combination of content-related inputs and subtasks.
The case study
The case study is a fictitious project, a product development, a migration, or the like. After a brief overview, specific information to it in the form of content-related inputs is provided. Essentially, these are requirements that the examinee must consider for subsequent subtasks. Conceivable are the following contents:
- Functional requirements (e. g., important use cases, user stories, …)
- Quality goals, refined in scenarios if need be
- Stakeholders (e. g., list, personas)
- Interviews with stakeholders
- Technical and/or organizational constraints
- Business context, users, and external systems
- Standards and conventions
Not every task includes all of these contents. Furthermore, it may be that certain requirements are explicitly stated, but others must be worked out as part of the task. Interviews with stakeholders, for example, are sometimes available, and then the examinee must work out and, if necessary, prioritize the constraints or quality objectives as part of a subtask.
Much like the case study with its content-related inputs, the task is also subdivided – into a minimum of 5 and a maximum of 10 subtasks that cover different aspects of the architectural work. Overall, the processing is supposed to show that the examinee is able to methodically design and record an architecture from requirements, to reflect on it, and to communicate it. By analogy with the conceivable inputs above regarding the case study, here are some possible subtasks:
- Refining the system context
- Identifying quality goals, developing utility tree and scenarios
- Framing open questions to stakeholders
- Preparing solution strategy/architectural vision
- Making architectural decisions
- Elaborating a technical question incl. alternatives and rationale
- Structuring the system, technically analyzing it, defining responsibilities
- Designing interfaces
- Processing technical and/or cross-cutting aspects
- Qualitatively evaluating the solution
- Identifying and addressing risks
Content-related inputs and subtasks overlap: The system context could be given with the case study (as content-related input) or must be worked out instead as a subtask.
The iSAQB provides the sample task “BigSpender”. This is a real task that used to be set, but has been removed from the pool in the meantime after some examinees had been able to work on it. You can download the exam task as a PDF here.
This task deals with expense claims. The case study contains the following contents:
- Input 1 – Overview (1 page, text)
- Input 2 – Business context (diagram and short description of the actors)
- Input 3 – Class model (diagram) and glossary (as table)
- Input 4 – Stakeholders (scarce list)
- Input 5 – Interview with the client (quite extensive, approx. 3 pages)
- Input 6 – Exemplary user stories (10)
- Input 7 – Availability of the system (requirement, as scenario)
- Input 8 – Technical constraints (as short text)
- Input 9 – Quantity structure (table, statements about users, locations, operations, …)
The actual task consists of 6 parts:
- Subtask 1 – Working out quality requirements, in the form of quality goals and scenarios
- Subtask 2 – Developing solution strategy, length approx. one page
- Subtask 3 – Clarifying the technical context, diagram and description of actors and communication
- Subtask 4 – Developing a business structure (building block view)
- Subtask 5 – Making technology decisions
- Subtask 6 – Evaluating the solution, using the quality scenarios from subtask 1
See the PDF for details. And please note that, as described, the exam tasks vary greatly and “BigSpender” is an example – albeit a real one.
Frequently asked questions about exam tasks
How can be made sure that the task fits the training courses I attended?
Actually, not at all. The specification of the system type (e. g., web, embedded) merely ensures that it roughly fits technologically. Other than that, the tasks are not tied to specific modules. The subtasks (+ interview) only cover the three competence areas (“pillars”) of the Advanced Level (methodical, technological, and communicative).
What is the extent of my solution?
You record your solution on a maximum of 40 DIN A4 pages (including illustrations). You have three months at the most to finish it (for details, see examination rules). In terms of effort, the subtasks are planned to enable an examinee to complete them within 40 hours.
What if technologies or methods are required that I don’t master?
The tasks give you reasonable leeway regarding technologies, tools, notation, and the like. If something is explicitly required, it is ensured that information on it is freely accessible. It is either included already in the content-related inputs or in an appendix, or it is being referred to. Of course, it may happen that you still have to acquire knowledge to solve the task.
What if the given requirements are not enough for me to solve the task?
As in real life, you may lack information to solve the task. In individual cases, requirements may even seem to contradict each other (for example, statements made in interviews by stakeholders with different priorities). You usually clarify that during the project with the people involved, find compromises, etc. Since people are not available to you as part of your paper, you make assumptions. You explicitly mark these as such in your solution. Make sure that they make sense and are consistent with each other and with the task.
Should I structure my solution according to arc42?
The answer to this question is definitely no. arc42 is a common outline suggestion for architecture descriptions, so the idea seems natural. For your solution, however, the precept is clearly that you structure it according to the subtasks. That means one section per subtask. This way, you enable the examiners to easily review the solution and compare it with criteria.
I hope I was able to give you an impression of what the exam tasks at CPSA-Advanced Level basically look like. If you have any questions about this topic, please feel free to contact me. Otherwise, you will find a lot of information about the Advanced Level here on the iSAQB website.