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.
In order to function effectively, the software architect must not become detached from the other technical leadership. This includes the chief software engineer, the software systems engineering lead, and the development team leads. The approach that works best for communication of both the top level and subsystem level of the software architecture is to create a small software architecture team made up of the key technical individuals on the development team. The size of this team should usually be limited to no more than seven individuals. If the development is geographically distributed, then a weekly meeting via network-connected meeting software and teleconference can work well. If the travel budget permits, it is good to have the software architect and a few key individuals travel to the different sites occasionally for some of the meetings. This can be done in conjunction with periodic technical interchange meetings with the development teams.
The architecture team is composed of team members, not representatives. When the team meets, the team members should be representing the best interests of the system architecture, not the individual groups they may feel the need to represent. These team members should report to project management personnel, not to the software architect. This will allow the software
architect to focus on the technical aspects of the system and not on the management tasks, such as performance reviews and other personnel management activities. However, a large project may require a small group of people that report to the software architect to support such activities as preparation of the top-level architecture document or definition/negotiation of interfaces between the software subsystems or processes.
The architecture team should take ownership of the overall software architecture and design. In addition, they are responsible for defining the design and coding guidelines. The software architecture team should be the group of individuals that makes the key design and implementation decisions.
They are responsible for making the architecture and design as effective as possible, given project constraints. In addition, both requirements and design changes to the system should be approved by this team.
The architecture team is a working group that approves all design reviews, documents, deliveries, and makes sure the software delivery and the architecture defined for that delivery are consistent. Members of this team should be invited to all key reviews. In addition, they should participate in many of the peer reviews and inspections of the design artifacts and code. Many of the members of the software architecture team will be development leads, since these are usually the senior technical members of the development team. This will also facilitate acceptance of decisions made by the team among the development team members.
It is important this team be composed only of technical design and development leads that are responsible for the software architecture, not just individuals who are interested in or who may need to review the architecture. One exception to this rule is that a technical lead from the test team is sometimes a good addition to the architecture team to ensure the testability aspects have
While project management support is important for the success of the software architecture team and managers should be used to facilitate the team activities, a manager should never lead the team nor should any managers be members of the team. These managers should not be making or guiding the technical decisions made by the software architecture team, other than to provide input on the budget and schedule aspects of architectural decisions. In order to facilitate communication, presentations should be scheduled for the sole purpose of communicating the latest architecture and related issues to the managers and other development team members. These presentations are effective communication and training sessions and will be effective in minimizing the number of requests to add interested individuals to the architecture team.
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
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.
The following roles are usually found in large-scale software development. Each role has an associated relationship with the software architect. Note that no organization will necessarily have all these roles, nor will each role be assigned to separate individuals. Often in smaller organizations, two or more of the roles can be combined and assigned to one person. In addition, there will often be more overlap of individuals focused on architecture and those focused on development in smaller projects. On large projects, these kinds of overlap will occur less frequently. The relationships between the role of software architect and other roles in the organization are described below:
Role: project management
Description: This includes the top-level project manager, and the immediate staff associated with that role. This could include program planning, subcontract management, supplier management, software estimation, release management, and operations management.
Relationship to Software Architect: The program management must understand how the software architecture maps to internal development teams, subcontracted development teams, COTS tools, hardware, network architecture, and external organizations/entities with whom the software must interface. In addition, the architect will work with project management in the definition of release content as well as prioritization of features included or omitted from a release.
Role: development team managers
Description: These are the managers for each individual development team. These may be internal or subcontracted teams. These leads may also have a small staff with whom the software architect must communicate.
Relationship to Software Architect: These development team managers should clearly understand the interfaces they provide and consume with respect to other development teams and external entities. This includes the high-level technical aspects, such as COTS tools involved in the interface, as well as the complexity involved in the development or modification of each of these interfaces. In addition, the managers should understand the key interfaces that may be a potential performance problem. Finally, the software architect will need to assist the development team managers in the addition of features or reduction of functionality.
Role: system architect/chief engineer
Description: Many organizations have a top-level technical lead responsible for the overall system design and delivery. This is frequently the case when significant hardware components are to be delivered along with software. The responsibilities associated with this role often include technical leadership of the systems engineering, software development, hardware design, network (LAN andWAN) design, and even test organizations.
Relationship to Software Architect: The software architect must communicate the overall software design to the system architect. This includes interfaces between development teams, external interfaces, requirements-related issues, and dependencies from other organizations that may impact the software development. In addition, the software architect will work closely with the chief engineer to identify and resolve significant technical issues.
Role: chief software engineer
Description: In some organizations, a role of chief software engineer (CSE) is separate from the software architect. In smaller organizations, these roles may be merged. The role of the chief software engineer is usually tied more closely to the development process than the details of the software architecture. This means the CSE should not only play a key role in the definition of the process, but should ensure the process is followed throughout the development lifecycle. The CSE works closely with the technical lead and build manager for each release.
Relationship to Software Architect: The software architect and CSE work closely together not only to make sure the delivered software meets the requirements, but also to ensure that the interface and port definitions match those defined by the software architecture team. In addition, the CSE will consult the software architect on many process definition issues, especially those related to requirements, architecture definition, and design.
Role: hardware architect
Description: The hardware architect is responsible for the selection and configuration of the hardware on which the software must execute. This requires a careful analysis of several types of requirements. These include requirements related to performance, input/output, data storage, COTS products, software sizing, and the user interface.
Relationship to Software Architect: The software architect will provide detailed information on the low-level requirements the software will levy on the hardware. These estimates will often vary widely early in the architecture definition process and less widely as the architecture becomes well understood. The hardware architect will also communicate to the software architect the restrictions that are imposed by the hardware that will be used. Often the selection of hardware is mandated by the customer or prior installations of the system and the software architect must make sure the software architecture is defined within the constraints of this hardware. In addition, the software architect must participate in the hardware selection and the specification of configuration information, making sure all key requirements are considered.
Role: network architect
Description: The network architect is responsible for defining the LAN and WAN design and configuration. In addition, the network architect must make sure the installation of the network hardware is performed to meet the network design. This role is sometimes combined with the hardware architect, primarily because knowledge of the various hardware components and how these components are interconnected are closely related.
Relationship to Software Architect: As with the hardware architect, the software architect must communicate network requirements to the network architect and participate in the selection and configuration of the network. In addition, once the network configuration is defined, the network architect must communicate the constraints implied by the network back to the software architect.
Role: technical leads of each release
Description: One effective approach we have seen is to have a manager and technical lead work together to deliver each major release of the software. Each individual can then focus on what they do best, leaving the release management tasks to the manager and the technical issues to be worked out by the technical lead. This lead is responsible for technical aspects of the interfaces, defects, building, testing, and delivery of the software. These technical leads will often participate in the definition of and modifications to the software architecture.
Relationship to Software Architect: First, the software architect must deliver a set of architecture views to the technical lead that clearly communicates the system under development and test for that release. This will enable the technical lead to quickly detect and remedy issues with the software. In addition, the software architect should work with the technical lead to change representations in the architecture that do not accurately represent the software that was delivered.
Role: data architect
Description: The systems engineering leads are responsible for delivering the system requirements that have been allocated to software, to the development organization.
Relationship to Software Architect: The software architect must review these requirements to make sure they can be developed, given the project constraints, and provide feedback to the systems engineering leads when a mismatch occurs. In addition, the software architect must communicate the software architecture to the systems engineering leads to make sure the requirements have been correctly understood and translated into the architecture.
Role: software systems engineering lead
Description: Many development organizations create a software systems engineering (SSE) group that translates and maps the requirements from the higher-level systems group into lower-level requirements, which can be assigned to individual development teams. This often means that the higher-level ‘shall statements’ which are used at the top level must be translated into use
cases and other artifacts that more clearly communicate the requirements to the software development teams. In addition, the requirements associated with each interface may also be specified by this team.
Relationship to Software Architect: The software architect should participate in many of the use case and interface definition activities with the SSE team. The preliminary software architecture will often be provided to this organization, and the resulting activities of the SSE team will evolve the software architecture as the system is better understood.
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.
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.
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.
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.
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.