Becoming a software architect isn’t something that simply happens overnight or with a promotion. It’s a role, not a rank. It’s the result of an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role. While the term “software developer” is fairly well understood, “software architect” isn’t. Here are the things that I consider to make up the software architecture role. Notice that I said “role” here; it’s something that can be performed by a single person or shared amongst the team.
1. Architectural Drivers
The first part of the role is about understanding the business goals and managing the architectural drivers, which includes the requirements (both functional and non-functional) and the constraints of the environment. Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or quality attributes) that they need. Sometimes the stakeholders will tell us that “the system must be fast”, but that’s far too subjective.
2. Designing Software
It should come as no surprise that the process of designing software is a part of the software architecture role. This is about understanding how you’re going to solve the problems posed by the architectural drivers, creating the overall structure of the software system and a vision for the delivery. Despite how agile you to strive to be, you probably do need some time to explicitly think about how your architecture is going to solve the problems set out by the stakeholders because your software system isn’t going to do this itself
Conclusion
If you’re responsible for the software architecture and technical delivery of a software system, you must have the authority to make decisions. If you have the responsibility but not the authority, and are therefore continually seeking permission to make decisions, you could be in for a bumpy ride.
