Artifact: Architecture Notebook |  |
This artifact describes the context for software development. It contains the decisions, rationale, assumptions, explanations and implications of forming the architecture.
Domains: Architecture Work Product Kinds: Specification
Purpose
To describe the context and perspective of the system to assure its integrity and understandability.
Relationships
Roles | Responsible: Architect | Modified By: Architect
Tasks | Input To: Design the Solution Refine the Architecture Outline the Architecture Plan Iteration | Output From: Outline the Architecture Refine the Architecture
Description
Main Description | 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.
Illustrations
Templates | Architecture Notebook
Tailoring
Representation Options | 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.
More Information
Checklists | Architecture Notebook
Concepts | Pattern Component Software Architecture Executable Architecture Visual Modeling
Guidelines | Architectural View Layering Abstract Away Complexity
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright.