What does being a software architect mean?
I was recently asked: "What does being a software architect mean?" Here is my answer.
I was asked this question recently. I was approached by someone who wanted to interview me for a project they are working on. They wanted to record a short clip on my thoughts about being a software architect. As preparation, they presented me with the Bob Martin quote below and a couple questions to consider. One of those questions was: What does being a software architect mean to you?
“The purpose of (software architecture) is to facilitate the development, deployment, operation, and maintenance of the software system contained within it”
Robert C. Martin
Robert C. Martin
Here are my initial thoughts in response.
Bob mentions 4 things there, I would boil it down to just 1 thing. Think about the humans involved. Software is written for, by, and with humans. All the humans involved have their own needs. Being an architect is about designing a system that balances all those needs.
Before you can design for those needs you have to understand them. I'm going to generalize a little here because the details of your specific project will vary. You'll have to do your own legwork to understand what each of these groups' needs is for your specific project, but here are some good generalizations.
The end users have a problem they are trying to solve. In general, end users want a solution to their problem that melts into the background so that they don't have to think about it. They want something robust. They don't want to worry about bugs and workarounds. Don't forget to think about everyone affected by the use of the software. You have to consider the second-order effects as well not just the fingers on the keyboard or mouse.
Then you've got the people who are paying for your work. There's always some driving force behind any piece of software and that's usually a business need. So we have the business people who have their own goals. They generally care about things like stability (keeping existing customers) and releasing new features (gaining new customers).
And lastly, you can't forget the other developers and others (testers, designers, etc) who are helping you to build your project. If you are doing anything worthwhile you are probably not doing it alone (and even if you are, you aren't immortal so someone else will have to pick it up eventually). From a developer's perspective, they want code that is easy to read, understand, modify, and test.
So as an architect how do you balance all these things? Iteratively. You go and try something and see what works. Throw out the stuff that doesn't work. Keep doing more of the stuff that does. Then try something else. If you keep doing that and keep the humans in mind at each step, that will lead you to the right technical solutions.
People think architecture is about what framework you use, how you pass data around, and other technical details. Those are important, but they are all just supporting details. They are often distractions. They don't matter unless you get the human factors right. The human factors are what will cause your project to be a success or failure. If you focus on the humans, those technical details will all sort themselves out.
Architecture is about so much more than just the technical details. It took me a long time to get to this level of understanding. We're engineers it's natural to want to focus on the technical details, but the sooner you can learn to focus on the big picture, the more successful you'll be as an architect. You'll make decisions that "facilitate the development, deployment, operation, and maintenance" of your software.
Before you can design for those needs you have to understand them. I'm going to generalize a little here because the details of your specific project will vary. You'll have to do your own legwork to understand what each of these groups' needs is for your specific project, but here are some good generalizations.
The end users have a problem they are trying to solve. In general, end users want a solution to their problem that melts into the background so that they don't have to think about it. They want something robust. They don't want to worry about bugs and workarounds. Don't forget to think about everyone affected by the use of the software. You have to consider the second-order effects as well not just the fingers on the keyboard or mouse.
Then you've got the people who are paying for your work. There's always some driving force behind any piece of software and that's usually a business need. So we have the business people who have their own goals. They generally care about things like stability (keeping existing customers) and releasing new features (gaining new customers).
And lastly, you can't forget the other developers and others (testers, designers, etc) who are helping you to build your project. If you are doing anything worthwhile you are probably not doing it alone (and even if you are, you aren't immortal so someone else will have to pick it up eventually). From a developer's perspective, they want code that is easy to read, understand, modify, and test.
So as an architect how do you balance all these things? Iteratively. You go and try something and see what works. Throw out the stuff that doesn't work. Keep doing more of the stuff that does. Then try something else. If you keep doing that and keep the humans in mind at each step, that will lead you to the right technical solutions.
People think architecture is about what framework you use, how you pass data around, and other technical details. Those are important, but they are all just supporting details. They are often distractions. They don't matter unless you get the human factors right. The human factors are what will cause your project to be a success or failure. If you focus on the humans, those technical details will all sort themselves out.
Architecture is about so much more than just the technical details. It took me a long time to get to this level of understanding. We're engineers it's natural to want to focus on the technical details, but the sooner you can learn to focus on the big picture, the more successful you'll be as an architect. You'll make decisions that "facilitate the development, deployment, operation, and maintenance" of your software.
Thoughts
What do you all think? Am I missing something? Am I off-base? What would you add or subtract? As of writing this, I haven't done the interview yet, so I am happy to entertain other ideas. Post yours in the comments.
