Recently I have taken a 4-day training culminated in the
iSAQB CPSA Foundation Level Exam. The CPSA, by the way, stands for Certified Professional for Software Architecture.
In this post I want to share my thoughts about it.
Why this exam?
The iSAQB organization is trying to position themselves as an industry standard, more or like Project Management Institute with its PMBoK standard. But in the end I didn’t really specifically choose it, it was a suggestion by my boss from the company I’m currently working for — Netconomy, to take it.
The exam is not focused on any specific architecture technology – Kubernetes, AWS, Oracle, whatever, but is rather about the theoretical standards. iSAQB claims that the certification has been gaining popularity over time:
What have I learned?
I think, the best way to illustrate the benefit is this image:
So, my knowledge has become more organized.
Have I learned anything else?
The second benefit is that I have finally learned what the hell should software architect do and what he shouldn’t do. In essence: he should constantly battle.
Battle with a client against requirements that do not make sense.
Battle with Project Manager who: “we need this feature yesterday and I don’t have a budget for your, howd’ya call it, reee-fucktoring“.
Battle with developers, who have got used to having no documentation at all and are frustrated that implementing small changes takes weeks.
However it’s not that bad. At least you learn the standard ways to communicate the architecture (hint: that’s your numero uno responsibility) and you also learn the standards you can refer to. You can strongly argue your views to get budget for things.
Course topics
Basic Concepts
The definitions of what exactly the Software Architecture is. Software Architect’s responsibilities. The difference of Software Architecture compared to Business Architecture. Conway’s Law.
Influencing Factors
Functional vs Quality Requirements. Constraints (Organizational, Technical). Architecture goals (hint: the main goal is that the product does not degrade after many years of changes).
Design and Development of Software Architectures
From System Context view to Black Box view to White Box view. The ways how to visualize your ideas and decisions step-by-step from a general perspective to the technical details (down to classes/files). Explanation why is Business Architecture orthogonal to the Technical Architecture. Top-down vs. Bottom-up approach in describing architecture. Specific approaches: DDD, Model-Driven Architecture, Reference Architectures. Basically, what standard languages or metaphors you can use to describe what you are going to create, so that you don’t invent your own ones.
Architectural and Design Patterns
- Architectural Patterns: MVC/MVVM, Master-Slave, Client/Server, RPC.
- Design Patterns: Facade, Adapter, Factory etc. you know them
Interfaces and Dependencies
So, you have already described the blocks, now how would you describe interactions between those blocks? Types of dependencies (e.g. temporal when internal service waits until a remote service is finished working and hangs). SOLID principles.
Cross-Cutting Concepts
Basically, you should understand what it is and how it influences the architecture. Logging, Exception Handling, Security, UI Layer. This is something you never find in specification from a client (’cause they don’t care) and this is something you should actively fight for.
Risk Management
Surprise! That’s your job now as well. Learn FMEA. Next!
Specification and Communication
Attributes of a good technical documentation. Reminder to adapt documentation to each class of readers. Context View → Building Block View → Runtime View (Sequence, States) → Deployment View (4 nerdZ). Basically, we learn UML diagrams again ’cause there’s nothing better.
Software Architecture and Quality
Quality Models (Basically just ISO 25010). Quality Metrics: Lines of Code (haha, lol), Cyclomatic Complexity, blablabla. Qualitative Methods: ATAM (Know in Russia as “АТАМУНИХВООБЩЕКАПЕЦ”), Quality Trees etc. A big topic is how to assess the amount of shit that the development team has produced over the years.
Tools
Final topic. SonarQube, Sonargraph (has nothing to do with the former, it’s just a fu-, I mean, wonderful naming coincidence). Tools for code generation (there are no good ones).
All topics in one place (clickable)
Exercises
The best part of the training were exercises. We were split to 3 teams and given the description of a software — in our case it was a place where people could lend the tools they don’t use — and description of use-cases: lending, borrowing, login and others.
Each team first would create and present context view, then white box view, then perform risk analysis and defend each of the presentations against the other teams. That was kinda fun.
Exam
You get 43 random question from a tight pool (feels like 45-50 total). The questions are of 2 types.
Exempli gratia:
Type 1: “What is beneficial to do if you are working as architect in the scenario when <description_of_a_scenario> ?”
| [Beneficial] [Not beneficial] | |
| [] [] | Do A |
| [] [] | Do B |
| [] [] | Do C |
| [] [ ] | Do D |
Here you have a bunch of statements and you have to decide which ones are true and which ones are not that true.
Type 2: “Which ones of these are <some_definition> (2 correct answers)?”
- [] A
- [] B
- [] C
- [] D
- [] E
Here you are allowed to select 0,1 or 2 answers.
Calculation of points
The calculation of points is very funny. For each question there is a maximum: either 1 or 2 points. If you answer completely correctly — guess all true/false statements, you get the maximum points. Otherwise you can get any fraction of points between 0 and maximum. Be aware that a wrong answer to a statement counts as a negative fraction.
For the second example here is what you get for your answers if the maximum has been 1:
- Two marked, both are correct answers = 1 point
- One marked and is a correct answer = 0.5 (1 of 2 guessed right)
- One correct, one incorrect = 0 (+0.5 – 0.5)
- Two marked and both are incorrect = 0 (you can’t get less than 0)
Now the main problem with answers is that many of them are very controversial, not covered in the training or contain some difficult phrases. And all this ambiguity is especially frustrating when you get the result saying:
“You got 59.85% correct. Required score is 60%. Sorry, you did not pass.”
So the best strategy I have coined is to mark only those answers where you are pretty sure they are correct and skip the rest. Don’t get greedy, otherwise
Oh yes, you got it — required score to pass the exam is 60%.
Post Mortem
Would I recommend passing the training? Yes, I guess so. It gives you certainty in things you already do and maybe some hints as to how to do it better. Remember, a Software Architect is not about writing working code.
Would I take the exam results seriously? Well, not really. We had a group of 9 people from the same company and if you plot our results you get this:
Top cluster contains scores 74-85% for three guys who have already worked as architects for like three years so it kinda confirms their experience.
The close group in the middle: 65-68%
Two unlucky ones got the score slightly under 60%
Which means, there is not much sense dividing people by whether they passed or not, but it makes sense to say to a colleague: “Suck it I’ve got much better score than you, haha!”. No, don’t do it please.
Another point is that the training itself and the exam are felt very beta. Things and terms are changing, complete topics are thrown away and replaced. Maybe, in 6 months the questions pool will contain 83% new questions.
And yes, I’ve passed.