Expanding Your Architectural Thinking: A Guide for Software Practitioners

In software development, practitioners must have an architectural mindset, understanding the implications of technology decisions, analyzing trade-offs, and consistently updating their technical knowledge.
This article shares some of the insights from a thought-provoking talk given by Mark Richards at the Great International Developer Summit (GIDS) 2023 in Bengaluru, India. Mark, a seasoned software architect and author, shared his insights on how software practitioners can expand their architectural thinking to create more effective and efficient software solutions. You can watch the full talk here for free.
In this article, we delve into the key points from Mark's talk, including understanding the broader context of your work, analyzing trade-offs, expanding technical knowledge, and the importance of avoiding over-evangelizing any particular technology or framework. We also discuss the "20-minute rule", a daily practice Richards recommends for expanding your technical breadth.
Architectural Thinking Mindmap
Understanding the Broader Context
The first step in thinking like an architect is to understand the broader context of your work. This involves identifying the key characteristics that your architecture needs to support. For instance, if your business prioritizes time-to-market, your architecture should support characteristics like maintainability, testability, and deployability.
Analyzing Trade-offs
Every decision in software architecture involves trade-offs. For instance, you might have to choose between performance and maintainability. The key to making these decisions is understanding the business drivers. If time-to-market is a priority, you might opt for maintainability over performance, even if it means your system will run a bit slower.
It's also important to avoid the "out of context" trap. This occurs when you make decisions based on a list of pros and cons without considering the specific context of your project. For example, while a shared library might seem like the best choice based on a general scorecard, a shared service might be a better fit for your specific project if you're using polyglot programming and need to manage frequent changes to shared functionality.
Expanding Technical Knowledge
To stay ahead in the field, it's crucial to continuously expand your technical knowledge. Resources like InfoQ, DZone Refcards, and the ThoughtWorks Technology Radar can help you stay updated on the latest trends and technologies.
However, it's not just about knowing what's new. It's also about understanding what these technologies do, why they exist, and how they differentiate themselves from others. For instance, you don't have to code in every new programming language, but you should understand what they do and why they're there.
Avoid Over-Evangelizing
While it's natural to get excited about a new technology or framework, it's important to avoid over-evangelizing. This can hide the trade-offs that inevitably exist, leading to decisions that might not be in the best interest of the project. Remember, everything in software architecture is a trade-off.
The 20-Minute Rule
Finally, consider adopting the "20-minute rule". Spend at least 20 minutes each day expanding your technical breadth. This could involve reading articles, exploring new technologies, or even just creating a list of words you've never heard of. The key is to make this a part of your daily routine, ideally first thing in the morning.
In conclusion, thinking like an architect doesn't necessarily mean you have to become one. Whether you're a developer or an aspiring architect, adopting an architectural mindset can help you create more effective and efficient software solutions.
Have questions or comments about this article? Reach out to us here.
Banner Image Credits: Mark Richards Speaking at Great International Developer Summit








