Software Architect: what does it mean?

I just read an interesting article about the role of the Software Architect and how it will develop in the future. That is specially interesting cause it would be nice to be able, one day, to feel ready to be a good Software Architect. But there are a lot of different capabilities to stick all together, and obviously (and unfortunately) they are not only coming from the technical side.

(link to the full pdf, from
“The Software Architect”
Communications of the ACM, May 2007

(by By Matthew R. McBride)

Matthew McBride, the director of software development for Countrywide Financial Corporation as well as an adjunct professor of computer science at SMU, weighs in with his vision for the future development of the software architect position. The role of the software architect, explains McBride, is currently plagued by a lack of understanding about what exactly the software architect does and how he or she adds value to the software development process. Drawing on his experiences from implementing different types of software development projects, McBride describes the key skills and abilities of the successful software architect.

As a starting point, the software architect must be able to reduce the complexity of both the problem and the potential software solution. As a rule of thumb, every 25% increase in problem complexity results in a corresponding 100% increase in the complexity of the software solution. They must also be able to manage functional requirements and communicate effectively with stakeholders. In addition, the architect must act as a translator during software construction so each stakeholder stays involved and consistently supports the proposed software solution.

The software architect must also embrace leadership opportunities as often as possible. After all, the architect is the author of the solution and is accountable for the success or failure of the effort. For an architect, leadership includes the ability to provide system-level design and technical direction, work with a variety of teams and individuals, and recognize when and how to make decisions that guide the team to a successful solution. Along the way, the software architect needs to pay attention to nonfunctional requirements. Effective software architects also must acquire a set of tricks and tools that are largely experience-based to help them make decisions on a day-to-day basis. Such tools might include patterns and idioms, frameworks and best practices. (continue…)


if you want to read more here is the link to the full PDF (find it out attached to this post as well, as thesoftwarearchitect.pdf)