I Thought I Knew Software Architecture (feat. iSAQB)

On a quiet Sunday evening, I was reading Building Microservices (by Sam Newman) and I was almost at the end. The final chapter was titled “The Evolutionary Architect”.

This was right at the beginning of the chapter:

At whatever level architects operate, their role is a tricky one to pin down and despite it often being the obvious career progression for developers in enterprise organisations, it is also a role that gets more criticism than virtually any other in our field. More than any other role, architects can have a direct impact on the quality of the systems built, on the working conditions of their colleagues and on their organisation's ability to respond to change and yet their role seems very poorly understood. Why is that?

Yeah, why is that?

Although I finished the rest of the chapter, I wasn’t completely satisfied. The book gave me another perspective on what it means to be an architect and it certainly made me think differently about the role. But it didn’t quite answer the question I had in my head.

The question stayed with me. The more I thought about it, the more I realised just how difficult the role of an architect is to define.

This resonated with my own experience. Having spent most of my career at startups, I’ve found that being an architect rarely came with a neatly defined set of responsibilities.

I had to wear multiple hats. Owning the functional and quality requirements of our systems, ensuring the systems could evolve with the needs of the business. Improving the environment my colleagues worked in and designing and building systems they’d be happy to come back to on a Monday morning. Sometimes making decisions that delivered short-term benefits but created long-term problems and then defending those decisions (the decision stays, but the context gets happily forgotten - seriously, start doing ADRs). And when necessary, I had to get my hands dirty and code some of the most difficult parts of the system myself.

I started looking for some kind of standard for software architecture and stumbled upon the iSAQB (International Software Architecture Qualification Board).

Well, that sounded like a standard.

I went through their curriculum and was genuinely impressed by what they were trying to do with the role. They were trying to establish a common language and a shared understanding of what software architecture and being a software architect, actually means.

That's exactly what I was looking for!

They also had a set of mock questions and answers, so I decided to test myself. The questions and answers were originally available as a PDF, but scoring it was quite painful. Luckily someone had turned them into a beautiful, interactive interface that felt just like taking a real exam: iSAQB Mock Exam.

I scored decently and passed. But it wasn’t good enough. The questions felt very relatable, but the answers were surprisingly tricky. Whenever a question touched on the role of an architect my first reaction was, “Hmm, a lot of these options sound right. I’ve been doing a lot of this myself.”

Surprisingly, I had got a lot of those questions about an architect’s role wrong. My experience designing systems gave me a strong foundation for the design-related questions, while my experience with software quality (and my ISTQB certification) put me on solid ground with the quality-related questions. But the questions around the architect’s role, responsibilities and communication exposed a gap I hadn’t really considered before. I had plenty of practical experience, but I clearly didn’t have a structured understanding of the principles behind the role.

I wanted to understand the material more deeply and see how I actually measured up against the standard. So I got fired up and decided to take the real exam.

Monday came around. Work took precedence and this quietly slipped down my priority list. Three years passed.

Luckily, I have a backlog of things I’ve wanted to learn throughout my career. So, on a fine Saturday morning, while looking for something new to learn, I stumbled upon this again and decided it was finally time to do it.

I found two online training providers: HVDSoft and Verity. I emailed both asking for a quotation.

HVDSoft came back with a quote of around ₹78,000.

Verity came back with around ₹36,000.

I gulped.

Both quotations also had a clause stating that if there weren’t enough participants, the training could be cancelled or rescheduled. So now I had two problems: I’d be spending a fairly serious amount of money on the training, while also running the risk of having it rescheduled multiple times.

I’m not letting that fire burn out again.

The combination of the cost and uncertainty made me a little uncomfortable, so I started looking for ways to prepare without burning a hole in my wallet.

That’s when I noticed that iSAQB also recommends Software Architecture Foundation (by Gernot Starke and Alexander Lorz). I checked the reviews on Amazon and found several people saying they had prepared for the certification using the book and successfully cleared the exam. I also reached out to a few people on LinkedIn and the feedback was pretty encouraging.

