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.