The software architecture role is about coding, coaching, and collaboration

The image that many people have of software architects is of traditional "ivory tower" software architects dictating instructions to an unsuspecting development team. It doesn't need to be like this though, and many modern software architects instead prefer an approach that favours coding, coaching, and collaboration.

Coding

Should software architects write code? In my ideal view, yes, software architects should write code. Somebody once told me that the key characteristic of a good architect is the ability to think in an abstract way. You can also think of it as the ability to not get caught up in the details all of the time. And that's fine, but those abstract boxes and lines you're drawing on the whiteboard do need to be coded at some point. It's also easy for people to lose touch with technology given how quickly it changes. As a software architect, it definitely makes sense to keep your technical skills up to date, and coding is a great way to do this. Most of the best software architects I know have a software development background, and they still enjoy writing code. For some reason though, even now, many organisations don't see coding as a part of the software architecture role.

My recommendation is to make coding an explicit part of your role as a software architect, and you can do this by being an integral part of the software development team. In other words, you have a "software architecture hat" and a "coding hat". You don't need to be the best coder on the team, but the benefits of being hands-on and engaged in the delivery process are huge. After all, there's a substantial difference between knowing about something and doing it.

Appreciating that you're going to be contributing to the coding activities often provides enough incentive to ensure that your designs are grounded in reality too. Coding provides a way for the architect(s) to share the software development experience with the rest of the team, which in turn helps them better understand how the architecture is viewed from a development perspective - good or bad! It also allows you to keep "a pulse on the code", helping you ascertain whether the team is actively following the architectural principles, or ignoring them. Contributing to the coding activities helps you build rapport with the rest of the team, which in turn helps to reduce the gap between architects and developers that you see on many software teams. This quote from Agile Coaching, by Rachel Davies and Liz Sedley, highlights a common consequence of this gap in the software industry:

If you know how to program, it’s often tempting to make suggestions about how developers should write the code. Be careful, because you may be wasting your time - developers are likely to ignore your coding experience if you’re not programming on the project. They may also think that you’re overstepping your role and interfering in how they do their job, so give such advice sparingly.

Of course, there are situations where it's not practical to be involved at the code level. Being a "hands-on software architect" doesn't necessarily mean that you need to get involved in the day-to-day coding tasks all of the time, but it does mean that you're continuously engaged in the delivery, actively helping to lead and shape it. Also, a large project/product generally means a bigger "big picture" to take care of, which implies more technical leadership, and there may be times when you just don't have the time for coding. And some organisations need different levels of architects too. But, generally speaking, a software architect who codes is a more effective and happier architect.

Coaching

Coaching and mentoring is an overlooked activity on many software development teams, with many team members not getting the support that they need. This is especially true when teams are trying to move too fast, perhaps because of time/budgetary constraints. While technical leadership is about guiding the team as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people's skills, and to help them improve their own careers. Sometimes this assistance is of a technical nature, and sometimes it's more about other skills.

The people undertaking the software architecture role have a duty to help out with the coaching and mentoring. Why? Most software architects that I know have got to where they are because they have a great deal of experience, and they are usually more than capable of sharing some of this experience to help other people out. An apprenticeship model is how the master builders of times past kept their craft alive, and we should consider doing the same.

The sad thing about our industry is that many developers are forced into non-technical management positions in order to "progress" their careers up the corporate ladder. Ironically, it's often the best and most senior technical people who are forced away, robbing software teams of their most valued technical leads and architects; exactly the sort of people who are capable of mentoring. Filling this gap tomorrow are the developers of today. In some cases, teams have already lost their most senior technical people, adding more work to the remainder of the team who are already struggling to balance all of the usual environmental constraints, along with the pressures introduced by whatever is currently fashionable in the IT industry (e.g. microservices!).

Collaboration

The software architecture role doesn’t necessarily need to be undertaken by a single person. This is often a good place to start, but the role can be a collaborative effort that is shared between a number of people. And this makes sense too. Most software architects/developers are specialists in a small number of technologies; perhaps server-side Java, or client-side JavaScript/HTML/CSS, or databases. Electing one person to provide technical leadership across such a wide variety of technologies (which is what you find on most projects/products) is hard, and often unfeasible. A better approach might be to find your experts, and have them collaborate to collectively perform the software architecture role, and provide technical leadership.

A word of caution, though. Be wary of advice stating that "everybody should be an architect", and that collaborative technical leadership is easy. It's not, and soft skills are hard. I regularly run software architecture katas where groups of 2-5 people are asked to design a software system, with everybody collaborating on the exercise. I've witnessed some of these groups being unable to reach consensus on decisions relating to design and technology choices. In extreme cases, groups have split because of ego and personality conflicts!

Summary

I like to think that modern software architects (or "Tech Leads", if you use that term) should be "master builders"; who value coding, coaching, and collaboration. It's easier to lead a team if you're seen to be a part of that team. The key is to understand the team you have, and then make sure you apply the appropriate quantity and style of technical leadership.