Roles of the Software Architect

This chapter will provide an understanding of the role of the software architect and how this role relates to other key roles on the development team. In addition, the skills required for the software architect, key approaches for leading the software architecture team, and traps and pitfalls associated with the software architect are discussed. In keeping with the philosophy of providing a practical guide, many of the detailed definitions and discussions are left to the recommended reading at the end of the chapter.

The importance of a good software architect should not be underestimated. There are plenty of examples of projects gone awry for lack of good leadership. Lack of someone filling the architect role is sometimes part of the story. Of course good architects can fail in a non-supportive environment. A poor architect that is out of touch, however, can quickly drive a project to ruin. The software architect should be instrumental in the development of a ‘shared vision’ for the software. What is a shared vision? At a basic level the development team must have an idea in their minds about what the final product will be, the effect the software will have, and the goals of the organization. The architecture will reflect and define a large part of the vision.

The shared vision is influenced by many factors, many of them nontechnical. However, it is in the technical aspects of the vision that the architect typically makes the largest contribution. The final architecture will necessarily balance the conflicting interests of the various stakeholders. The architect must always be prepared to communicate and interact with other team members about the overall vision. Defining and communicating this technical vision includes the following activities:

• Analysis of the problem domain

• Risk management

• Requirements management

• Interface design

• Technology roadmap management

• Determination of implementation approaches

• Definition of an architecture that meets the system requirements

• Definition of an architecture that meets goals of the organization

• Definition of an architecture that meets the project budget and schedule

• Oversight of the mapping from the architecture to the design and implementation

• Communication of the software architecture to technical and non-technical audiences

• Maintenance of the software architecture throughout the project lifecycle

Although the exact roles and responsibilities vary somewhat by project and organization, the following are typical:

Requirements tend to be a topic that consumes much of the attention of the software architect. This is because the architect is typically responsible for understanding and managing the non-functional system requirements such as maintainability, performance, testability, reusability, reliability, and availability.

In addition, the architect must often review and approve both the requirements provided by the system-level systems engineering organization and the designs produced by the development teams. The software architect participates in reviews of these development work products. Often the architect will work directly with customers, marketing, and support organizations as well on the formulation of requirements.

Technical risk assessment and management is another crucial role for the architect. The architect should use his or her experience to provide management and other stakeholders with information about the key technical risks of the proposed software. A risk reduction plan, either formal or informal, to address these risks is the responsibility of the architect. The architect needs to be capable of assessing the impact of requirements changes on the system as well as the risk of the proposed changes.

Analysis of the problem domain is an important role. This is especially true if the task is to create a product line, framework, or family of products. The architect needs to be able to dissect problems into component parts and structure solutions that can meet the needs of the organization.

Design of the overall software structure as well as critical components, interfaces, and policies is the direct responsibility of the architect. The software architect should also provide a set of design guidelines to the development team as well as input to the development of coding style guides. The software architect is the final authority on issues such as design/development style, interface negotiation and definition, and requirement modifications.

The software architect serves as a reviewer and approver of many different project deliverables. These including subsystem designs, interface definition documents, coding style guidelines, and system engineering work products. In addition to reviewing, the software architect also approves many of these documents. The software architect also reviews and approves software deliveries

and associated documentation. Examples of these associated documents should include test reports and updated design documents that accompany the delivery.

Mentoring of designers and developers is another key role. Since the software architect is an expert developer and designer it is critical to share this knowledge and experience with other team members. This can be done in a number of different ways, including developing and teaching classes, individual help sessions, and brown-bag seminars. Participating in design sessions, peer reviews, and inspections are additional mentoring techniques. An occasional programming session will also be beneficial.

Integration and test support is another important role of the software architect. This includes defect prioritization and assignment, resolution of defect issues, definition of test scenarios, and participation in test execution.

Implementation is a role that may be played by an architect on a small project. In addition, an architect may be involved in initial prototyping efforts to defer major risks. However, on large-scale projects there are simply too many highlevel issues for an architect to spend significant time in an implementation role. One caution for the architect on large-scale systems is to avoid getting

tied up in the implementation details to the point that the architecture suffers. In spite of the fact that software architects usually have a strong development background, the architect should not be personally responsible for code deliverables as this involvement may end up as a bottleneck for other developers.

Finally, team lead is another critical role played by the architect. The architect is part of the leadership team and needs to work with that team. In addition, in large projects an architect may have a supporting staff, or at a minimum an architecture team. The architect needs to lead these teams and keep them focused on addressing the most critical project risks.

The software architect is also a key liaison to project management, other technical leaders, system engineering, and developers. The architect will need to translate and interpret technical information for other team members as well as helping a team member find appropriate contacts.

These roles and responsibilities will be emphasized or de-emphasized as the project evolves. As the systems engineers begin requirements definition, the software architect will be focused on understanding the domain, preparation and review of the requirements. As requirements are becoming more defined, the focus will shift to staffing the senior technical team members, and process definition. During the development of the top-level architecture, the focus will shift to architecture definition.

As subsystem teams start design, the role of reviewer and approver will be the focus. As the software deliveries to the integration and test organization begin, the role of integration and test support may be the focus. In addition, the software architect must start the architecture definition tasks for the next increment of the software during the development of the current increment, or the architecture definition will not be complete when the next set of subsystem design activities begin.