What Software Architects Do That Programmers DON'T

Key Points:

• Avoid being pushed into coding roles to remain focused as an architect.
• Zoom in and out to balance detail and overarching design.
• Understand trade-offs in technology selection to make informed decisions.
• Embrace change and be adaptable in architectural choices.
• Communicate effectively with diverse audiences to convey important decisions.

It's really important if you're going to be an effective software architect that you don't let the company you work for push you into being the lead developer on projects or just pitching in anywhere people need help. Because if you get sucked into writing code for just any old application or any old feature, then you don't have time to really be an architect.

Ever wondered what makes a great software architect? Or how do I get promoted to be one? Well over 20 years ago, at 23 years old, I was promoted to be a software architect and I messed up pretty bad back then, but I'd like to think I've learned quite a few things in the 20 years since.

So here are 10 aspects of the job of being a software architect that if you do them, I think will not only help you increase the chance that you'll get the job, but actually do it really well.

The first thing that many software architects are really good at is what I call zooming in and zooming out. I had a manager at my first job right out of college, and after a couple years of working for him, he saw something in me that told him that I might make a really good software architect. And once he helped me get the promotion, one of the things he told me that really sets people apart as a software architect is being able to look really detailed and deep at the code you're looking at, knowing every single detail of what you're dealing with and not glossing over things. But then when you need to, coming way back up and making sure you look at the big picture of what you're doing and not getting bogged down in the details.

You'll find many programmers fall into one or the other camp. You'll find programmers that are really good at understanding all the most detailed and difficult parts of some aspect of the code and others that are really big picture and can really think about the overall solution or architecture as a whole. But to be a really great architect, you need to be able to know how to do both and when the best time is to do it.

The second thing that makes a really great architect is caring about the domain. Now this doesn't just mean domain driven design. You've probably heard of that really famous book from Eric Evans. This actually means caring about the business that you work in and understanding its problem domains.

So for example, if you worked like for a company that does shipping, understanding all that you can about how that company looks at shipping, what are all the different other business systems at that company, and actually really doing a good job of trying to figure out how to represent this problem domain in the software in the best way possible.

The third thing software architects are really good at that sets them apart from your average programmer is their masters at understanding trade-offs. What I mean by this is when you go to select a technology or figure out how to do some deployment aspect of your code, or you're picking an API of some sort, there's often a lot of positives and negatives.

Some of the less experienced developers I've worked with will see some really positive aspects of the code, but they won't look at everything else that's going to be impacted if they choose that technology. And so knowing how to look at all the variables that come into consideration—training, costs, ease of use, configurability, complexity—is crucial.

When you go to make a decision about software, technology decisions and patterns and architecture is one of the biggest things that'll set you apart if you really want to consider becoming a software architect.

The fourth thing that I think really great software architects do that sets them apart from, let's say, a tech lead or a lead software developer is humility about gathering technology decisions. What I mean by this is some of the people who I've worked with who are not maybe the best choice for being a software architect will go out and find technologies that they really want to work on.

They'll go out and find solutions and patterns and frameworks that they are really excited about working with, but they don't put enough consideration into the rest of the team and the rest of the company. So a really great software architect, when they go to make decisions about technology investments, they know how to talk to all their team members and they know the history and preferences of their team members.

The fifth thing that makes a really great software architect is they embrace change. They know that the decisions they're going to make about technology and the patterns they choose are not necessarily going to stay fixed or work for the entire lifetime of the project. So they put just enough planning in upfront to put some good architecture in place.

But they're really realistic in thinking about the fact that once the team or whoever they're handing that architecture off to, to sort of get started with, begins to use it, there's a really high likelihood that the decisions they made aren't going to solve every problem and they're not going to be suitable for every use case.

The sixth thing that makes someone a really strong candidate for an excellent architect is their masters of communication. They know how to use diagrams to effectively convey both details or high level things about the software that they're building.

But they also know how to talk to a lot of different audiences—the business people, support people, developers, the CTO, and executives. They know how to communicate the architecture decisions in a way that helps each of those different types of people really understand what's important to them and not get bogged down in all the details that might not even be related to what's important for them to support the architecture.

The seventh thing that a really strong architect knows how to do is to be aware of the infrastructure. They know that when you choose technology to use, eventually it's gonna run in a production environment.

It's gonna have real users hitting that software, exercising it, and using it. And they don't think about last whether the technology they picked is going to perform well. They actually consider that at the very beginning.

So a really strong architect is usually very interested in DevOps technologies, cloud architecture, and whatever kind of hardware or software infrastructures needed to run the application. And it's one of the biggest things I see when a programmer does not care too much about that.

The eighth thing that a really strong software architect will do is they're very strategic coders. Now what I mean by that is they don't just write software for any given piece of code that a team or a company needs. They actually protect their time and they make sure they don't get sucked into working on features.

They're always working on architectural code. On some of the projects I've worked on as an architect, I'd often come up with patterns or initial code, and give them to a team. But it's really important if you're going to be an effective software architect that you don't let the company you work for push you into being the lead developer on projects or just pitching in anywhere people need help.

The ninth thing a great software architect does is they consider the scale of the application or the services they are designing. If you're working at a company and they're going to have at most a thousand users, really sophisticated cloud architectures are actually going to cost that company a lot of money for the return on investment.

At the same time, if you're working at a company where they're going to have millions of users, making decisions that don't meet the performance needs of the application is going to get you in just as much trouble.

So whether you're choosing how your app's going to be tested, you're choosing monitoring platforms, or how to integrate various libraries, I've tried to get better at gathering data from existing business systems to understand the true scale we expect for the application.

And the tenth and final thing that really great software architects do is they're sensitive to costs. Every architectural decision you make has implications for cost. Depending on how hard it is to troubleshoot, they may have to pay support engineers more money to support the product.

So really great architects will be realistic about how every technology decision comes with a cost.

Do you agree or disagree with this list of what I think is important to be a really great software architect? What are some of the things about being a great software architect that I haven't mentioned? Leave me some comments and let me know about it until next time. Thanks.