Skip to content

Attribute-Driven Design (ADD) in Practice with Linked.Archi

The Attribute-Driven Design method (ADD) from the SEI at Carnegie Mellon University is a systematic approach to designing software architectures based on quality attribute requirements. This article walks through three ADD iterations for a payment platform, showing how the existing Linked.Archi extensions — decisions, reference architecture, processes, and quality attributes — compose to support the full ADD workflow.

Unlike ATAM (which evaluates an existing architecture), ADD creates the architecture through iterative decomposition. Each iteration selects an element, identifies the driving quality requirements, and applies patterns and tactics to satisfy them.

The Scenario

A fintech startup is building a payment processing platform from scratch. The architecture team will use ADD to design the system iteratively, starting from the highest-level structure and decomposing into components.

Common Prefixes

@prefix ad:       <https://meta.linked.archi/arch-decision#> .
@prefix ap:       <https://meta.linked.archi/arch-processes#> .
@prefix refa:     <https://meta.linked.archi/ref-arch#> .
@prefix am:       <https://meta.linked.archi/archimate3/onto#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix arch:     <https://meta.linked.archi/core#> .
@prefix skos:     <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:       <https://model.example.com/payment-add#> .

The ADD Process as an Architecture Process

First, model the ADD method itself as a governance process:

ex:ADDProcess a ap:ArchitectureProcess ;
    skos:prefLabel "Attribute-Driven Design Process"@en ;
    skos:definition "Iterative architecture design driven by quality attribute requirements."@en ;
    ap:hasActivity ex:ChooseElement, ex:IdentifyASRs, ex:GenerateDesign,
                   ex:InventoryRequirements ;
    rdfs:seeAlso <https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=8147> .

ex:ChooseElement a ap:ProcessActivity ;
    skos:prefLabel "Step 1 — Choose element to design"@en ;
    ap:activityOfProcess ex:ADDProcess ;
    ap:precedes ex:IdentifyASRs .

ex:IdentifyASRs a ap:ProcessActivity ;
    skos:prefLabel "Step 2 — Identify ASRs for the element"@en ;
    ap:activityOfProcess ex:ADDProcess ;
    ap:follows ex:ChooseElement ;
    ap:precedes ex:GenerateDesign .

ex:GenerateDesign a ap:ProcessActivity ;
    skos:prefLabel "Step 3 — Generate design solution"@en ;
    ap:activityOfProcess ex:ADDProcess ;
    ap:follows ex:IdentifyASRs ;
    ap:precedes ex:InventoryRequirements .

ex:InventoryRequirements a ap:ProcessActivity ;
    skos:prefLabel "Step 4 — Inventory remaining requirements"@en ;
    ap:activityOfProcess ex:ADDProcess ;
    ap:follows ex:GenerateDesign .

Iteration 1 — Establish the Overall Structure

Goal: Select the reference architecture for the payment platform.

Step 1 — Choose element: The system itself (top-level decomposition).

Step 2 — Identify ASRs:

# The driving quality requirements
ex:QAS-Availability a ad:QualityAttributeRequirement ;
    skos:prefLabel "99.99% availability for payment processing"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasStimulus "Server failure during peak load"@en ;
    ad:qasEnvironment "Normal operation, all regions"@en ;
    ad:qasArtifact ex:PaymentPlatform ;
    ad:qasResponse "System continues processing without interruption"@en ;
    ad:qasResponseMeasure "99.99% uptime, zero lost transactions"@en ;
    ad:hasImportanceMeasure "critical" .

ex:QAS-Modifiability a ad:QualityAttributeRequirement ;
    skos:prefLabel "Add new payment provider in under 2 weeks"@en ;
    ad:onQualityAttribute iso25010:Modifiability ;
    ad:qasStimulus "Business requires new payment provider integration"@en ;
    ad:qasResponse "New provider added without modifying existing services"@en ;
    ad:qasResponseMeasure "< 2 weeks, zero downtime"@en ;
    ad:hasImportanceMeasure "high" .

ex:QAS-Security a ad:QualityAttributeRequirement ;
    skos:prefLabel "PCI-DSS Level 1 compliance"@en ;
    ad:onQualityAttribute iso25010:Confidentiality ;
    ad:qasStimulus "Attacker gains network access"@en ;
    ad:qasResponse "Payment data encrypted at rest and in transit"@en ;
    ad:qasResponseMeasure "PCI-DSS Level 1 audit pass"@en ;
    ad:hasImportanceMeasure "critical" .

ex:BudgetConstraint a ad:BusinessConstraint ;
    skos:prefLabel "Infrastructure budget < EUR 12,000/month"@en .

Step 3 — Generate design: Evaluate options using patterns and tactics from the ref-arch extension.

