Architecture Decision RecordDecisioun record templat bi Jeff Tyree an Art Akerman
This is the architectur decisioun description templat publisht in "Architecture Decisions: Demystifying Architecture" by Jeff Tyree and Art Akerman, Capital One Financial.
Issue: Describe the architectural design issue ye're addressin, leavin nae questions aboot why ye're addressin this issue noo. Follaein a minimalist approach, address an document juist the issues that need addressin at various pynts in the life cycle.
Decision: Clearly state the architectur’s direction—that is, the position ye’ve selectit.
Status: The decisioun’s status, sic as pendin, decidit, or approved.
Group: Ye can uise a simple groupin—sic as integration, presentation, data, an sae on—tae help organise the set o decisiouns. Ye could an aw uise a mair sophisticatit architectur ontology, sic as John Kyaruzi an Jan van Katwijk’s, which includes mair abstract categories sic as event, calendar, an location. For example, uisin this ontology, ye’d group decisiouns that deal wi occurrences whaur the system requires information unner event.
Assumptions: Clearly describe the unnerlyin assumptiouns in the environment in which ye’re makin the decisioun—cost, schedule, technology, an sae on. Note that environmental constraints (sic as acceptit technology staundarts, enterprise architectur, commonly employit patterns, an sae on) micht limit the alternatives ye consider.
Constraints: Tak doun onie additional constraints tae the environment that the chosen alternative (the decisioun) micht pose.
Positions: List the positiouns (viable options or alternatives) ye consideret. These aften require lang explanatiouns, whiles even models an diagrams. This isna an exhaustive list. But, ye dinnae want tae hear the question "Did you think about...?" durin a final review; this leads tae loss o credibility an questionin o ither architectural decisiouns. This section an aw helps ensure that ye heard ithers’ opinions; explicitly statin ither opinions helps enrol their advocates in yer decisioun.
Argument: Outline why ye selectit a position, includin items sic as implementation cost, total ownership cost, time tae market, an the availability o required development resources. This is probably as important as the decisioun itsel.
Implications: A decisioun comes wi mony implicatiouns, as the REMAP metamodel denotes. For example, a decisioun micht introduce a need tae mak ither decisiouns, mak new requirements, or modify existin requirements; pose additional constraints tae the environment; require renegotiatin scope or schedule wi customers; or require additional staff trainin. Clearly unnerstaunin an statin yer decisioun’s implicatiouns can be unco effective in gaein buy-in an makin a roadmap for architectur execution.
Related decisions: It’s obvious that mony decisiouns are relatit; ye can list them here. But, we’ve found that in practice, a traceability matrix, decisioun trees, or metamodels are mair uiseful. Metamodels are uiseful for shawin complex relationships diagrammatically (sic as Rose models).
Related requirements: Decisiouns sud be business driven. Tae shaw accountability, explicitly map yer decisiouns tae the objectives or requirements. Ye can enumerate thir relatit requirements here, but we’ve found it mair convenient tae reference a traceability matrix. Ye can assess each architectur decisioun’s contribution tae meetin each requirement, an than assess hoo weel the requirement is met athort aw decisiouns. If a decisioun doesna contribute tae meetin a requirement, dinnae mak that decisioun.
Related artifacts: List the relatit architectur, design, or scope documents that this decisioun impacts.
Related principles: If the enterprise haes an agreed-upon set o principles, mak siccar the decisioun is consistent wi ane or mair o them. This helps ensure alignment alang domains or systems.
Notes: Acause the decisioun-makin process can tak weeks, we’ve found it uiseful tae tak doun notes an issues that the team discusses durin the socialisation process.