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.

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.

Architectural Viewpoint Summary

The following summarizes the architectural viewpoints described in later  chapters. These viewpoints are built by applying the various UML diagram  types to specific architecture development tasks. Each viewpoint has specific  modeling goals and stakeholders. Additionally, we have used the IEEE 1471  framework to describe the rationale for each of the viewpoints. These descriptions  should assist those attempting to apply these viewpoints. Appendix A  provides a detailed summary of these viewpoints.
The viewpoints in Table 1.1 provide a set of highly abstracted software  descriptions. The ContextView provides a summary of the system boundary and  the external entities that interact with the system. The analysis views provide an  abstract set of entities focusedonmodelingtheproblemrather than the solution.

Table 1.1 Conceptual and analysis viewpoint summary
Viewpoint                     UML diagram        type
Analysis Focused          Class                   Describe system entities in  response to a scenario. Often
referred to as a view of  participating classes or VOPC.
Analysis Interaction     Interaction            Interaction diagram between  objects for analysis.
Analysis Overall           Class                    Combination of all classes  from all focused analysis  viewpoints.
Context Use                Case                      Show the external system actors and the system under design.

Table 1.2 describes a set of viewpoints targeted at describing the software  design. The Component, Component Interaction, and Component State Views  provide a mapping of the logical runtime structures, their functionality, and their  intercommunications.The Subsystem Interface Dependency View provides a visualization of subsystem dependencies and interfaces. The Layered Subsystem  View provides a highly abstracted view of all the subsystems. Finally, the Logical  DataView provides a description of data models shared between components.

Table 1.2 Logical design viewpoints

Viewpoint UML  diagram                type              Description
Component                                 Component        Illustrate component  communications.
Component
Interaction                                  Interaction         Interactions among components.

Component State                        State/Activity    State transition/activity diagram for a component or for a     set of components.
Layered                                      Subsystem          Package Illustrate layering and subsystems  design.
Logical Data                              Class                  Show critical data views used for  integration.
Subsystem Interface
Dependency                               Class                  Illustrate subsystem dependencies  and interfaces.

The final set of viewpoints (Table 1.3) is focused on the environment and  physical aspects of the software, such as database deployment, that can impact  architectural qualities of the system. The Deployment View shows the mapping  of hardware and software for distributed systems. The Physical Database  View illustrates the physical deployment structures of databases. The Process  View shows the execution threads of the system and often the mapping to  components. The Process State View shows the dynamic states for a process.

Table 1.3 Environment/Physical viewpoint summary
Viewpoint UML diagram           type                      Description
Deployment                             Deployment         Mapping of software to hardware for  distributed systems.
Physical Data                           Deployment         Physical view of a particular database.
Process                                    Deployment         Show the processes of a particular  system instance.
Process State                           State                    Show the dynamic states of a process.

Often, overall views of large software systems become overwhelming.  An overall view usually requires architecture-size paper to print, which  necessarily limits distribution and use. As a result, we sometimes describe a  single viewpoint that covers both a ‘focused’ and ‘overall’ variation of a view.  In these cases, a series of focused views is often developed as the basis for an  overall view. However, if the stakeholders and intent of the focused and  overall perspectives are different a new viewpoint is created. The idea of  focusing a view is critical to enabling development of large systems. In  Chapter 5, in the discussion of managing model complexity, we describe the  focusing principles that underlie the derivation of many of these   viewpoints.  Specific projects might create other viewpoints using these principles.

Frequently several views will be used together. For example, in the design of  components and interfaces it is common to create a Component View, a  Component Interaction View, and a Component State View. A series of  interaction views is then used to elaborate the details of the Component View  and validate the component structure. The state view describes the overall  dynamics of a collection of components without showing the details of the  sequencing of operations.

Why Architect?

It has become standard practice in the software industry to engage in a process of software analysis and design along with coding. This design facilitates  understanding the structure of the developed software. Architecting simply  recognizes the need to focus on the bigger picture of the software design and  to provide guidance to the development team designers. At the software  architecture level, we’re more interested in the subsystems, components, and  interfaces than in the classes and methods.

According to Hofmeister, software architecture:
aspects for others, but to expose them so that the architect can reason provides a design plan – a blueprint of the system, and that it is an abstraction to help manage the complexity of the system. . . . The  purpose of the software architecture is not only to describe the important about the design.

As described earlier in this chapter, the software architecture is a place to capture early design decisions, provide constraints on the lower-level design  and implementation, and provide the organizational structure for the development  team. Getting the architecture defined well up front saves a great deal of  pain and trouble throughout the development process. The goal is that a welldefined  architecture will produce a system that will be easier to design,  develop, and maintain.
A good architectural representation (sometimes any meaningful architectural  representation) is often missing completely from projects that have been under  development for some time. Often the role of the software architect is to capture  the existing architecture, then make recommendations for improvements for
future releases. We have been in this position, and it can be quite frustrating.
Major design changes may be required to repair the damage from the lack of a  software architecture, but convincing management to make these changes may  be an impossible task. Our hope is that the emphasis on good software  architecture practices will allow the software architect to get the architecture  right up front. In this way, the architect will not be the victim of a bad  architecture and can avoid playing catch-up to try to fix a bad architecture.

Here is a list of some of the uses for the software architecture description:

Training is essential for new team members. Anyone who has been assigned to an existing software project can appreciate the need for a well-documented  software architecture to quickly bring developers up to speed. In addition, this  information can be used to train customers, managers, testers, and operations  personnel for the software system. New architects will likely need to be  trained since most teams do not stay the same over the full life of a system.
Making modifications to the system must be done carefully so existing  functionality is not broken. A common maintenance need is to describe the  impact or scope of a change and hence the regression testing required to  ensure correctness of the change. This process should start with a careful  analysis of the existing software architecture, which includes the static and  dynamic aspects of the system.
Testers need to understand the system and its interfaces, at both the subsystem  level and the component level, to perform white box testing. In addition, key  process interactions are captured in the architecture views. Finally, each interface should have associated performance information that can be verified
by the test organization.
Ensuring architectural attributes such as testability, reliability, availability,  maintainability, and performance is another important use of the architectural  description. To reason about these attributes of software, there is a need to  explore and document these attributes of the software structure.
Verification of requirements – Architectural modeling will often expose  missing, invalid, or inconsistent requirements.

Project management – When the architecture moves beyond the preliminary  state, project managers can use the information to structure the development  organizations and identify work to be performed by specific development  teams. Project managers can use the architecture to identify interface elements  to be negotiated among the development teams. This can be useful when  contract or project negotiations need to take place to reduce functionality or  move functionality to a later build.
Operating a system – Large systems such as telephone switches that support  24 × 7 operations often require human operators to run and interact with the  system. Some of these may be users, but others will perform system administration  functions. The operations staff often needs an understanding of the
software structure to perform their job.