• Architect

• Architect

• Design the Solution
• Refine the Architecture

• Outline the Architecture
• Outline the Architecture
• Plan Iteration
• Plan Iteration

• Outline the Architecture
• Outline the Architecture
• Refine the Architecture

• Agree on the Technical Approach  >  Architecture Notebook
• Agree the Technical Approach  >  Architecture
• Construction Phase Iteration  >  Manage Iteration  >  Architecture
• Construction Phase Iteration  >  Develop Solution (for requirement) (within context)  >  Architecture Notebook
• Construction Phase Iteration  >  Plan and Manage Iteration  >  Architecture Notebook
• Construction Phase Iteration  >  Develop Solution Increment  >  Architecture Notebook
• Develop Solution (for requirement) (within context)  >  Architecture Notebook
• Develop Solution Increment  >  Architecture Notebook
• Develop Solution Increment (no TDD)  >  Architecture Notebook
• Develop the Architecture  >  Architecture Notebook
• Develop the Architecture  >  Develop the Solution  >  Architecture Notebook
• Develop the Architecture  >  Architecture
• Develop the Architecture  >  Develop Solution Increment  >  Architecture Notebook
• Elaboration Phase Iteration  >  Manage Iteration  >  Architecture
• Elaboration Phase Iteration  >  Develop the Architecture  >  Architecture Notebook
• Elaboration Phase Iteration  >  Develop Solution (for requirement) (within context)  >  Architecture Notebook
• Elaboration Phase Iteration  >  Plan and Manage Iteration  >  Architecture Notebook
• Elaboration Phase Iteration  >  Develop the Architecture  >  Architecture
• Elaboration Phase Iteration  >  Develop Solution Increment  >  Architecture Notebook
• Inception Phase Iteration  >  Plan and Manage Iteration  >  Architecture
• Inception Phase Iteration  >  Agree on the Technical Approach  >  Architecture
• Inception Phase Iteration  >  Plan and Manage Iteration  >  Architecture Notebook
• Inception Phase Iteration  >  Plan and Manage Iteration  >  Architecture Notebook
• Inception Phase Iteration  >  Agree on the Technical Approach  >  Architecture Notebook
• Inception Phase Iteration  >  Agree on the Technical Approach  >  Architecture Notebook
• Inception Phase Iteration  >  Develop Architecture Spike  >  Architecture
• Plan and Manage Iteration  >  Architecture
• Plan and Manage Iteration  >  Architecture Notebook
• Transition Phase Iteration  >  Manage Iteration  >  Architecture
• Transition Phase Iteration  >  Develop Solution (for requirement) (within context)  >  Architecture Notebook
• Transition Phase Iteration  >  Plan and Manage Iteration  >  Architecture Notebook
• Transition Phase Iteration  >  Develop Solution Increment  >  Architecture Notebook

This artifact gives context and guidance for developers to construct the system. It's a critical artifact used to help capture and 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, this artifact should:

• List guidance, decisions, and constraints the developers must follow in building the system
• Justify those guidelines, decisions and constraints
• 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 context of the architecture so they can best address the needs of the system.

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 communicated 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.

This artifact is distinct from the Executable Architecture. This artifact describes how the system should be constructed, while the Executable Architecture is a build that contains part of the validated architecture.

• Architecture Notebook

The architecture can be represented in many forms and from many viewpoints, depending on the needs of the project and the preferences of the project team. It need not be a formal document. The essence of the architecture can often be communicated through a series of simple diagrams on a whiteboard; or as a list of decisions. Choose the medium that best meets the needs of the project.

The architecture can be expressed as a simple metaphor or as a comparison to a predefined architectural style or set of styles. It may be a precise set of models or documents that describe the various aspects of the system's key elements. Expressing it as skeletal build is another option - although this build may need to be baselined and preserved to ensure that the essence of the system can be understood as the system grows.

Part of the architecture frequently references architecturally significant portions 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.

• Architecture Notebook

• Component
• Executable Architecture
• Pattern
• Software Architecture
• Visual Modeling

• Abstract Away Complexity
• Architectural View
• Layering