The Software Architect

For much of my career I’ve played the architect role on various software projects, whether that’s product development, consulting gigs, or in-house web apps. I’ve always tried to make a positive impact when I’m in that role, but something that’s always bothered me is the sometimes-negative-stigma about architects.

Many people look at “architects” as just that – architects with air quotes. The perception is that they don’t do actual work. That they’re only good at Visio and PowerPoint. That they sit in an ivory tower. That they exist just in title. That they don’t add any value.

Whatever the reason, many people have been burned by so-called architects and are left with a bad taste in their mouth. But that’s not been my experience; I’ve worked with some really great ones that played huge parts in the success of projects.

Of course, there are many types of architects. Application architects, system architects, technical architects, solution architects, mobile architects, network architects, and infrastructure architects, to name several. Since I’m referring to software in general, let’s use the term software architect for the rest of this post.

The Role Described

First let me start by describing my version of the role of software architect. This is someone who typically oversees the technical direction of whatever it is they are working on. They are responsible for leading the design and implementation of said work, and spend a lot of time ensuring the right people stay on course for how the work gets delivered.

This person is most likely part of a development team, but isn’t necessarily on the hook for delivering user features (code they write is for different purposes, talked about in more detail below). In addition to the dev team, they spend a lot of time talking to project managers, business analysts, subject matter experts, and executives to understand broader business needs.

So with that, allow me to share a few things I’ve learned over the years about what it takes to be a good software architect.

Effectively Communicate

The number one thing that a software architect does isn’t technology related – it’s communication. The really good architects are great communicators first, everything else second. Being an effective communicator is a software architect’s most important trait.

There are three types of communication a software architect must be good at: verbal, written, and visual.

Verbal

For verbal communication, an architect must be able to clearly articulate thoughts and meaning. Whether it’s in meetings, hallway conversations, or whiteboard sessions, an architect should be able to convey the why/what/when/where/how, and do so without ambiguity.

Written

Simply put, when it comes to written communication, a software architect must be able to write well. They don’t need to be an English Literature major, but they should be able to write above a 1st grade level. This applies to any place writing occurs – documentation, wikis, chat windows, and especially emails.

Visual

Visual communication is critical because many people struggle with visualizing concepts in their own head. The act of drawing something helps people better understand the verbal and written communication of the same concept. Whiteboard and paper sketches go a long way, but so do tools like Balsamiq and yes, Visio and PowerPoint.

Know Thy Audience

In addition to being great communicators, good software architects tailor their communication based on audience. This is something many technically-savvy people, not just architects, fail to grasp. I’ve seen it time and time again where an architect is being asked about something from upper management and they immediately go too deep to effectively get their message across.

Good architects know that communication, in any form, they have with the dev team is almost always going to be different from how they communicate with VPs and C-Level executives. And the best architects are able to seamlessly transition between the different levels.

Collaborate

Being able to work well with others applies in all facets of life, and a software architect is no different. Rarely does the best design and implementation come from a single person, so collaboration with the team is another critical skill a good software architect employs.

The benefits of good collaboration are many: it ensures the team is involved, gives them a voice, helps them feel ownership, and creates an environment for open discussion.

The best architects seek out collaboration and take the initiative to get other people involved. Not only do they understand that other people have good ideas too, but also that they cannot do it all by themselves.

You Work for Them

Here’s something I think most people will be surprised about: contrary to popular belief, as a software architect, developers do not work for you – you work for them. I’m not talking about people reporting to an architect in a manager-employee relationship. I’m referring to the fact that most of the work an architect does is to make the developers jobs easier.

This is an approach that many software architects fail to realize. Developers do not exist to do the architect’s bidding. An architect might help set the technical direction, but developers are not the architect’s lackey.

Based on upcoming business needs, an architect might do some research into a new piece of technology or how something needs designed and implemented. This allows an architect to get in front of the dev team and lay the groundwork for upcoming tasks. The best architects balance this kind of “future work” with feedback from developers on current issues so that they can help make constant adjustments where necessary.

Write Code

I think much of the negativity towards bad software architects is related to them being Astronaut Architects. Joel Spolsky’s seminal post is now 14 years old (!), but still applicable because unfortunately these “architects” continue to exist. There is almost no perceived value in non-coding architects, and as an architect, it’s very hard to gain respect in a technical leadership role if you can’t/don’t/won’t code.

Simply put, the best architects write code. However, it’s most likely not the same code developers write. Meaning, the dev team is usually writing code to implement specific features and pieces of functionality that an end user will use.

Architects, on the other hand, tend to write code that *supports* the code the developers are writing. Think of it as all the behind-the-scenes code (infrastructure, frameworks, cross-cutting concerns, those sorts of things). They also write code that sets patterns for the team to follow, part of that whole laying-the-groundwork approach.

Read Code

In addition to writing code, good software architects spend a lot of time reading code. This may seem obvious, but I think it’s an underrated trait for architects.

Good architects should be doing code reviews, formal or informal, and provide constructive feedback for improvement. This helps ensure everyone stays on course and identifies potential technical debt.

Reading code also allows software architects to mentally construct an application so that they can better see patterns and ways to improve the codebase. Good architects do this as a way to understand and communicate the bigger picture.

Be a Leader

It’s kind of the point that architects are in a technical leadership role, but as a leader it’s really the people aspect that’s most important. Management looks to architects to help decide what they should do, and developers look to architects for help on how they should do it.

Great architects are natural leaders, both in terms of technical expertise and the people side of things, which ultimately comes back to communication and collaboration.

Mentor and Grow People

Part of the leadership that architects have is being a mentor, which allows them to have a direct impact on the growth of other people. Developers have their own aspirations and good software architects enable others to grow in their profession.

One of the best ways for an architect to do this is to simply share as much knowledge as they can, whether it’s about their own experiences or more technically-related, job-specific things.

I can tell you from my own career that seeing someone grow and knowing I had a part in it is incredibly rewarding.

Balance Short-Term and Long-Term

Often times architects get too bogged down with trying to create the perfect technical solution. This leads to over-thinking, over-engineering, and over-complicating things that could otherwise not only be simpler, but released into customers hands. The best software architects have a vision for an end-state, but understand that sometimes concessions must be made in order to get there.

Architects must constantly strike a balance between short-term and long-term goals, and be able to live with the decisions they might not have otherwise made given schedules, budget constraints, revenue goals, etc.

The side effect of this takes the form of technical debt, but that doesn’t have to be a bad thing. Technical debt exists in all software, and good architects keep a running list so that it can be prioritized and worked as time goes on.

Read and Research

More than ever, technology changes at a breakneck pace, and it’s nearly impossible to stay up-to-date on every new language, framework, library, and toolset that shows up on a day-to-day basis. Most software architects understand and accept this, and while they can’t be an expert in all things, good architects have a knack for at least *being aware* of new and shiny things.

What it really comes down to is an appetite for learning. Good architects are constantly reading, playing with code, and developing proof-of-concepts. They want to understand why and how something works because it helps them design and communicate better. Constant learning is a key trait of the best architects.

Summary

To sum it all up, here’s the TLDR version:

Effectively Communicate
Being an effective communicator is a software architect’s most important trait

Know Thy Audience
Good software architects tailor their communication based on audience

Collaborate
The best architects seek out collaboration and take the initiative to get other people involved

You Work for Them
Most of the work an architect does is to make the developers jobs easier

Write Code
Simply put, the best architects write code

Read Code
Good software architects spend a lot of time reading code

Be a Leader
As a leader it’s really the people aspect that’s most important

Mentor and Grow People
Good software architects enable others to grow in their profession

Balance Short-Term and Long-Term
The best software architects have a vision for an end-state, but understand that sometimes concessions must be made in order to get there

Read and Research
Constant learning is a key trait of the best architects

I’m pretty passionate about building software, and I’m a firm believer that the best architects are worth their weight in gold. Hopefully this post sheds light on the fact that there *are* good software architects out there and these are many of the traits they will have.

As always, I’d love to get your thoughts in the comments.

Props

A big note of thanks to Nate Kohari and Jeremy Miller for providing feedback on the content of this post.

Featured Image: Some rights reserved by Refractious

3 comments

  1. Jay Wren says:

    These same bullet points and description are what it takes to be a good software engineer. What makes the a-word different?

    • Hey Jay – Yea, I mean, these points can be made for many titles and roles. And there are many people who loathe the “architect” title, and I get that. But to me an architect plays at a bit higher level than “engineer” or “developer”.

Leave a Reply

Your email address will not be published. Required fields are marked *