Technical Leadership for Software Architects

I just attended a 3-day workshop, "Advanced Software Architecture with Residuality" with Barry O'Reilly, and I enjoyed it a lot from start to finish. Barry takes you on a journey through software architecture, from its early foundations to the present day, all the way to introducing random stressors and building residues to find a resilient, fit-for-purpose architecture. This feels very strange at first. But the workshop is guided in a way that leads you straight to the aha moments, and you actually experience how it works. In the end, you will have trained an initially very pragmatic software architecture to withstand unknown stressors. With every software solution I've built, there was that little doubt: What if I (or we as a team) are wrong? Even after reading many books and applying plenty of state-of-the-art techniques, that doubt only got quieter, but never fully disappeared. It doesn't help that, in our industry, there are many very confident people preaching their methods like a holy grail. Barry dismantles that mindset very elegantly. And with residuality theory in the tool belt, I will probably sleep better in the future. If doubts still show up, it might be for a reason. So they should be translated into stressors and used to train the architecture to become more resilient. Before this, only one technique reduced my doubts in a similar way: Event Modeling. After the workshop I better understand why that is. It's just another "walk around the problem" as Barry says. But it is a very thorough one and it forces you to think about the details of information flows. And it involves stakeholders from the start. That implicitly brings up a lot of stressors early a project, when there is still enough time to integrate fixes (residues) into the solution. But: No method, no concept can answer every question. You always have to embrace critical thinking to find the best possible solution.

The last few days I had the opportunity to step back from day‑to‑day work and take some time to reflect on how we think about software architecture in business environments. I attended a workshop led by Barry O'Reilly on "Advanced software architecture with Residuality". There were many topics covered in this workshop (which I highly recommend to anyone interested in software architecture), but I want to highlight one idea that was particularly thought‑provoking for me. If we try to design an “optimal” architecture using purely logical reasoning and requirements engineering, we implicitly assume we know what the software will need to do in the future. But we don’t. That assumption is completely unrealistic. The context our systems operate in is a complex system full of unknowns, changing constraints, new interactions, and unpredictable behaviours. Traditionally, our answer to that uncertainty has been refactoring. But refactoring is only feasible, both technically and timewise, if the architecture allows it. If it doesn’t, even small changes become expensive or risky. Maybe the goal shouldn’t be to build an “optimal” architecture, but rather to build an architecture that can survive future states of a complex system: something that is adaptable and resilient to whatever reality throws at it. This is where Residuality comes into play, providing thinking tools to help design architectures that can survive. The nice thing about these thinking tools is that they don’t rely on the architect’s intuition alone; instead, they create the space to think more freely and laterally, while catching problems early.

Last week, I had the opportunity to attend Barry O'Reilly Advanced Architecture class - Residues. The ideas behind it sound controversial - until you understand that this is the nature of the world applied to software design. Knowing the techniques is only a subset of the required qualities, and it was as important to learn the former as the latter. What is really important is to treat our work seriously and to go and learn from Barry and others while they are willing to teach. There is a point where they are not willing to teach anymore, and you might simply miss out and keep doing your little thing in the comfort zone, afraid to learn that all you have been doing so far is illusion at best and quackery/hand waving the majority of the times. Before parting ways, Barry provided us with reading material, some of which I need to refresh and most of it I need to read. Get out of your echo chamber fed by a loop and check alternative perspectives. You might not accept them, even then you will know your premises better. Kudos to Software Leader for organizing these classes.

Attending an advanced software architecture workshop led by Barry O'Reilly was a transformative experience. Initially skeptical about the residuality theory, I was pleasantly surprised by the depth of knowledge shared over three days. We explored Barry's academic research, tracing its origins from ancient Greek philosophy to complexity science, and culminating in a mathematical proof of the residuality theory based on boolean networks. The workshop was free from sales pitches. Barry presented his work with the calm assurance of someone confident in the scientific and peer-reviewed nature of his findings. The practical methods we learned are immediately applicable, requiring only a spreadsheet and lateral thinking to move beyond traditional structuralism. A key takeaway for me: while we cannot predict the future, we can design our systems to withstand the unknown unknowns that will never appear in any specification or requirements document. If you are building complex software systems, then there is no way around the residuality theory. Thank you Martin Helmer for organizing, Boško Stupar for pointing me to this event and Markus Gasser Alex Stücker Zdravko Lucic Bruno Roque Sebastian Bortz for interesting discussions on software architecture topics.

Roman said it well. Barry has sorted it out for us. We now have the opportunity to move past the hand waving game to a fuzzy Monte Carlo simulation to make our architectures survive back swans. Thanks Barry O'Reilly for moving the field forward. This is the first time since the university that I feel like we are at the paradigm shift. From all the books I've read and courses I've visited and conferences I've attended to, I alway had my reserves and parts that I'd rather leave out when I try to apply the techniques learned. Now I don't have any reserves (apart from reading Plato's and Aristotle's body of work) and I truly want to use this to make stuff anti-fragile. Barry even made me curious about academic work in the IT again! For almost 20 years now I didn't see much academia in the IT, and that was the main reason why I didn't want to waste time after the Masters degree with some pesky PhD. Now, this all makes sense again! There is a lot to build upon this work and I am really curious where this is going to take us. I am convinced however, that where we're going, we're not going to need roads.