My name is Ronan. I am a system architect. I work for Qblox, a scale-up company in Delft, The Netherlands. QCS is building a quantum control system (QCS), which one may describe as the “brain” of quantum processors (QPU).

I spend most of my time designing the control electronics and software for quantum control system, used for building high-performance quantum systems that scale to thousands of logically corrected qubits and beyond. I am involved in early prototyping and full-stack product development (hardware to software), as well as product definition, requirement engineering and roadmap alignment.

It is a fascinating job, where every day is an opportunity to learn something new, with fantastic, knowledgeable colleagues. I am writing this blog to share some of those learnings, of course, without sharing any secrets!

Feel free to email me at ronan or connect on LinkedIn if you want to know more!

Disclaimer: While I work at Qblox by the day, this blog is a personal project and does not reflect the views of my employer. The thoughts, ramblings, and opinions shared here are mine alone and haven’t been vetted, approved or modified by anyone but myself.

System Architecture at a glance Link to heading

The sysarch role Link to heading

That is a question I get asked quite often: What is a system architect (sysarch) expected to do exactly? The answer varies by company, country of operation, and business domain. Still, one concept remains constant: Communication

Yes, the role of the architect is to communicate complex ideas simply, whether to development and engineering teams, C-suite executives, or customers. It starts with understanding the problem with the customer and the product team, which is an exciting part of the role: creating a solution that makes the customer happy!

From there comes the traditional system requirements analysis and, often, a proof-of-concept prototyping phase, where I am usually hands-on. After that follows product development, where I act as a tech lead, working with cross-functional teams until the product is ready. Finally comes the product’s post-launch servicing.

Architectural Decision Link to heading

How do I reach an architectural decision? The role of the architect is not necessarily to decide, but rather to frame the problem by consolidating the inputs needed for a decision to be made. For example, the product team (”what does it cost to develop this new product? what is the time to market?”) or by the CxO team (”do we want to invest in this new technology? What is the ROI and long term strategy?” ).

It is about being Cartesian by researching and defining the pros and cons of each possible solution without subjective judgment. It is also about assessing cost vs. benefit, considering not just the implementation effort, but also the long-term maintenance, operational costs, and cognitive load on the team.

More importantly, it is also about negotiating social alignment, because any architecture decision that engineers hate or product managers don’t understand will fail. Reaching a decision means taking people on the journey. For the Product & Business Loop, ensure the choice delivers business value. For the engineering loop, seek critique from senior engineers, so they own its execution.

Refactoring Criteria Link to heading

This is a recurring question for all companies with a software product: Why and when should we refactor? It is common to think that when existing products are slow and unstable, and it takes too much time to fix the problems due to the accumulated technical debt, it is time to refactor. But the answer is not always the right one; instead, the role of the architect is to prevent the second system effect

My personal philosophy is to apply day-1 decisions, and check them against the “two-way door” test: Is the refactoring a one-way door (nearly impossible to reverse, like choosing a primary database paradigm) or a two-way door (easy to change later, like an internal library choice)? One-way doors require deep validation; two-way doors require speed.

Promoting the Engineering Culuture Link to heading

At a glance, the role of the sysarch is also to advocate for the proper engineering culture that creates value for both the engineering teams (less firefighting) and the product teams (faster time-to-market).

While the general idea is to invest now in your engineering/software stack to save time later in development, the actual challenge is to strike the the right balance between investing and over-engineering: develop the right tools and software components to make product development and maintenance easier, rather than over-engineering something that does not add value.

This also means for the architect to communicate frequently with the product and C-level teams to promote the work of the teams that invest their efforts into proper future-proof engineering instead of constantly firefighting.

Restructuring a Team Link to heading

At some point, refactoring the system is not enough, as Conway’s Law comes into play: “Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.”

The answer is not always to move people around, but rather to realign the team’s output with the business organisation, in a way that the sum of the two teams is greater than the sum of their parts. If a team does not create enough value because its communication structure is inefficient, create a system in which the team’s outcome is defined by better components and API promises that deliver more value to the business. And if the team fails to create new components, break the work down into simpler components with more straightforward API promises.

But, more importantly, this is about driving social alignment between the team and the organisation: imagine a company where the team changes itself to create more value. Wouldn’t that be the ideal situation?

AI and the design loop Link to heading

How did AI change the way I work? A lot! Like developers do vibe-coding, architects need to be better at writing “vibe designs” (as well as vibe system requirements) that can be fed directly into LLMs as input to produce code.

AI really helps when iterating on the design, as it can quickly generate many variations of the same design, enabling faster exploration of different options. Those designs can then be quickly prototyped to verify their assumptions and development complexities.

But more importantly, it is essential to remember that AI is not here to replace the engineers but to augment their capabilities and creativity. It is a tool to enhance the design process, rather than a tool to replace engineering judgment and expertise.

For example, check the diagram below: How many LLMs will tell you the diagram on the right shows an error on qubit 3 (Z₂Z₃), while it is actually a Byzantine error on qubits 1 and 2? (full explanations)

Some selected illustrations Link to heading