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.
The many web pages and books on software architecture have provided dozens, if not hundreds, of definitions of software architecture and related terms. Given this plethora of definitions, we must settle on a set of key definitions for the purposes of communicating software architecture concepts. What follows are some key definitions required for a discussion of software architecture. Additional definitions can be found in the recommended readings located at the end of this chapter.
The Institute of Electrical and Electronic Engineers (IEEE) recently issued a recommended practice regarding Software Architecture: IEEE 1471. The definitions we provide in this book are closely aligned with IEEE 1471. These include definitions of system, stakeholder, architect, architecture, architectural views, and architectural viewpoints. IEEE 1471 defines the following key terms:
- System is a set of components that accomplishes a specific function or set
- ‘Architecture is the fundamental organization of a system embodied in its
components, their relationships to each other, and to the environment,
and the principles guiding its design and evolution’.
- Architectural Description is a set of products that document the architecture.
- Architectural View is a representation of a particular system or part of a
system from a particular perspective.
- Architectural Viewpoint is a template that describes how to create and
use an architectural view. A viewpoint includes a name, stakeholders,
concerns addressed by the viewpoint, and the modeling and analytic
The IEEE definitions are intentionally general, to cover many types of software architecture, and are not specific enough to provide detailed guidance to architects and developers of large-scale systems. As such, a large portion of the book is devoted to the description of specific architectural viewpoints, defined in the UML, which can be applied to many different largescale development projects. In addition, most of these viewpoints can also be applied to smaller development efforts. In this book, these viewpoints are illustrated as architectural views for an example system. The System Architecture is the set of entities, the properties of those entities, and relationships among them that define structure of the system. The Software
Architecture is the set of software components, subsystems, relationships, interactions, the properties of each of these elements, and the set of guiding principles that together constitute the fundamental properties and constraints of a software system or set of systems.
Software Architecting refers to the analysis, design, documentation, review, approval, and other related activities concerned with the definition and management of the software architecture. Architectural Views provide representations of the architecture that can be used to guide construction, manage, explore, train personnel, test, and perform other engineering tasks related to creation and maintenance of the software system. Some uses for views include:
- Capturing the design decisions both early on, and as enhancements are
- Capturing information about the runtime environment for the software
- Providing constraints on the lower-level design and implementation
- Architectural Description is a set of products that document the architecture.
- Architectural View is a representation of a particular system or part of a
system from a particular perspective.
- Architectural Viewpoint is a template that describes how to create and
use an architectural view. A viewpoint includes a name, stakeholders,
concerns addressed by the viewpoint, and the modeling and analytic
For each of these views there is a group of associated Stakeholders. The stakeholders may include project and program managers, development team managers and technical leads, system engineers, the test organization, and individual developers. This group of stakeholders may be building the early versions of the software, or may be making maintenance modifications to software that has existed for some time. The architectural views are used to communicate with the stakeholders and, as such, must be carefully crafted
to communicate the appropriate information at the appropriate level of detail to the set of associated stakeholders for that view. While the definition of software architecture terminology provided above is
useful, the definitions are still somewhat fuzzy since some of the terms used in the definitions are not themselves clearly defined. The following sections of this chapter will help refine and clarify these definitions. Architecting software is primarily about software design – design in the large. Thus, the focus of architecture is on the arrangement of the larger aspects of software systems such as subsystems and components rather than classes and objects. To model software systems in the large requires examining
both the static or build-time view and the dynamic or runtime behaviors of the software. Another way of thinking about software architecture is to think about some of the typical questions that can be answered by views of the architecture:
• What are the subsystems or components of the software?
• What are the responsibilities of the components?
• What are the interfaces provided/consumed by these subsystems or components?
• What subsystems or components are impacted by a change to the software?
• How much retesting is required if we change this component?
• What components are involved in installing this change?
• How are parts of the system to be physically distributed?
• How will a change impact the performance of the system?
• What development teams are impacted by a change to this interface?
• How much effort is involved in the development of this functionality?
Since the software architecture being defined is often part of an even larger system, it is often useful to concentrate on the subset of the system for which a particular architecture is being defined. Examples of this type of system subset include a set of components being developed by a particular development team
or a set of components that will be developed rather than purchased. This subset of the system can be referred to as the system under design. This means that even though only part of a larger system is being designed, any external entities can be considered external to the system under design. This approach
allows architectural definition to focus on the parts of the system that are critical and delay concerns about parts of the system which are not yet defined.
What software architecture is not
The software architecture does not include the hardware, network, or physical plant architecture. As such, the software architecture description is not intended to convey the complete description of the system, only the software within that system and any context needed to create the software. As an example, information such as hardware model number, hardware configuration information, routers, or LAN cards is not the focus in software architecture views. Other views, tables, or documents may be used to specify this type of information. However, this type of information should be included or referenced if it influences the software design. In general, the software architecture description should not duplicate information found in other sources, such as requirements documents or marketing information. Duplication causes extra rework when these other documents change. The software architecture description must be kept at the appropriate level
of detail. The team that defines the architecture must keep each view at the right level of detail and avoid showing more than one level of detail in a particular view, unless the reasons for doing so are clear and agreed upon in advance. Low-level implementation details should not be included in the software architecture description. For example, a context or subsystem view should not include details about the implementation mechanism for a particular interface. In addition, descriptions of specific implementation mechanisms such as compiler optimizations, shared versus static libraries, COTS class or method names, or file format should not be included in the software architecture views.
Attributes of software architecture
Many different attributes or qualities are of interest in software architecture. These qualities are important because they impact the design and development of many different parts of the software. Some of these qualities include:
• Cultural adaptability – support for multiple languages and cultural differences
• Security – prevent unauthorized access
• Data integrity – does not corrupt or provide bad data
• Maintainability characteristics
Portability – can software be ported to other platformss, Changeability – ability to add new functions and change existing functions, Fragility – changes to fragile software tend to break existing functions, Rigidity – software is difficult to change even in simple ways, Duplication – software with duplication strewn throughout ismore difficult to maintain because it is larger and because change is not localized, Understandability – can the software be understood so that changes can be mades Debugging support – support for multiple levels of online debugging.
• Testability – software can be tested effectively (impacts changeability)
• Usability – a measure of the effectiveness of the human interface
• Operational system aspects:
Availability – percentage of the time system is functioning, Manageability – ability to inspect and manage executing components, Upgradeability – can system be upgraded while running, how difficult are upgrade procedures, Reliability – ability to perform required functions over specified period of time and Recoverability – time required to recover from a failure.
Response – is the response fast enough for normal and extreme usage scenarios, Scalability – system capacity/throughput can be increased or decreased as necessary, Capacity/Throughput – handle heavy loads and still maintain response
• Safety – system does not create hazards in the real world
All of these attributes of the architecture are typical concerns for the architecture team. Members of the architecture team need to constantly evaluate the software architecture to determine if it meets the desired goals with respect to these characteristics. At first blush, this evaluation seems straightforward, but it is not. Increasing one attribute often results in a non-linear decrease in a different attribute. For example, an increase in modifiability might reduce performance. An increase in changeability might negatively impact testability. In addition, the requirements with respect to these properties are not easy to specify. Many of these attributes can only be assessed qualitatively given current tools and practice. Architects must constantly prioritize and manage the trade-offs between these attributes for a given project. Some of these properties also imply that architects are concerned with implementation mechanisms. For example, mechanisms involving data persistence, transactions, and component error handling often need consistent
approaches in order to meet the architectural goals. This often means coping with how to integrate legacy components alongside new components. To a large extent, the practice of software architecture is the attempt to balance a series of fuzzy trade-offs for the system stakeholders over what are often immensely complex systems. Looking at the whole system at once is simply not possible. Architects need tools to break down problems and reason about the parts, the interaction of the parts, and how the entire system fits together.
Definitions of other key architecture-related terms
The following are a few other definitions that are required for understanding the discussions in the remainder of the book. We recommend the reader rely on the recommended readings for a complete set of architecture-related definitions. Terms that are associated with a particular aspect of software architecture, for example terms associated with the analysis and design process, are defined in the appropriate sections later in this book. The following terms will provide a clearer understanding of concepts key to large-scale software architecture:
Architectural Patterns – define a general set of element types and their interactions. Examples of Architectural Patterns include Pipes and Filters, Model–View–Controller, and Reflection. Architectural Style – As the term coined by Garlan and Shaw, it is an idiomatic pattern of system organization. For example, a client–server system is an architectural style. Many of the original architectural styles have been
reformulated as patterns. Build Systems – Development teams typically employ a set of tools that facilitate the translation of a large source code base into a set of libraries and executables in an orderly manner. This usually involves interacting with configuration management tools as well as tools such as the ‘Make’ utility that utilizes software dependencies to perform incremental builds. Commercial Off-the-Shelf (COTS) Products – These include software components that are purchased from software vendors or obtained from open source. Some authors use the term ‘common’ in place of the term commercial to prevent confusion with using the term ‘commercial’ for open source software.
Component – A construct that groups implementation constructs and provides/consumes a set of interfaces. A component is a modular and easily replaceable implementation construct. The UML definition includes executable processes, applets, EJB, and code libraries as part of the componentdefinition. Some authors further categorize components to include conceptual or logical components. However, we define views only in terms of the runtime aspects of components.
Domain – A domain is an area of concern. For example, the ‘problem domain’ defines the ‘what’ aspect of the system under design. The ‘solution domain’ is the ‘how’ aspect. A large complex problem is often broken into sub-domains that address only one aspect of the larger problem.
Model – A representation used to understand or document one or more aspects of a problem or solution. With the UML, the model is often kept in a tool that will support the creation of multiple views. In this case, the tool can provide the ability to keep a series of partial views of a complex model consistent.
Top-Level Software Architecture Description – The set of views of the system that encompass the highest-level perspective of the software. This perspective tends to focus on subsystems and components as documented in the top-levelsoftware design document.
Subsystem – A collection of classes and components that are grouped to form a development package. These subsystems need to be defined in such a way as to facilitate having them assigned to different, possibly geographically diverse, development teams.
Other types of architectures
Architecture is used in conjunction with many adjunct terms such as technical architecture, business architecture, enterprise architecture, reference architecture, product line architecture, and information architecture. To some extent, all these ‘architectures’ have confused and obscured the definition of software
architecture. The following list will briefly describe some of these in order to clarify how they relate to software architecture:
Enterprise Architecture is generally defined in terms of its constituent architectures. These include the business architecture, application architecture, technology architecture, software infrastructure architecture, and information architecture. The enterprise architecture provides the vision and consistent principles that cross all the constituent architecture types and addresses objectives such as security, flexibility, make versus buy decisions, and reuse.
The Business Architecture defines the key business strategies, organization, goals, and related business processes. The software architecture should be complementary with the business architecture. We must remember that the final goal of most software is to make the business successful, not simply to produce an elegant software design.
At the enterprise level, the Application Architecture may be more of a set of guidelines on how the various software architectures should be constructed consistently across the enterprise. For a specific product, the application architecture is the software architecture for that product.
The Technology/Infrastructure Architecture refers to the network connectivity, hardware upon which the software runs, network routers, operating systems, and other technologies that facilitate the communication among the distributed software components and support the execution environment of
The Data Architecture, sometimes referred to as the Information Architecture, refers to how the data is structured, stored, and handled either in the enterprise or for a particular project. The definition of the data architecture involves the specification of the number and type of databases, the logical and physical database design, the allocation of data to servers, the strategy for data replication and archival, as well as the strategy and design of a data warehouse.
The U.S. Army’s Joint Technical Architecture – Army (JTA-Army) provides the following definition:
A Technical Architecture is the minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements that together may be used to form an information system. Its purpose is to ensure that a conformant system satisfies a specified set of requirements. It is the build code for the Systems Architecture being constructed to satisfy Operational Architecture requirements.
A Product-line Architecture is used to define a set of products that are developed by a company or organization within the company. The similarities within that set of products allow for sharing of design and implementation information among the various teams developing the products. In this way, the products can be more consistent in the way they are designed, developed, tested, supported, and in their appearance to the end user. In addition, these products can be developed in a more cost-effective manner, due to the design and implementation reuse potential.
The term Reference Architecture refers to the definition of an architecture for a particular application domain. An example domain might be satellite ground control systems or telecommunications switch network management. The reference architecture describes the high-level set of elements involved in applications from a particular domain along with their interactions. These elements must intentionally be left at a high level to apply to a large number of systems for that particular domain. Reference architectures are often used to focus on subsystem definition rather than application process level definition. Reference
architecture definitions also provide an excellent framework for development of a specific system in that application domain and can save the software architects a significant amount of time rediscovering these elements. In addition, the naming conventions used in the reference architecture provide a common
language for architects and application developers to communicate. The functional and interface definitions provided in the reference architecture also provide an opportunity for third-party COTS products to be developed that can be used by software architects for significant portions of the final system. The techniques and many of the architectural views described in this book can also be used for developing product-line, data, and reference architectures.