To describe the context and perspective of the system to assure its integrity and understandability.

• Architect

• Architect

• Design the Solution
• Develop the Architecture

• Outline the Architecture
• Plan Iteration

• Develop the Architecture
• Outline the Architecture

This artifact gives context and guidance for developers to construct the system. It's a critical artifact used to help make architectural decisions and explain those decisions to developers. It can contain any information and references that are appropriate in communicating how developers should build the system. It generally doesn't contain design information, although it will likely reference architecturally significant design elements. At a minimum, it should list decisions and contraints the developers must follow in building the system, the justifications for those decisions and constraints, and describe the architectural mechanisms and where they should be applied. Team members who were not involved in those archtiectural decisions need to understand the reasoning behind the constraints imposed upon them.

Other recommended content is:

• References to architecturally significant requirements
• References to architecturally significant design elements
• Packaging instructions for subsystems and components
  
• Layers and critical subsystems
• Critical system interfaces
• Key abstractions
• Important analysis classes
• Key scenarios that describe critical behavior of the system

Architects should use this artifact to collaborate with other team members in developing the architecture, and to help team members understand the motivations behind architectural decisions so those decisions can be robustly implemented. For example, the architect may place constraints on how data is packaged and communited between different parts of the system. This may appear to be a burden, but the justification in the Architecture Notebook can explain that there is a significant performance bottleneck when communicating with a legacy system. The rest of the system must adapt to this bottleneck by following a specific data packaging scheme.

This artifact should also inform the Project Manager and other team members how the system is partitioned or organized so the team can adapt itself to the needs of the system. It also gives whoever must maintain and change the architecture later their first glimpse of the system and its technical motivations.

• Architecture

This artifact can be represented in many forms and from many viewpoints, depending on the needs of the project and the preferences of the project team. The architecture could be expressed as a simple list of decisions and contraints, a metaphor, or a comparison to a predefined architectural style or set of styles. It could include or reference diagrams that describe important aspects of the system's behavior or structure. It may reference a precise set of models or documents that describe the various aspects of the system's key elements.

It frequently references architecturally significant aspects of the Design . It can reference models that describe Architectural Views for communicating the architecture. A view is a representation of a system from the perspective of a related set of concerns. To choose the appropriate set of views, identify the Stakeholders who depend on software architecture documentation and the information that they need.

It need not be a formal document. Choose the medium that best meets the needs of the project.

• Architecture Notebook

• Pattern
• Component
• Software Architecture
• Visual Modeling

• Architectural View
• Layering
• Representing Interfaces to External Systems
• Abstract Away Complexity