iSAQB Software Architecture Gathering
1. Your session argues that leadership, negotiation, and collaboration are just as important as technical expertise. In your experience, what's the biggest communication mistake software architects still make today?
In my experience, the biggest communication mistake I see software architects make is telling teams what the architectural structure and constraints are rather than collaborating with them to create a sustainable and working architecture. This is a common trap due to the belief that architecture and software development are two separate practices, when in fact they have to be done collaboratively to make software systems work. Along those lines, it’s been my experience that many software architects place too much emphasis on communication rather than collaboration.
Communication is telling someone what needs to be done or how something works, whereas collaboration is about coming up with a solution together by bring the other party in on the conversation. A good example is this: Suppose a team is struggling with a scalability issue, and an architect is brought in to assist with the problem. The architect takes one look at the problem and says “well, what you obviously need here is a cache. That would solve all of your issues”. That’s not collaboration, that’s communication (telling someone what the solution is). Now let’s suppose the architect looks at the problem and asks the development team “Hmm, have you considered using a cache right here?” Notice the solution is posed as a question, drawing in the team to have a discussion. Many times turning communication in to collaboration is a simple matter of posing your suggestion or solution as a question rather than a command.
2. Software architects often need to bridge the gap between technical teams and business stakeholders. How can architects build credibility with business stakeholders without sacrificing technical integrity?
The real key here is for software architects to have a keen sense of the business domain (such as banking, retail, transportation logistics, finance, and so on). In my experience one of the best ways to lose credibility with the business is to not understand their language or not understand some of the core concepts of the business. Asking a business stakeholder “Can you tell me again about this whole credit swap thing?” Is a sure way to lose the trust and respect of the business sponsors and stakeholders. The time to ask those kind of questions is BEFORE becoming an architect. It’s not expected that most developers have a keen sense of the business. It’s certainly nice to have (and in some business domains required), but for the most part that’s the role of an architect to provide the additional business context.
Another way credibility gets lost with business stakeholders is when architects and dev teams simply accept new features or requirements for a system at face-value, which many times results in cost overruns, complicated solutions, and more effort and time than expected. Gaining credibility with business stakeholders means collaborating and negotiating with them to help the business understand some of the trade-offs associated with the requirements they create or desire. For example, suppose the business creates a set of new features (let’s call them A, B, and C) they would like added to the system. Features A and B are fairly straightforward, but feature C would require a massive restructuring of part of the architecture of the system. Without any collaboration or communication, the team would struggle to implement all three, resulting in cost and time overruns, and consequently some very unhappy business stakeholders. If an architect educated the business of the trade-offs involved with the three requirements and the difficultly in implementing feature C, the business is now armed with additional knowledge to make a decision whether to move forward with that feature or not.
3. Your workshop explores architecture patterns, anti-patterns, and the trade-offs behind them. In your experience, what separates architects who consistently make good architectural decisions from those who repeatedly fall into the same traps?
Many architects fall into an anti-pattern known as the “Cart Before The Horse”, where they make decisions without having a good basis for making them. One of the patterns I’ll be talking about in the workshop is the “Frozen Caveman” antipattern, where an architect has been burned by a prior decision or situation, so every future decision is based on that experience alone.
The biggest mistake I see in my experience is seeing architects make architectural decisions without first understanding what the critical or important architectural characteristics—things we now are calling architectural capabilities—are of the system. These include things such as scalability, maintainability, responsiveness, and so on. I frequently as architects who fall into this trap “So, what exactly are you basing your decision on?” Answers I get include things like “gut feel”, prior experience (that’s the Frozen Caveman AntiPattern), recent trends, or my favorite, “well, that’s the way we’ve always done it.” Good decision making requires good trade-off analysis, and good trade-off analysis requires knowing what capabilities are important to your system.
4. Microservices have shaped software architecture for more than a decade. Do you think the industry has become more pragmatic in deciding when to use them, or are we simply replacing one architectural trend with another?
I see both actually. I’m at some client sites where I see a responsible and cautious use of microservices, and I’m at others where I see lots of anti-patterns and pitfalls. After almost four decades of being in this field, it’s been my experience that Microservices is the hardest architectural style to get right. Service granularity, bounded contexts, data, and managing distributed transactions and workflows are just a few of the many difficulties teams face when trying to get Microservices right.
In my workshop I touch on some of the more common patterns (and anti-patterns) surrounding microservices, including the “Grains of Sand” pitfall, and the all-too-common “Microservice All The Things” pitfall (to name a few).
5. Architects often talk about making trade-offs, but making the "right" trade-off is rarely obvious. Is there a software architecture principle that you believe many architects treat as universal, even though it really depends on context?
In our book "Fundamentals of Software Architecture" (2nd Edition) we coined several laws of software architecture. Our first law states “Everything in software architecture is a trade-off”. This law implies that there are no “best practices” in the structural aspect of architecture. You can’t say “always focus on performance”, because some systems don’t need performance—they need availability. We always stress to architects not to seek the “best” architecture, but the “least worst” architecture. This is because architecture is always full of messy trade-offs, meaning you have to give up one thing to get another.
One universal principle I’ve seen architects and dev teams repeatedly treat as universal is this one: “Always strive for loose coupling and strong cohesion”. I remember that axiom myself from the mid-1990’s. However, going back to the first law of software architecture, one might ask “Okay, but what are the trade-offs of doing so?”. And this points to the first corollary of the first law, which states “If you think you’ve found something that doesn’t have a trade-off, keep looking—it’s there.” The trade-off of loosely coupled systems is distributed workflows that are difficult to understand and maintain. The trade-off of strong cohesion is the tendency to create services that are too fine-grained, leading to the “Grains of Sand” pitfall I talk about in the workshop.
Some words of advice: watch out for phrases or practices that use the words 'always' and 'never'. There’s a trade-off there, however insignificant.
6. Looking ahead, what do you think will become the most important skill for software architects over the next ten years that isn't receiving enough attention today?
For those that know me, you’d expect my answer to be leadership skills. While I believe this to be true (and it’s still a critical skill, particularly in the age of A), I have a different answer this time.
One of the most important skills an architect can have today and in the next ten years, particularly with agentic code generation on the rise, is to understand the importance of governance and architectural fitness functions and how to apply those to systems teams create and maintain. This brings us to the topic of architecture as code—the ability of an architect to describe and govern an architecture through executable source code.
Neal Ford and I are currently finishing up our book by the same name, "Architecture as Code: Quantifying the Intersection of Software Architecture", due to be published in January 2027. By leveraging architecture as code and fitness functions, architects can now have better insights as to if the actual implementation of the system matches the intended architecture, and if the system is meeting required (or desired) architectural capabilities. This skill provides architects with the fastest possible feedback loop that something is misaligned with the architecture—whether it be implementation, the data topology, team structure, infrastructure, integration architecture, enterprise architecture, engineering practices, and even the business.
Those with an O’Reilly Leaning account can get a sneak preview of the early release of the book.
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