Traps and Pitfalls Associated with the Role of Software Architect

Many organizational issues can have a significant impact on the ability of the software architect to function effectively. As much as possible, the architect should focus on the definition of an effective architecture that meets the requirements. Distractions caused by a poorly defined or misaligned development organization can detract from this focus. A few of these issues and their

potential remedies are discussed below.

Clear definition of leadership

Description: In the organization, the definition of clear leads is critical in many key areas. These include software systems engineering, development leads, test leads, and potentially the software architect or chief software engineer. Often, especially if there are two diverse geographical development centers, management will create two or more co-leads with equal roles and responsibilities.

The degenerate case of this is the ‘self-managed team.’ This is a clear sign of trouble on the horizon, as these two leads will seldom be able to act as one and an inevitable set of conflicts will occur.

Remedy: Encourage management to establish a clear leader and offer an equitable solution. For example, the lead of one type of team (for example, the test team) could be established at one site and the lead of another team (for example, the process team) at another site. Another approach we have seen to be successful is to clearly define the roles and responsibilities of the two individuals so that there is no overlap and to have a common manager or technical leader that arbitrates conflicts. Of course, this approach works best when the two individuals are located at the same site and can easily coordinate with one another.

Reporting structure for the software architect

Description: The software architect should report directly to the overall software development manager. Any attempt to create a software architect from one of the lower level technical leads and leave that lead reporting to the same manager will fail. In order to garner the respect required for the job of software architect and to effect change and arbitrate management disagreements, the reporting level of the software architect must be at the appropriate level. In addition, a software architect reporting to a manager at too high a level is often seen as an outsider by the entire development organization.

Remedy: Key individuals should usually report to the top-level software development manager. These individuals include the software architect, chief software engineer, software systems engineering lead, and data architect. The network architect and hardware architect often report to a project hardware management lead. An example of an organization chart based on this approach is shown in Figure 1. The key technical positions are shown as staff positions reporting to a manager. Another approach we have seen to be effective is to have all these key technical individuals, with the exception of the subsystem technical leads, report to the chief engineer.

Figure 1. Organization chart example

Geographical location of software architect and technical leads

Description: In geographically distributed development organizations, the software architect must either be located with the majority of the development leads, or plan on commuting frequently to the other site in order to communicate with these leads.

Remedy: The technical focus will shift early in the program to one primary site, usually the one where the top-level development manager spends most of his or her time. Select the software architect from the qualified technical leads at the site where technical focus will most likely result, or plan on having the software architect travel for a significant amount of the time.

Architecture team size and composition

Description: Managers will often try to get themselves or other non-technical individuals added to the architecture team, or convince the software architect’s manager to have them added to the team. In addition, individuals who are not technical leaders but who may consider themselves to be technical leaders may request to be added to the team.

Remedy: The software architect should closely control the size and composition of the architecture team from the start. This means that the architect should define the guidelines for the structure and composition of the team and communicate these guidelines to the project managers early in the process. The effectiveness of the software architecture team will be compromised if the team is too large or if anyone who is not one of the key technical individuals is on the team.

To prevent unreasonable requests for additions to the team, the software architect must be sure to clearly communicate to all interested individuals the minutes of the architecture team meetings, the decisions made by that team, and the architecture that is defined by the team. The software architect should keep several mailing lists to keep information flowing.

One related problem that occurs frequently is that effective individuals are often overlooked when the team is first structured and individuals might be added who are not effective. One approach for adding to the team is to start very small (3–4 key individuals) and then determine if others have emerged as technical leaders in the organization. Removing people from the team is very difficult, so the initial selection must be done carefully.

Software architect lifecycle participation

Description: The software architect is frequently moved on to the next project in advance of the final delivery of the system. This may be due to the perception that the software architecture task ends before the final build or due to the needs of the new project. This should be avoided, as the architect will not be able to evaluate the true effectiveness of the architecture and will not learn from architecture flaws that existed in the system, but were not noticed until the end users interacted with the software over an extended period. This could potentially introduce the same flaws in the software architecture of the new system.

