iSAQB Software Architecture Gathering
1. In your session "Software Architecture Trade-off Analysis," you start with a statement many architects know well: "It depends." In your experience, what's the most important factor that software architects still tend to overlook when evaluating architectural trade-offs?
Context. "It depends" is the correct answer to every question in software architecture — the problem is that architects stop there rather than asking the follow-up: "Depends on what?" The most common failure mode I see is architects doing trade-off analysis in generic terms — reading about how some famous company solved a problem and assuming the same trade-offs apply to them, when that company's constraints, scale, and business drivers have almost nothing in common with theirs. Never take architecture advice from someone who doesn't know your context.
The second thing they overlook is that trade-offs aren't static: the analysis you did two years ago was correct THEN, but the ecosystem, the team, and the business have all shifted underneath it, so trade-off analysis has to be iterative, not a one-time ceremony.
2. Trade-offs often involve balancing technical concerns with business priorities. In your experience, what's one architectural decision that tends to look "wrong" in isolation, but makes perfect sense once the broader business context is taken into account?
Duplication instead of reuse. Every architect has had DRY drilled into them since their first programming course, so deliberately duplicating code or data looks like malpractice in isolation. But reuse creates coupling — every team that shares that library or that service is now handcuffed together, and a change for one becomes a coordination exercise for all. When the business priority is independent team velocity and fast time-to-market — which it usually is in a microservices world — duplicating something small and stable is often the cheaper trade-off than sharing it. Reuse is a great idea right up until the moment it isn't, and only the business context tells you where that line falls.
3. Your session introduces modern techniques for trade-off analysis as an alternative to more bureaucratic approaches. What do you think today's software architects should spend less time debating and more time verifying?
Almost everything they currently debate in conference rooms. So many architecture arguments — will this hurt performance, will this break our modularity, can this scale — are empirical questions wearing philosophical costumes. Two architects trading anecdotes about elasticity is a war story exchange; a fitness function that measures it against the actual system is verification.
The bureaucratic approaches fail because they front-load enormous analysis effort into documents nobody validates against reality; the modern approach is to make the smallest responsible decision, encode the concern as something executable, and let the running system tell you whether you were right. Architects should hold opinions loosely and hold measurements tightly.
4. Your workshop "How To Teach Your Agents About Architecture" explores how architects can teach both humans and AI agents to follow architectural intent. Which aspects of software architecture do you think are surprisingly easy to teach to an agent, and which ones still depend heavily on human judgment?
The structural stuff is surprisingly easy — anything with a deterministic answer. Layer dependencies, component coupling rules, naming conventions, "nothing in the domain layer touches the database directly" — these are exactly the governance checks we've been writing as fitness functions for a decade, and agents are both good at following them and tireless about it, which is more than I can say for most humans.
What still requires human judgment is everything upstream of the rule: WHY the rule exists, when the business context has shifted enough that the rule should change, and how to weigh competing trade-offs that have no objective answer. An agent can enforce architectural intent all day long; it can't yet decide what the intent should be, because that decision lives at the intersection of technical constraints and business strategy — and nobody wrote the business strategy down in the training data.
5. Your workshop emphasizes embedding architectural rules into specifications and generating deterministic guardrails. How do we make sure those guardrails encourage good engineering rather than simply enforcing rigid compliance?
Every guardrail has to carry its "why" with it. A rule without a rationale is just bureaucracy that compiles — people (and agents) will comply with the letter of it while cheerfully violating its purpose. So we pair every rule with the reasoning behind it, the way a good architecture decision record does, which lets both humans and agents recognize when they've hit a legitimate exception rather than an obstacle to route around.
The second safeguard is treating guardrails like code: versioned, reviewed, and deleted when the context that justified them disappears — a stale guardrail is worse than none, because it teaches people the rules are arbitrary. Think of guardrails on a mountain road: they don't steer the car for you, they just keep mistakes from being fatal. The moment your guardrails start doing the steering, you've built a bureaucracy, not an architecture.
6. As AI becomes a permanent part of software development, do you think the role of software architects will gradually shift from designing systems to designing the rules and guardrails that both humans and AI agents use to build them?
Partly — but I'd frame it as making explicit what was always the job. Architects have never really built systems; we've defined the constraints and structures within which systems get built, and then relied on hallway conversations, code review, and hope to see the intent survive contact with implementation. AI forces us to make that intent explicit, precise, and executable — specifications, fitness functions, guardrails — because agents can't absorb intent by osmosis, and frankly humans never absorbed it that well either.
So yes, more of the architect's output becomes encoded intent rather than diagrams. But the core of the role doesn't move: someone still has to do the trade-off analysis, understand the business drivers, and make judgment calls where reasonable people disagree.
The medium changes; the "it depends" doesn't.
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