Most software development teams have one person with the role of Architect. Small teams of one or two people may not, but someone is thinking about architecture. This person’s title may be Solution Architect, Application Architect, Data Architect or Systems Architect. For now let’s consider all of them under the collective name of Software Architect. In this article I’ll talk about the characteristics of a good architect, and I’ll explain what a software architect does. I’ll also address the evolution of the role of software architect, and where it is today. By the end I hope you’ll have an answer to the question “so what does a software architect do anyway?”
Who is This Software Architect?
A software architect is the person responsible for the technical design of the product that the team is building. Most often they come into this role after spending several years honing their craft as a senior software developer. Along the way they built up their design and communication skills. They have worked often enough with network specialists, database administrators, business and systems analysts that they have a sound working knowledge of those areas. They are not necessarily experts in those areas, but they can have an informed conversation with the people in those roles.
The broad technical knowledge our architect posesses is also deep in one or two areas. For example, they have a basic working knowledge of networking, front-end tooling and server configuration. At the same time, they have deep expertise in the specifics of a programming language as well as continuous integration/continuous delivery (CI/CD).
Strong Communication Skills
Above all, the software architect has strong communication skills and solid business sense. They need to be at ease with business customers as well as their technical peers. An architect can explain technical concepts in terms business customers can readily understand, then turn around and “geek out” with the development team to talk about technical issues. They have a solid understanding of the business domain that their team’s product supports. Through discussions, meetings and conversations with business customers they come to understand the problems their customers are trying to solve. This helps establish the context that the development team serves.
Part of those strong communications skills is negotiating. The world isn’t perfect; the architect can find themselves in a situation where there are competing priorities among various groups in the organizations. A skilled architect can find common ground with all these groups and arrive at an optimal solution. It may not the perfect one they had in mind, nevertheless it is agreeable to everyone.
I have also met some very skilled software architects who came into the role from job functions other than software development, such as systems analysis. They’ve acquired a decent amount of technical expertise in their career, typically by way of development roles they had prior to their current role.
What Does a Software Architect Do?
A software architect works with the development team to design and build a software product, and provides technical leadership to the team. Using their broad technical knowledge, the architect works with the team to design an architecture that fulfills the stated business requirements. They mentor team members, teach them the intricacies of the frameworks of the technology stack, perform code reviews, and develop reference implementations. They ensure the architecture meets the characteristics that are important to the business, such as scaleability, performance, security, reliability, etc. Over time, an architect guides the team as they evolve the product in response to the inevitable enhancements and bug fixes. They ensure the product continues to meet the stated business requirements and architecture characteristics.
Business customers look to the software architect for technical guidance. Our architect comes to the conversation with a combination of a solid understanding of the business domain and broad technical knowledge. They are able to evaluate the available technologies to meet the needs of the business.
Keep On Coding
A software architect still develops software. I mentioned earlier that a software architect usually comes from a senior developer role. That doesn’t mean they stop coding. The discipline of software architecture along with the tools and frameworks in the software development space evolve at a breakneck pace. Our architect needs to do some coding so they maintain an understanding of the evolving capabilities and limitations of the underlying technology stack they are architecting. If they can spend 30% of their time coding, that’s good. Neal Ford of ThoughtWorks said it well at a conference I attended: “When a software architect stops coding, they become irrelevant after three months”.
It’s a Team Effort
Architects don’t work alone, they work collaboratively with the team. During the design process they facilitate discussions and workshops with the analysts, product owner and the development team to figure out the optimal architecture of what the team is to build. A skilled architect evaluates not just the shiny benefits, but also the drawbacks of the many options available to the team. Ultimately the decision they make is a set of trade-offs between these benefits and drawbacks.
This is not to say a software architect replaces the role of business or systems analysts; those people have a critical role to play. Rather, the architect complements those roles as a trusted advisor and mentor.
Delegation and Time Management
An architect needs to be good at delegation and time management. Given a chance to use a framework or tool in a new or unique way, the temptation to dive in and begin coding can be great. But with the higher demands on an architect’s time in meetings and ad-hoc conversations, often it is better to delegate the work to a developer. In fact, pair up with the developer to get them started, then mentor them going forward to ensure they are achieving the desired results.
And yes, an architect is involved in many more meetings than when they were a developer. Back when they were a developer, time was largely managed for them in terms of work items in their queue. But now the added freedom means time management is even more important. Blocking out time in their calendar as “Busy” to work on a presentation, and declining meetings in favour of reviewing the meeting minutes are effective tactics to manage time.
The Evolution of a Software Architect
The role of a software architect has seen big changes in the past 10 to 15 years. Back then, it was a common joke that the preferred programming language of an architect was PowerPoint. Architects were known to produce reams of slide decks and highly abstracted architecture diagrams and documents. The architect would throw these over the wall to the development teams, who were left to figure them out. The few feedback mechanisms that existed revealed the architects, by and large, lacked or lost the technical understanding of the capabilities and limitations of the underlying technology stack the team was working with. It was as though architects lived in an ivory tower.
Architects used to think they no longer needed to code because they were busy making important decisions. In fact, Joel Spolsky, founder of Fog Creek Software, coined the term architecture astronaut. This referred to how architects used to think at such high levels of abstraction that they bore little relevance to the real world.
Nowadays there is a need to think about the operational aspects of the product. How are we going to run it? What is the support model? How does it fit in to the organizations ecosystem? How will it evolve?. All this, coupled with the need for soft skills makes the role of a software architect much more relevant today than in days gone by. For example, our architect needs negotiation and persuasion skills to refactor the product, or to convince business customers that this technology is better than that one.
Technical Knowledge That is Broad and Deep
A software architect coming from a senior developer role now finds themselves needing to know more about other tools, frameworks, languages, etc. As a developer they have deep expertise in one particular area such as the nuances of a particular programming language. It’s unreasonable to expect they can develop that same depth of knowledge in infrastructure, networking, operational management, disaster recovery, microservices, and the multitude of other specializations and frameworks. It’s just too much to keep in one’s head. Rather, it is better to develop T-shaped knowledge that is broad and shallow, yet deep in one or two areas. In other words, develop a working understanding of those other areas so you can recognize when they apply or become important to your team. At the same time, continue to hone your craft in the one or two areas of specialization that brought you to this role.
To the Future
A software architect will continue to be a vital contributor to the success of a software product. Their broad and deep technical knowledge, and their mentoring skills, coupled with effective soft skills are a huge benefit to the team and the organization as a whole.
Is it a worthwhile career choice? That is an individual and personal decision. If you love making a difference, if you love helping an organization succeed, if you feel a sense of gratitude and humility after a design session where your team came up with so many good ideas you never thought of, if you feel a sense of pride when you’ve helped someone’s career in a big way, if you love seeing how technology can move the needle for an organization, then software architecture may be a good choice.
Me, I wouldn’t trade it for anything.
