The purpose of this activity is to define an architectural decision and get it approved and published.
Work Breakdown Structure
Purpose
The purpose of this activity is to define an
Architectural Decision (AD) and get it approved and published. Documenting important ADs provides a repository of decisions
that will help guide other architects, managers and implementors in being compliant with enterprise and business domain
standards. They also provide a source of information for re-visiting decisions over time.
Description
This activity has the following goals:
Create an Architecture Decision (AD):
Define the context of the problem, issue or decision;
Define the constraints, imposed by existing architecture, enterprise standards or others;
Define the rationale for the decision, through a well researched summary of the facts;
Extract the implications of the AD, on current systems, future systems, support aspects and other aspects;
This activity is best carried out by an individual IT architect or a small team, and usually guided by one or
two individuals who have deep experience in architecting systems in the relevant domain. The team is staffed by
cross-functional team members best carries out these activities. Issues that are typically architecturally important
include performance, scaling, distribution, or other speciality engineering requirements. Significant architectural
constraints might also flow from physical and environmental requirements. The team should also include members with domain
experience who can identify key abstractions. Issues that are typically architecturally significant include technology,
performance, scaling, process and thread synchronization, and distribution. The team should also include members with
in-depth relevant IT technology knowledge. The team should also have experience with modeling, organization and
layering.
Usage
Usage Guidance
An architectural decision may be defined at any time during a project, during business planning and in any
other contexts.
