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 Profes­sional for Software Architecture certification, the Foundation Level (CPSA‑F), includes a multiple-choice test as an exami­nation. 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 exami­nation. But regarding the Advanced Level, I keep hearing the same question in workshops or by email: What does such an exami­nation task look like in terms of content? This is not so obvious immediately.

The actual exam tasks are of course confi­dential (just like the exam questions at Foundation Level). Therefore, I will describe below how tasks are struc­tured – 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 exami­nation 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 regis­tering 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 exami­nation tasks vary consid­erably in the combi­nation of content-related inputs and subtasks.

The case study

The case study is a ficti­tious project, a product devel­opment, a migration, or the like. After a brief overview, specific information to it in the form of content-related inputs is provided. Essen­tially, these are requirements that the examinee must consider for subse­quent subtasks. Conceivable are the following contents:

• Functional requirements (e. g., important use cases, user stories, …)
• Quality goals, refined in scenarios if need be
• Stake­holders (e. g., list, personas)
• Inter­views with stakeholders
• Technical and/or organi­za­tional constraints
• Business context, users, and external systems
• Standards and conventions
• Risks

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. Inter­views with stake­holders, for example, are sometimes available, and then the examinee must work out and, if necessary, prior­itize the constraints or quality objectives as part of a subtask.

Your task

Much like the case study with its content-related inputs, the task is also subdi­vided – 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 method­i­cally design and record an architecture from requirements, to reflect on it, and to commu­nicate it. By analogy with the conceivable inputs above regarding the case study, here are some possible subtasks:

• Refining the system context
• Identi­fying quality goals, devel­oping utility tree and scenarios
• Framing open questions to stakeholders
• Preparing solution strategy/architectural vision
• Making architectural decisions
• Elabo­rating a technical question incl. alter­na­tives and rationale
• Struc­turing the system, techni­cally analyzing it, defining responsibilities
• Designing inter­faces
• Processing technical and/or cross-cutting aspects
• Quali­ta­tively evalu­ating the solution
• Identi­fying 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.

An example

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 – Stake­holders (scarce list)
• Input 5 – Interview with the client (quite extensive, approx. 3 pages)
• Input 6 – Exemplary user stories (10)
• Input 7 – Avail­ability of the system (requirement, as scenario)
• Input 8 – Technical constraints (as short text)
• Input 9 – Quantity structure (table, state­ments 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 – Devel­oping solution strategy, length approx. one page
• Subtask 3 – Clari­fying the technical context, diagram and description of actors and communication
• Subtask 4 – Devel­oping a business structure (building block view)
• Subtask 5 – Making technology decisions
• Subtask 6 – Evalu­ating 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 speci­fi­cation of the system type (e. g., web, embedded) merely ensures that it roughly fits techno­log­i­cally. Other than that, the tasks are not tied to specific modules. The subtasks (+ interview) only cover the three compe­tence areas (“pillars”) of the Advanced Level (methodical, techno­logical, and communicative).

What is the extent of my solution?

You record your solution on a maximum of 40 DIN A4 pages (including illus­tra­tions). You have three months at the most to finish it (for details, see exami­nation 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 acces­sible. 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, state­ments made in inter­views by stake­holders with different prior­ities). You usually clarify that during the project with the people involved, find compro­mises, etc. Since people are not available to you as part of your paper, you make assump­tions. 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 descrip­tions, 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.

Further information

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.