Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of the system. Each architectural view addresses some specific set of concerns, specific to stakeholders in the development process: users, designers, managers, system engineers, maintainers, and so on.

The views capture the major structural design decisions by showing how the software architecture is decomposed into components, and how components are connected by connectors to produce useful forms [PW92]. These design choices must be tied to the requirements -- functional and supplementary -- and other constraints. But these choices in turn put further constraints on the requirements, and on future design decisions at a lower level. 

In essence, architectural views are abstractions, or simplifications, of the entire design, in which important characteristics are made more visible by leaving details aside. These characteristics are important when reasoning about:

• System evolution-going to the next development cycle.
• Reuse of the architecture, or parts of it, in the context of a product line.
• Assessment of supplementary qualities, such as performance, availability, portability, and safety.
• Assignment of development work to teams or subcontractors.
• Decisions about including off-the-shelf components.
• Insertion in a wider system. 

To choose the appropriate set of views, identify the stakeholders who depend on software architecture documentation and the information that they need. For an example of a set of views that have been used to represent architecture, see Example: 4+1 Views of Software Architecture.  A more comprehensive set of views can be found in the IBM Views and Viewpoints Framework for IT systems.