iSAQB Software Architecture Gathering
In connection with his SAG 2026 keynote “Dark Modules and Cobots: Architecting for AI” and workshop “Resilient Distributed Systems,” Sam Newman answers questions by Richard Wallintin (WPS – Workplace Solutions) about how AI is transforming software development, why architectural fundamentals still matter, and what it really takes to build resilient distributed systems.
1. We are in a transformation of software delivery through "AI": What exactly has changed?
Lots! Firstly, we’re removed generation of code as a bottleneck in our delivery process, if it ever was. This is putting more pressure elsewhere – for many organizations this includes challenges around human review and verification of the generated code.
More generally we’re at the point as an industry where we have to consider if AI is the next abstraction point for us – in the same way as we shifted from machine code to assembly, assembly to general purpose programming languages, and now perhaps AI. This is far from certain as far as I am concerned, but even amongst the many firms I have spoken to who largely never look at the AI-generated code, there is still a wide variety of approaches, with lots of experimentation going on, and that is healthy.
2. There are many hints that pretty-well-known concepts around software architecture and design may become even more important when employing ML models (first and foremost LLMs I guess) in the process of developing software. (modularity and all concepts and heuristics revolving around it) Do you agree? Do you have examples of established best practices becoming obsolete? Are there entirely new design heuristics appearing?
What hasn’t changed is the fundamentals around software delivery. Small changes are still better than large changes. Frequent small releases are still better than infrequent large releases. Just because you’re doing spec-driven development, it doesn’t mean that reimplementing waterfall is a good idea.
Modularity allows us to vary (and experiment) with how we use AI, and can also scope agentic behaviour to mitigate security concerns. So that concept is still vital. I’m unsure as to the future of TDD though. I think if you see TDD as a design dicipline (which I largely do), then I think the idea of using TDD to “design” a function call is dead. I’m not sure yet what replaces this, or if it just goes and becomes some variation of Acceptance test driven development.
3. How do you address the question of sustainability of "AI"-based software delivery — both in terms of the negative externalities of GenAI (hidden costs) and visible, charged costs for tokens?
From a sustainability viewpoint, we should split that into financial sustainability and environmental. On both sides of that the answers aren’t great.
We have very little clarity around the real cost of the AI services we use, due to a combination of very murky financials being shared by the foundation labs and assumption that many if not most of the services we use are highly subsidised right now. As such it is hard to know what our spend might be in the future, even if our use of AI had stabilised. This is even more difficult when you consider that most firms are still experimenting with how to use AI for software delivery, and the definition of what “good” looks like is changing month by month.
From an environmental angle, generative AI is pretty terrible, and I have no good answers here. I think the best thing for the planet might be for a GFC-scale financial collapse, which will hopefully reduce carbon output and wider environmental damage.
4. Isn't the first rule of distributed systems to avoid them if you can?
Cute! But if you define a distributed system as two or more computers connected by networks, then I think you’ll see that the vast majority of people cannot avoid them. So I’d rephrase that to “the first rule of distributed systems is to distribute them as little as possible.
5. Did you encounter unnecessary (over-)engineering of distributed systems that misses the relevant failure scenarios? Often?
Frequently, but not in the way that the question implies. Building a properly resilient system requires making your system more robust, making sure it recovers well when something goes wrong, making sure the people operating the system can deal surprise, and ensuring that you continue to learn and adapt the system to make sure it continues to be resilient as things change. Many distributed systems I’ve seen focus primarily on robustness, but not much at all on the other stuff.
6. How do you find and pin-point the actual availability requirements of systems (instead of just assuming 24/7/365 + "five nines")?
Speak to the people using the system. What do they need? Break out key pieces of functionality and determine availability requirements on a case by case basis. Your contractual SLA defines the bare minimum you need to deliver, but if you just deliver to the letter of the SLA your customers are typically still annoyed.
Track targets over either quarterly or monthly windows. Don’t track across a full year – if you have one bad day in January you can blow through your error budget for the rest of the year. So define SLOs at a team level that will deliver what the customer needs, and use them to drive team behaviour.
7. Is the amount of work and continuous effort for resiliency often under-estimated? Or is it easy if you know what you're doing?
Under-estimated implies that people often know what they need to do to be resilient, and in my opinion they often don’t! It starts with defining acceptable resilience, then identifying what work is needed to obtain (or retain) the required levels. Really embracing the idea of resilience engineering is less around having work items to tick off, and more about adopting a change in mindset and culture. The systems we build are sociotechnical – when looking at resilience, we need to consider the hardware, software, processes, culture, and people operating and using the software. I think we unfortunately often take a too narrow view on making systems resilient.
You need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from Turnstile to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Turnstile. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Vimeo. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from YouTube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Facebook. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Instagram. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Google Maps. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from X. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information