I originally posted this as a thread on Twitter in response to a recent #DevDiscuss topic. I'm reposting here to preserve these thoughts and for others to easily refer to it.
Software architecture concerns itself with how the software is built, including high-level design and technical standards, as well as coding standards, tools, platforms, etc.1
A software architect is a software developer who has become an expert in these things through extensive experience practicing them and learning from others.
A software architect (as a role) is a leader in the organization, helping the team turn a problem domain into software. They are able to grasp the concepts of the domain and communicate how to represent them in code. Additionally, they work with the team to set standards and develop practices that will ensure the quality of the software created and the long-term maintainability of the code. They balance purity with pragmatism, considering the business goals and priorities—and they articulate the risk to the business when sacrificing quality/purity for accelerated timelines.
I believe a software architect should be a mentor, using their experience to teach others how to create the best software they can. This involves in-depth code reviews and pair programming, among other teaching techniques. Good software architects are humble and patient. They don’t berate or belittle their team for not yet grasping concepts that they see clearly. Instead, they use these moments as teaching opportunities.
Many see coding as formulaic as algebra equations. Software developers are natural problem-solvers, often seeing a code solution based on a formula before fully understanding the problem. Software architecture is different. There is no formula for it. There are recurring patterns seen across problem domains, and Martin Fowler has cataloged many, but his book Patterns of Enterprise Application Architecture cannot be treated as a formula by filling in the blanks and generating the code. It doesn’t work that way.
Learning to design software from an architectural perspective is an exercise in grokking2 the problem, taking a Zen-like approach to perceiving its true nature. To do this, you must exercise restraint so you don’t cloud your mind with thoughts of the solution before you fully understand the problem.
Top comments (0)