Skip to main content

Enterprise OpenUP (with CobiT)

Go Search
Home
  
Enterprise OpenUP (with CobiT) > Wiki Pages > WorkProduct - Architecture  

WorkProduct - Architecture

WorkProduct Detail

Architecture

Description

Overview:
This artifact describes the context for software development. It contains the decisions, rationale, assumptions, explanations and implications of forming the architecture.

Purpose:

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


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.

Roles

ResponsibleArchitect

Last modified at 1/25/2008 2:13 AM  by Administrator