# Option A — Microservices
ex:MicroservicesOption a ad:Option ;
    skos:prefLabel "Microservices with Event-Driven Processing"@en ;
    ad:addressesForce ex:QAS-Availability, ex:QAS-Modifiability ;
    ad:includesConcept ex:MicroservicesPattern ;
    ad:addsConcept ex:APIGateway, ex:PaymentService, ex:FraudService,
                   ex:EventBus, ex:PaymentDB .

ex:MicroservicesPattern a refa:ArchitecturalPattern ;
    skos:prefLabel "Microservices"@en ;
    refa:appliedTactic ex:CircuitBreakerTactic, ex:ServiceDiscoveryTactic,
                       ex:AsyncMessagingTactic .

ex:CircuitBreakerTactic a refa:Tactic ;
    refa:addressedQA iso25010:Availability, iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour .

# Option B — Modular Monolith
ex:MonolithOption a ad:Option ;
    skos:prefLabel "Modular Monolith with Plugin Architecture"@en ;
    ad:addressesForce ex:QAS-Modifiability ;
    ad:includesConcept ex:ModularMonolithPattern ;
    ad:addsConcept ex:PaymentModule, ex:FraudModule, ex:SharedDB ;
    ad:hasRisk [ skos:prefLabel "Vertical scaling only — availability risk"@en ] .

The decision:

ex:Iteration1 a ad:Iteration ;
    skos:prefLabel "ADD Iteration 1 — Overall Structure"@en ;
    ad:hasDecisionGoal [ skos:prefLabel "Select reference architecture"@en ] .

ex:ADR-001 a ad:Decision ;
    skos:prefLabel "ADR-001: Microservices architecture for payment platform"@en ;
    ad:hasSelectedOption ex:MicroservicesOption ;
    ad:hasAlternative ex:MonolithOption ;
    ad:influencedByForce ex:QAS-Availability, ex:QAS-Modifiability, ex:BudgetConstraint ;
    ad:relatedConcept ex:PaymentPlatform ;
    ad:justification """Microservices address both availability (independent scaling,
    circuit breaker isolation) and modifiability (independent deployment,
    adapter pattern for providers). Budget is feasible with Kubernetes on
    managed cloud."""@en .

ex:Iteration1 ad:hasDecision ex:ADR-001 .

Step 4 — Inventory: QAS-Security is not yet addressed. QAS-Availability is partially addressed (circuit breaker, but no data tier redundancy). → Next iteration.

Iteration 2 — Data Tier Resilience

Goal: Address the data tier availability gap identified in Iteration 1.

ex:Iteration2 a ad:Iteration ;
    skos:prefLabel "ADD Iteration 2 — Data Tier Resilience"@en ;
    ad:hasDecisionGoal [ skos:prefLabel "Ensure data tier meets 99.99% availability"@en ] .

# New ASR surfaced from Iteration 1 analysis
ex:QAS-DataFailover a ad:QualityAttributeRequirement ;
    skos:prefLabel "Database failover within 30 seconds"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasStimulus "Primary database instance fails"@en ;
    ad:qasArtifact ex:PaymentDB ;
    ad:qasResponse "Automatic failover to replica"@en ;
    ad:qasResponseMeasure "< 30 seconds, zero data loss"@en .

# Options
ex:ReadReplicaOption a ad:Option ;
    skos:prefLabel "PostgreSQL with streaming replication + auto-failover"@en ;
    ad:addressesForce ex:QAS-DataFailover, ex:QAS-Availability ;
    ad:addsConcept ex:ReadReplica1, ex:ReadReplica2, ex:Patroni ;
    ad:modifiesConcept ex:PaymentDB .

ex:MultiMasterOption a ad:Option ;
    skos:prefLabel "CockroachDB multi-master"@en ;
    ad:addressesForce ex:QAS-DataFailover, ex:QAS-Availability ;
    ad:removesConcept ex:PaymentDB ;
    ad:addsConcept ex:CockroachCluster ;
    ad:hasRisk [ skos:prefLabel "Team has no CockroachDB experience"@en ] .

# Decision
ex:ADR-002 a ad:Decision ;
    skos:prefLabel "ADR-002: PostgreSQL with streaming replication for payment data"@en ;
    ad:hasSelectedOption ex:ReadReplicaOption ;
    ad:hasAlternative ex:MultiMasterOption ;
    ad:influencedByForce ex:QAS-DataFailover, ex:BudgetConstraint ;
    ad:justification "Streaming replication with Patroni provides automatic failover within 10 seconds. Team already has PostgreSQL expertise."@en .

ex:Iteration2 ad:hasDecision ex:ADR-002 .

Iteration 3 — Security Architecture

Goal: Address PCI-DSS compliance.

ex:Iteration3 a ad:Iteration ;
    skos:prefLabel "ADD Iteration 3 — Security Architecture"@en ;
    ad:hasDecisionGoal [ skos:prefLabel "Achieve PCI-DSS Level 1 compliance"@en ] .

