The Software Architect Role

A simplistic view of the role is that architects create architectures, and their responsibilities encompass all that is involved in doing so. This would include articulating the architectural vision, conceptualizing and experimenting with alternative architectural approaches, creating models and component and interface specification documents, and validating the architecture against requirements and assumptions.

However, any experienced architect knows that the role involves not just these technical activities, but others that are more political and strategic in nature on the one hand, and more like those of a consultant, on the other. A sound sense of business and technical strategy is required to envision the ‘right’ architectural approach to the customer's problem set, given the business objectives of the architect's organization. Activities in this area include active listening to stakeholders values, concerns and goals, creating technology roadmaps and scanning for opportunities to differentiate, and making assertions about technology directions and determining their consequences for the technical strategy and hence architectural approach.

The architect needs to partner well with a variety of different stakeholder groups, including management at different levels, business analysts or marketing, and developers. The architect needs to balance participation (to gain insight, ensure excellence and get buy-in) with the need to create conceptual integrity and keep the architecture decision process from stalling. The more broadly scoped the architecture, the more likely it is that the architecture will be challenged on many fronts. The architect has to shed distaste for what may be considered "organizational politics," and actively work to sell the architecture to its various stakeholders, communicating extensively and working networks of influence to ensure the ongoing success of the architecture.

But "buy-in" to the architecture vision is not enough either. Anyone involved in implementing the architecture needs to understand it. Weighty architectural documents are notorious dust-gatherers. The early participation of key developers brings good ideas into the architecture process and also creates broader understanding and vested interest in its outcome. In addition, for bigger projects, it can be quite helpful to create and teach tutorials to help developers understand the architecture and the rationale for the decisions it represents. During the construction cycles, the architect needs to be available to actively consult on the application of the architecture, to explain the rationale behind architectural choices, and to make amendments to the architecture when justified. The architect also acts as mentor and coach, working with developers to address challenges that arise, especially when they have broad/systemic impact or are critical to the success of the system.