Luckily, I’m a bit of a bookworm.

I had already crunched through some fairly dense books like Building Microservices (by Sam Newman), which triggered this whole journey, Accelerate (by Gene Kim, Jez Humble and Nicole Forsgren), which Kiran, then CTO at Melento, had me read to help measure and improve our software delivery performance, Designing Data-Intensive Applications (by Martin Kleppmann) and a few others. So I was reasonably confident that I could self-prepare for the exam.

So I bought the e-book from Kobo. Cost me around ₹4,700.

I finished the book in a couple of days. Then I spent another couple of days re-reading it and highlighting the important bits. One more day and I just went through the highlights.

Once I felt reasonably confident, I took the mock exam again.

I scored 100% in 9 minutes and 5 seconds.

At this point, confidence was off the roof.

So, I bought the actual exam from iSQI, cost me around ₹16,000 and scheduled it for the very next day.

The exam experience was quite new and fascinating. The exam was remotely proctored, so I could take it from home. I had to clear everything from the room and share my video, audio and screen with the proctor. They also had me change a few system settings and show the processes running on my laptop. I then had to use my mobile camera to show my laptop screen and the surroundings of the room and keep it positioned so that I remained visible along with my screen and keyboard throughout the exam.

The exam had 42 questions to be completed in 75 minutes, with three types of questions: A, P and K. A-questions are Single Choice, where only one answer is correct. P-questions are Pick Multiple, where you have to select a specified number of correct answers. K-questions are Allocation Questions, where you assign options to the appropriate categories. The scoring also varies by question type. A-questions have no negative marking, while P and K questions can penalise incorrect selections. You need to score at least 60% to pass.

By this point, I had spent enough time understanding the concepts and working through the material that the questions felt pretty straightforward. The things that had seemed tricky when I first attempted the mock exam now made much more sense and I could reason through the answers with confidence.

I scored 85% on the exam and, just like that, became an iSAQB Certified Software Architect. It felt good to finally close the loop on something that had started with a simple question I had while reading a book.

The clarity I gained from this process was incredibly satisfying and I would highly recommend it to anyone practising software architecture.

You’ll find that so many questions start getting answered along the way and you come out of the process with a much clearer understanding of what it actually means to be a software architect. You’ll have a better framework for thinking about architecture, making trade-offs, communicating decisions and navigating all the messy bits that come with the role.

Although you now come out of the process strongly equipped with the knowledge of what a software architect should be doing, there’s another beast waiting for you: Change Management.

Knowing what needs to change is one thing. Actually getting people, teams and the organisation to change is a completely different challenge.

So, please don’t come out of the exam and march into a meeting with your colleagues saying, “According to iSAQB, this is not my responsibility.” And definitely don’t start turning every architecture discussion into a courtroom drama about who is doing it wrong. The goal is to become a better architect - not to collect a shiny new set of arguments to win debates.

So, what's next?

iSAQB also has an Advanced Level certification, but that’s a much bigger commitment. To qualify, you need at least 70 credit points from Advanced Level training across the three areas of competence: methodology, technology and communication. There are currently no training providers available in India, which makes it a little harder to pursue from here. And the exam itself is a very different beast. Instead of another multiple-choice exam, you work on an architecture assignment, which is evaluated by examiners, followed by an interview where you defend your work.

And then there’s the cost. The exam itself is around ₹3,00,000. That’s a fairly serious investment, so I’m going to leave this one for the future. I’ll see where my architecture journey takes me and decide later whether the Advanced Level is something I want to pursue.

If you’re considering the iSAQB certification yourself, I hope this gives you a clearer picture of what to expect - not just from the exam, but from the learning journey that comes with it.

More importantly, if you’ve been putting this off for a while, I hope this gives you that little push to finally get started. You don’t need to know everything before you begin. Take the mock exam, find the gaps in your understanding, pick up the book or take a training program and work through those gaps. That’s pretty much how I did it.

And along your journey as a Software Architect, pick up a few books. You never know where a quiet Sunday evening, a good book and a simple “Why is that?” might take you.