Ontology for modeling architecture decisions, issues, options, forces, and their relationships.
Extension ontology for modeling architecture decisions, the issues that trigger them, candidate options, influencing forces (requirements, constraints, trends), and the rationale linking forces to chosen options. Use this extension when you need to capture decision records, trace forces to options, or integrate with ADD-style iterative decision processes.
Linked.Archi
Linked.Archi Architecture Decision Ontology
A business restriction on architecture options, such as budget limits, regulatory compliance, or organizational policies.
Business Constraint
A restriction that limits architecture options.
Constraint
An architecture decision that records a chosen course of action, its rationale, and the forces and options considered during the decision process.
ex:ADR-042 a ad:Decision ; skos:prefLabel "ADR-042: Use read replicas for Orders DB scaling"@en ; ad:hasIssue ex:DBScalabilityIssue ; ad:hasSelectedOption ex:ReadReplicas ; ad:hasAlternative ex:VerticalScaling, ex:CQRSOption ; ad:influencedByForce ex:AvailabilityReq, ex:PerformanceReq, ex:BudgetConstraint ; ad:relatedConcept ex:OrdersDB ; ad:justification "Read replicas provide horizontal scaling without downtime."@en .
Decision
Aligned with the MADR (Markdown Any Decision Records) template structure: Title, Status, Context, Decision, Consequences. Also compatible with Nygard-style ADRs and the Y-statement format (In the context of X, facing Y, we decided Z).
The lifecycle state of an architecture decision, such as proposed, accepted, deprecated, or superseded.
Common states: Proposed, Accepted, Deprecated, Superseded. Compatible with MADR status values.
Decision State
An architecture force — also referred to as an architecture driver (as in ADD) or motivation — that influences architecture decisions. The name Force is chosen as a more generic term that encompasses all factors influencing decisions, distinguishing it from the narrower meaning of Driver or Motivation.
ex:BudgetConstraint a ad:BusinessConstraint ; skos:prefLabel "Infrastructure Budget Limit"@en ; skos:definition "Monthly infrastructure cost must not exceed €15,000."@en ; ad:supportedByStakeholder ex:PlatformTeamLead ; ad:hasImportanceMeasure "high" .
Force
The term "Force" comes from the software architecture literature (Bass, Clements, Kazman) where "architectural forces" is the established term for all influences on architecture decisions. See DD-12 in doc/guide/design-decisions.md.
A qualified relationship that describes the influence of a Force onto a Decision. Used with the hasInfluence relationship.
Force Influence
A requirement specifying a function the system must perform.
Functional Requirement
The effect that a decision or option has on model concepts. Used with the affects relationship in the core ontology when linking ModelConcepts.
Impact
An influence that opposes or hinders a decision option.
Impending Influence
DecisionRequired
Problem
A problem or concern that requires an architecture decision. An Issue can be associated with any model concept and is also referred to as a Problem or a Decision-Required statement.
ex:ScalabilityIssue a ad:Issue ; skos:prefLabel "Database cannot handle peak load"@en ; ad:problemStatement "Current PostgreSQL instance reaches 95% CPU during Black Friday sales"@en ; ad:issueOwner ex:SolutionArchitect .
Issue
Issue is any problem that needs a decision to be resolved. It can be mapped to an abstract component where a more concrete implementation needs to be provided, or when an actual issue occurs that needs to be tackled. An Issue can represent, for example, an issue inside your issue-tracking software.
An iteration in the Attribute-Driven Design (ADD) process, grouping a set of related decisions and their goals.
ex:ADDIteration1 a ad:Iteration ; skos:prefLabel "ADD Iteration 1 — Establish Overall Structure"@en ; ad:hasDecisionGoal ex:SelectReferenceArchitecture ; ad:hasDecision ex:ADR-001, ex:ADR-002 .
Iteration
A candidate solution considered during the architecture decision process. Each Option addresses one or more forces and may include elements, tactics, or patterns.
ex:Option1 a ad:Option ; skos:prefLabel "Vertical scaling — upgrade to larger instance"@en ; ad:addressesForce ex:PerformanceReq ; ad:includesConcept ex:LargerDBInstance . ex:Option2 a ad:Option ; skos:prefLabel "Horizontal scaling — read replicas"@en ; ad:addressesForce ex:PerformanceReq, ex:AvailabilityReq ; ad:addsConcept ex:ReadReplica1, ex:ReadReplica2 .
Option
Someone's personal preference. Often not mentioned, but important to take into consideration as a force influencing architecture decisions.
Personal Preference
PersonalPreference might not be an officially used architecture force, but often is the one that drives many decisions especially if that preference is held by a very important Stakeholder.
An organizational policy that constrains architecture decisions.
Policy
A qualitative statement of intent that should be met by the architecture. It has at least a supporting rationale and a measure of importance.
Principle
A requirement on a specific [QualityAttribute](#QualityAttribute). Quality Attribute Requirements are described using Quality Attribute Scenarios. To model QAS use the properties: * [qasDescription](#qasDescription) * [qasSourceOfStimulus](#qasSourceOfStimulus) * [qasStimulus](#qasStimulus) * [qasEnvironment](#qasEnvironment) * [qasArtifact](#qasArtifact) * [qasResponse](#qasResponse) * [qasResponseMeasure](#qasResponseMeasure) Quality Attribute Requirements are tightly related to Technical Debt. Not addressing these software quality forces will increase the Technical Debt, which in turn will increase the force itself and also the cost to address that force later on.
ex:AvailabilityReq a ad:QualityAttributeRequirement ; skos:prefLabel "Payment Service Availability Under Peak Load"@en ; ad:onQualityAttribute iso25010:Availability ; ad:qasSourceOfStimulus "External users"@en ; ad:qasStimulus "Black Friday peak load (10x normal traffic)"@en ; ad:qasEnvironment "Normal operation, all regions active"@en ; ad:qasArtifact ex:PaymentService ; ad:qasResponse "Service continues processing transactions"@en ; ad:qasResponseMeasure "99.95% uptime, p99 latency < 500ms"@en .
Quality Attribute Requirement
Based on the Quality Attribute Scenario (QAS) structure from Bass, Clements, Kazman "Software Architecture in Practice": Source of Stimulus → Stimulus → Environment → Artifact → Response → Response Measure.
A statement of need that drives architecture decisions.
Requirement
An influence that supports or favors a decision option.
Supporting Influence
A technical restriction on implementation choices, such as mandated technologies or platform limitations.
Technical Constraint
A general direction in which something is developing or changing. This can be a generic technology trend or specific to the domain of interest.
Trend
Trend might not be an officially used architecture force, but often is the one that drives many decisions especially in young and less strict organizations.
Links an Option to a Force that it directly addresses or satisfies.
An Option for caching addresses the Performance force.
addresses force
Explicitly connects candidate solutions to the forces they are designed to satisfy.
Links an Option to a new ModelConcept that would be introduced if the Option is selected.
An Option adds a new Message Broker component to the architecture.
adds concept
Captures new elements that an option would bring into the architecture.
Links an Option to a ModelConcept that would be affected if the Option is selected.
Selecting a microservices Option affects the existing monolithic Application Component.
affects concept
Tracking which concepts are affected by an Option enables impact analysis before a decision is made.
Links a Tactic, Pattern, or Reference Architecture to a Decision Option in which it is applied.
applied in option
Links a ModelConcept directly to an Issue that needs to be addressed. These issues may relate to specific requirements or can map technical debt after a decision process.
associated issue
Links a Decision to another Decision that caused or triggered it.
caused by
Links a Force to another Force that complements or reinforces it.
A Reliability force complements an Availability force since both aim at continuous service.
complementary force
Links a Decision to another Decision that it conflicts with.
conflicts with
Links a Decision to another Decision that it depends on or requires as a prerequisite.
depends on
Links a Decision to a candidate Option that was considered but not necessarily selected. Options can be any Element, and standard options can be modelled as part of a ReferenceArchitecture in the form of building blocks, tactics, or patterns.
has alternative
Links an Issue to the Decision that addresses it.
has decision
Links a Decision to its goal, related to the ADD concept of iteration goal. The goal can also indicate the type of decision, such as choosing a reference architecture, tactic, or a combination of goals. Goals can be classified as concepts and referred to in the Architecture Metamodel.
has decision goal
Quantifies the difficulty of realizing a Requirement, measured by the impact and effort required. This measure can be stated, but in reality it often depends on the available Options. The less difficult the Requirement, the more influence it might have on the overall solution.
has difficulty measure
Indicates the degree to which an architect could influence or change the impact of this force.
has impact flexibility
Quantifies the general impact of a Force. This impact results in a specific influence onto a decision.
has impact measure
Indicates how much the impact of the force changes over time. This can be measured by capturing the resulting influence on concrete Issues and Decisions.
has impact volatility
Quantifies the importance of a Requirement, measured by the value it creates for the business, a particular Stakeholder, technology strategy, or Technical Debt reduction. The more important the Requirement, the more influence it might have on the overall solution.
has importance measure
Qualifies how a Force influenced a Decision, using an instance of ForceInfluence.
has influence
Quantifies the influence of a Force onto a Decision via a ForceInfluence instance.
has influence measure
Links a Decision to the Issue that it is supposed to address.
has issue
Links a Stakeholder to a Requirement that they have requested.
has requirement
Links an Option to a risk associated with selecting it. Risk is highly related to the level of uncertainty.
An Option for a novel technology carries a risk of insufficient community support.
has risk
Capturing risks per option enables informed trade-off analysis during the decision process.
Links a Decision to the Option that was ultimately selected as the chosen solution.
has selected option
Specifies ModelConcepts such as Elements, Relationships, and Viewpoints that are part of the Option.
An Option for Shared Repository DBMS includes MySQL; another may include PostgreSQL; another MongoDB.
includes concept
Options are composed of concrete model concepts that together form the candidate solution.
Links a Decision to the forces that actually influenced it. Note that for a chosen Option we already have the forces being addressed, but those are not quantified and we do not know what pushed for that particular option other than the rationale.
influenced by
Links an Issue to forces that potentially influence it. These may differ from the forces that actually drive the final decision.
influencing force
This is different from influencedByForce in that influencingForce captures potential forces recorded on an Issue before a decision is made, whereas influencedByForce captures the forces that actually drove the Decision.
Links an Issue to the element that caused it. An Issue can be caused by another Issue, a Decision, or any internal or external Element such as a global environmental event or change of strategy.
issue caused by
Links an Issue to the Stakeholder who is responsible for resolving it.
issue owner
Links an Issue to the entity that reported it. The reporter can be a Stakeholder or any other Element such as a monitoring system or audit process.
issue reported by
Architecture rationale text that justifies the Decision.
justification
An externally documented architecture rationale that justifies the Decision.
justification document
Links an Option to an existing ModelConcept that it reuses without significant changes.
An Option reuses the existing API Gateway without modification.
makes use of concept
Distinguishes reuse from modification — the concept satisfies the option as-is with only minor configuration.
Links an Option to a ModelConcept that would be modified if the Option is selected.
An Option modifies the existing Authentication Service to support OAuth 2.0.
modifies concept
Captures elements that an option would change rather than add or remove.
hasMeasure
Relates a QualityAttributeRequirement to the QualityAttribute it constrains.
on quality attribute
Links a Force to another Force that opposes or conflicts with it.
A Security force may oppose a Usability force when strict authentication hinders user experience.
opposing force
Links a Decision to the architecture consideration (stakeholder perspective, aspect, or concern) that it addresses.
pertains to
This way we may relate any Architecture Documentation Consideration such as stakeholder perspectives (layers), architecture aspects and concerns that are addressed by specific viewpoints.
A textual description of the problem or concern that the Issue represents.
problem statement
The system artifact that is stimulated in the Quality Attribute Scenario, such as a service, component, or data store.
QAS artifact
Textual description of the Quality Attribute Scenario. To qualify and distinguish different elements use the specific QAS properties: [qasSourceOfStimulus](#qasSourceOfStimulus), [qasStimulus](#qasStimulus), [qasEnvironment](#qasEnvironment), [qasArtifact](#qasArtifact), [qasResponse](#qasResponse), and [qasResponseMeasure](#qasResponseMeasure).
QAS description
The conditions under which the stimulus occurs, such as normal operation, peak load, or degraded mode.
QAS environment
The activity or behavior the system exhibits in response to the stimulus in the Quality Attribute Scenario.
QAS response
The measurable criterion used to determine whether the response satisfies the Quality Attribute Scenario.
QAS response measure
Range includes arch:QualityMeasure but also simple text or other documentation.
The entity (a human, a computer system, or any other actuator) that generated the stimulus in a Quality Attribute Scenario.
QAS source of stimulus
The condition or event that triggers the Quality Attribute Scenario, such as a user request, a fault, or an attack.
QAS stimulus
Maps ontology concepts between domains, for example between Tactics and Quality Attributes.
quality attribute match
Links an Element to a Requirement that it realizes or fulfills.
realize requirement
Links a Decision to a ModelConcept that is related to or affected by the decision.
related concept
Links a Decision to another related Decision, indicating a general relationship between the two.
related decision
Links an Option to a ModelConcept that would be removed from the architecture if the Option is selected.
An Option removes the legacy batch-processing service.
removes concept
Captures elements that an option would eliminate from the architecture.
Links a Decision to a previous Decision that it supersedes.
replaces
Links a Requirement to the Stakeholder who requested it.
requested by stakeholder
Links a Force to the Stakeholder who supports or champions it.
supported by stakeholder