Remedy: The software architect should participate in the development effort, 36 Roles of the Software Architect either in the role of software architect or as the technical lead of the final software build. If the architect remains in the architecture role, this will have the added benefit of ensuring the documentation of the software architecture accurately represents the final state of the software. If the architect is filling the technical lead role, then this will result in a closer involvement with the end users and a better understanding of the weaknesses in the architecture.

Figure 1 shows an example of the relative level of effort for each workflow over a series of three example iterations. In addition, it shows some typical architecture-related artifacts that would be produced by the workflows in each iteration. In this diagram, we have shown top-level architecture development as a separate workflow from subsystem design. This sort of tailoring is often needed in RUP to deal with multiple levels of architecture and design.

Skills and Background for the Architect

A software architect should have most or all of the following skills, background, and attributes.

Extensive software design and development experience is required to create an effective overall design, and the software architect must understand and explain how this will map to the implementation. In order to do this, the software architect should have significant development experience. Technical leadership is key to making timely and effective decisions. The management and development leads need to be convinced the decisions being made by the software architect are good ones, based on current information. The software architect should be a recognized technical leader and, as a result, instill this confidence in the program managers, development managers, and development leads.

Team facilitation skills are essential. The software architect should be effective in leading both the architecture team and the development teams. The architecture team usually consists of individuals with strong technical backgrounds and who often have strong opinions. The architect should be able to handle the dynamics of this team as well as be the final decision maker when there are technical disagreements.

Communication skills are vital to the job of architect. The software architect should be able to handle hundreds of emails a day, provide clear direction to the architecture team and technical leadership, and make the architecture and related issues clearly understood by both technical and nontechnical stakeholders. The software architect should also be able to clearly communicate needs and concerns related to the architecture to these stakeholders.

The architect will spend a great deal of time building consensus among technical leaders and managers. This is often required in advance of technical meetings, so the meetings will run smoothly. However, the amount of consensus building should not increase to the extent that the project stops progressing. There is an appropriate time to make a decision and move on, preparing those on the opposing side in advance, if possible.

Technical skills of the software architect should be broad, deep and up to date. In addition, based on a wide knowledge of technology, the architect should have the ability to make technology selections that can facilitate development within the project schedule, budget, and developer skill set.

Technical leaders in the development organization that try to push their own favorite technology should be dealt with carefully by the architect. In addition, the architect must avoid the tendency to select one technology and apply it to all situations. Finally, the architect needs to keep up-to-date technical skills on new software design and development technologies and should always be

researching new techniques that are more effective. Development languages, modeling techniques, and platforms continue to evolve rapidly. The architect needs to assimilate the relevant aspects of these new technologies for their applicability to the system or systems.

One facet of the architect’s technical skill set is knowledge of component communication mechanisms. In order to select the correct implementation approaches and tools, the software architect should have experience with and knowledge of several mechanisms. Examples include remote procedure call (RPC), Java Remote Method Invocation (RMI), Common Object Request

Broker Architecture (CORBA), other standards-based communication protocols, directory services, web services, and relational as well as object-oriented

databases.

In addition, knowledge of the domain is also important. The software architect must be able to develop an architecture that meets the needs of the customers and end users of the system. In order to meet these needs, the approaches and techniques applied by the end users in performing their dayto-day tasks must be clearly understood by the architect. This can frequently be achieved by spending on-site time with existing or potential customers.

There is no substitute for actual hands-on experience, or at least discussions with and observations of end users of the system under design. Good architects tend to be quick learners and keen observers because of the need to quickly acquire new domain understanding.

Finally, the software architect must possess very good abstraction skills. This is critical to the definition of views that communicate the appropriate information. Many developers will not be good software architects, as they are not able to focus at the right level of abstraction and quickly become overwhelmed by the low-level aspects of the software design and implementation.

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.