# The security tactic
ex:EncryptionAtRestTactic a refa:Tactic ;
    skos:prefLabel "Encryption at Rest"@en ;
    refa:addressedQA iso25010:Confidentiality ;
    refa:impactedQA iso25010:TimeBehaviour .

ex:TokenizationTactic a refa:Tactic ;
    skos:prefLabel "Tokenization"@en ;
    refa:addressedQA iso25010:Confidentiality ;
    skos:definition "Replace sensitive data with non-sensitive tokens."@en .

# Options
ex:FullEncryptionOption a ad:Option ;
    skos:prefLabel "Full database encryption + TLS everywhere"@en ;
    ad:addressesForce ex:QAS-Security ;
    ad:includesConcept ex:EncryptionAtRestTactic ;
    ad:modifiesConcept ex:PaymentDB ;
    ad:hasRisk [ skos:prefLabel "~15% query performance degradation"@en ] .

ex:TokenizationOption a ad:Option ;
    skos:prefLabel "Tokenization vault + selective encryption"@en ;
    ad:addressesForce ex:QAS-Security ;
    ad:includesConcept ex:TokenizationTactic, ex:EncryptionAtRestTactic ;
    ad:addsConcept ex:TokenVault .

# Decision
ex:ADR-003 a ad:Decision ;
    skos:prefLabel "ADR-003: Tokenization vault for PCI-DSS compliance"@en ;
    ad:hasSelectedOption ex:TokenizationOption ;
    ad:hasAlternative ex:FullEncryptionOption ;
    ad:influencedByForce ex:QAS-Security, ex:QAS-Availability ;
    ad:justification """Tokenization reduces the PCI-DSS scope — only the vault handles
    raw card data. Other services work with tokens, avoiding the performance
    penalty of full encryption while maintaining compliance."""@en .

ex:Iteration3 ad:hasDecision ex:ADR-003 .

The Resulting Architecture

After three iterations, the architecture has been decomposed into concrete elements, each justified by a traceable decision:

# The system
ex:PaymentPlatform a am:ApplicationComponent ;
    skos:prefLabel "Payment Platform"@en ;
    am:composedOf ex:APIGateway, ex:PaymentService, ex:FraudService,
                  ex:EventBus, ex:PaymentDB, ex:ReadReplica1,
                  ex:ReadReplica2, ex:Patroni, ex:TokenVault .

Every element traces back to the decision that introduced it:

PREFIX ad: <https://meta.linked.archi/arch-decision#>

# For each element, which decision introduced it?
SELECT ?element ?elementLabel ?decision ?decisionLabel ?iteration WHERE {
    ?decision ad:hasSelectedOption ?option .
    ?option ad:addsConcept ?element .
    ?element skos:prefLabel ?elementLabel .
    ?decision skos:prefLabel ?decisionLabel .
    ?iteration ad:hasDecision ?decision ;
               skos:prefLabel ?iterationLabel .
}
ORDER BY ?iteration

ADD → ATAM → ADD Cycle

After the three ADD iterations, the architecture is ready for ATAM evaluation. The ATAM evaluation (see ATAM Evaluation in Practice) may identify new risks that trigger additional ADD iterations:

ADD Iteration 1 → Overall structure (microservices)
ADD Iteration 2 → Data tier resilience (replication)
ADD Iteration 3 → Security (tokenization)
    ↓
ATAM Evaluation → identifies Risk-EventOrdering, TP-Encryption
    ↓
ADD Iteration 4 → Address event ordering risk
ADD Iteration 5 → Optimize encryption tradeoff

In Linked.Archi, this cycle is fully traceable:

PREFIX ad:   <https://meta.linked.archi/arch-decision#>
PREFIX atam: <https://meta.linked.archi/atam/onto#>

# Which ADD iterations were triggered by ATAM risks?
SELECT ?risk ?riskLabel ?issue ?decision ?iteration WHERE {
    ?risk a atam:ArchitecturalRisk ;
          skos:prefLabel ?riskLabel .
    ?issue ad:issueCausedBy ?risk .
    ?decision ad:hasIssue ?issue .
    ?iteration ad:hasDecision ?decision .
}

What Linked.Archi Adds to ADD

ADD as described by the SEI is a whiteboard method — it produces "sketches of architectural views." Linked.Archi makes those sketches into queryable, traceable, validatable knowledge:

ADD produces Linked.Archi adds
Sketches on a whiteboard arch:Model with typed elements and relationships
Verbal rationale ad:justification — searchable, auditable text
Mental model of forces ad:Force hierarchy — queryable, prioritized, linked to stakeholders
Implicit pattern selection refa:Pattern + refa:Tactic — with quality attribute trade-offs
Iteration notes ad:Iteration — grouping decisions with goals
"We should check this" atam:ArchitecturalRisk — formal risk tracking

The architecture is no longer in someone's head. It's in the knowledge graph, queryable by AI agents, validatable by SHACL, and traceable from business requirement to deployment decision.

References