Extensions Guide¶

Extensions are composable modules that add cross-cutting capabilities to any metamodel. Unlike modeling languages (which define complete element/relationship palettes for a specific notation), extensions provide vocabulary for concerns that span multiple languages — decision tracking, process governance, reference architectures, quality attributes, and architectural tactics.

Every extension imports arch:core and defines classes that subclass arch:Element, making them usable in architecture views alongside elements from any modeling language.

Overview¶

arch:core
  ├── ad:arch-decision      Decisions, forces, options, rationale
  ├── ap:arch-processes      Governance processes, activities, milestones
  ├── refa:ref-arch          Patterns, tactics, reference models, building blocks
  ├── qa:quality-attributes  Quality attribute individuals (ISO 25010 aligned)
  ├── tac:tactics            Architectural tactics by quality attribute
  ├── mlsys:ml-systems       ML-enabled system elements, stakeholders, viewpoints
  ├── aigov:ai-governance    AI ethics, risk classification, conformity assessment
  └── fina:financial-architecture  TCO, investment cases, CBA, FinOps
  └── easvc:ea-service           Service catalog, engagements, satisfaction, maturity

Extension	Prefix	Namespace	Key Classes
Architecture Decisions	`ad:`	`https://meta.linked.archi/arch-decision#`	Decision, Issue, Option, Force, Requirement, QualityAttributeRequirement
Architecture Processes	`ap:`	`https://meta.linked.archi/arch-processes#`	ArchitectureProcess, ProcessActivity, ProcessTask, ProcessDeliverable, ProcessRole
Reference Architecture	`refa:`	`https://meta.linked.archi/ref-arch#`	ReferenceArchitecture, ReferenceModel, Pattern, Tactic, ABB, SBB
Quality Attributes	`qa:`	`https://meta.linked.archi/quality-attributes#`	Quality attribute individuals
Tactics	`tac:`	`https://meta.linked.archi/tactics#`	Tactic individuals organized by quality attribute
ML-Enabled Systems	`mlsys:`	`https://meta.linked.archi/ml-systems/onto#`	MLModel, Dataset, TrainingPipeline, ServingInfrastructure, FeatureStore
AI Ethics & Governance	`aigov:`	`https://meta.linked.archi/ai-governance/onto#`	AISystem, RiskClassification, ConformityAssessment, BiasAssessment, HumanOversightPlan
Financial Architecture	`fina:`	`https://meta.linked.archi/financial-architecture/onto#`	CostModel, CostItem, InvestmentCase, CostBenefitAnalysis, Budget
EA-as-a-Service	`easvc:`	`https://meta.linked.archi/ea-service/onto#`	EAService, ServiceCatalog, ServiceEngagement, SatisfactionAssessment, EAMaturityAssessment

How Extensions Compose¶

Extensions can be imported individually or in combination. A metamodel declares which extensions it uses:

ex:MyMetamodel a arch:Metamodel ;
    arch:modelConcepts
        <https://meta.linked.archi/archimate3/onto#>,
        <https://meta.linked.archi/arch-decision#>,
        <https://meta.linked.archi/arch-processes#>,
        <https://meta.linked.archi/ref-arch#> .

Extensions also compose with each other. This is where the real power lies — each extension addresses a different facet of architecture work, and together they form a complete picture:

Decisions + Quality Attributes — ad:QualityAttributeRequirement references quality attribute individuals via ad:onQualityAttribute. This connects "we need 99.95% availability" to the formal ISO 25010 definition of Availability.
Decisions + Reference Architecture — ad:Option can include patterns and tactics via ad:includesConcept. This connects "we chose the Circuit Breaker pattern" to the formal pattern definition with its quality attribute trade-offs.
Processes + Decisions — Process outputs include ad:Decision; process inputs include ad:Force. This connects "the Architecture Review Board produced ADR-042" to the governance workflow that led to it.
Reference Architecture + Tactics — refa:Tactic addresses quality attributes via refa:addressedQA; patterns contain tactics via refa:appliedTactic. This connects "the Microservices pattern uses Circuit Breaker and Retry tactics" to the quality attributes they address.
ML Systems + AI Governance — aigov:AISystem wraps mlsys:MLModel and mlsys:ServingInfrastructure via aigov:wrapsMLModel and aigov:wrapsServingInfra. This connects "the fraud detection model is classified as High Risk under the EU AI Act" to the technical ML components it governs. See the AI Governance Practice Guide.
AI Governance + Decisions — ad:Decision can reference aigov:AISystem via arch:refines. This connects "ADR-051: Adopt EU AI Act compliance framework" to the AI systems it affects.
Financial Architecture + Decisions — fina:hasCostBenefitAnalysis links ad:Option to fina:CostBenefitAnalysis. This connects "Option A costs EUR 450K with NPV of EUR 220K" to the decision it informs. See the Financial Architecture Practice Guide.
Financial Architecture + TIME — fina:hasCostModel on timefw:Application enables cost-aware portfolio rationalization. "What is the total migration cost for all Migrate-classified applications?" becomes a single SPARQL query.
ML Systems + Decisions — ad:QualityAttributeRequirement can reference ML quality attributes (mlqa:Explainability, mlqa:Fairness). This connects "the model must be explainable" to the formal quality attribute definition. See the ML Systems Practice Guide.

1. Architecture Decisions (`ad:arch-decision`)¶

Why This Extension Exists¶

Architecture decisions are the most important artifacts an architect produces — more important than diagrams, more durable than models. Yet in most organizations, decisions live in Confluence pages, email threads, or people's heads. When someone asks "why did we choose Kafka over RabbitMQ?", the answer is often "ask Sarah, she was here when we decided that."

The architecture decisions extension solves this by making decisions, the forces that drove them, the options that were considered, and the rationale that justified the choice into first-class elements in the knowledge graph. Every decision is traceable to the requirements it addresses, the elements it affects, and the stakeholders who influenced it.

The extension is grounded in academic research on architecture decision documentation (Jansen & Bosch, Kruchten, Zimmermann) and aligned with the MADR (Markdown Any Decision Records) template structure. It implements the Attribute-Driven Design (ADD) methodology's concept of iterative, quality-driven decision making.

When to Use¶

Import this extension when your metamodel needs to:

Capture architecture decision records (ADRs) as queryable, linked data
Trace decisions to the forces (requirements, constraints, quality attributes, trends) that influenced them
Evaluate candidate options with their trade-offs, risks, and element impact
Link decisions to affected model elements for impact analysis
Model quality attribute scenarios (QAS) with the full stimulus-response structure

The Decision Lifecycle¶

The core flow is: Issue → Forces → Options → Decision → Impact

An Issue is a problem that needs a decision. It might come from a stakeholder concern, a technical limitation, or a change in requirements. Issues are linked to the forces that influence them and the elements that caused them.

Forces are everything that influences the decision — requirements, constraints, principles, trends, even personal preferences. The extension provides a rich hierarchy of force types because different forces have different characteristics: a budget constraint is non-negotiable, a technology trend is directional, a personal preference is subjective but real.

Options are candidate solutions. Each option addresses specific forces and has a concrete impact on the architecture — it adds, removes, modifies, or reuses model elements. Options can include patterns and tactics from the reference architecture extension.

A Decision records the chosen option, the alternatives that were rejected, the forces that drove the choice, and the justification. Decisions link to the affected elements, enabling impact analysis.

Example: Database Scaling Decision¶

This example models a real-world scenario: an e-commerce platform's Orders database can't handle Black Friday traffic. The architecture team needs to decide how to scale it.

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

Step 1 — The elements under discussion. These already exist in the architecture model. The decision will affect them.

ex:OrderService a am:ApplicationComponent ;
    skos:prefLabel "Order Service"@en .

ex:OrdersDB a am:ApplicationComponent ;
    skos:prefLabel "Orders Database"@en .

ex:OrderService am:accesses ex:OrdersDB .

Step 2 — The issue. Something triggered the need for a decision. Note how the issue links to the element that caused it, the stakeholder who owns it, and the forces that influence it.

ex:DBScalabilityIssue a ad:Issue ;
    skos:prefLabel "Orders DB cannot handle peak load"@en ;
    ad:problemStatement
        """The Orders Database reaches 95% CPU utilization during Black Friday
        sales events (10x normal traffic). Response times degrade from 50ms
        to 3 seconds, causing order timeouts and revenue loss."""@en ;
    ad:issueOwner ex:SolutionArchitect ;
    ad:issueCausedBy ex:OrdersDB ;
    ad:influencingForce ex:AvailabilityReq, ex:PerformanceReq, ex:BudgetConstraint .

Step 3 — The forces. Each force has a type, importance, and stakeholder. Quality attribute requirements use the full QAS (Quality Attribute Scenario) structure from Bass, Clements, Kazman — source of stimulus, stimulus, environment, artifact, response, response measure.

# A quality attribute requirement with full QAS structure
ex:AvailabilityReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Order Service Availability Under Peak Load"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasSourceOfStimulus ex:Customer ;
    ad:qasStimulus "Black Friday peak load — 10x normal traffic"@en ;
    ad:qasEnvironment "Normal operation, all regions active"@en ;
    ad:qasArtifact ex:OrderService ;
    ad:qasResponse "Service continues processing orders without errors"@en ;
    ad:qasResponseMeasure "99.95% uptime, zero order loss"@en ;
    ad:requestedByStakeholder ex:ProductOwner ;
    ad:hasImportanceMeasure "critical"^^xsd:string .

# A business constraint — non-negotiable budget limit
ex:BudgetConstraint a ad:BusinessConstraint ;
    skos:prefLabel "Infrastructure Budget Limit"@en ;
    skos:definition "Monthly infrastructure cost must not exceed EUR 15,000."@en ;
    ad:supportedByStakeholder ex:PlatformTeamLead .

Step 4 — The options. Each option specifies which forces it addresses and how it impacts the architecture. The addsConcept, modifiesConcept, removesConcept, and makesUseConcept properties make the impact explicit and queryable.

ex:VerticalScaling a ad:Option ;
    skos:prefLabel "Option A — Vertical Scaling"@en ;
    skos:definition "Upgrade PostgreSQL to a larger instance."@en ;
    ad:addressesForce ex:PerformanceReq ;
    ad:modifiesConcept ex:OrdersDB ;
    ad:hasRisk [ skos:prefLabel "Single point of failure — no redundancy"@en ] .

ex:ReadReplicas a ad:Option ;
    skos:prefLabel "Option B — Read Replicas"@en ;
    skos:definition "Add two read replicas behind a connection proxy."@en ;
    ad:addressesForce ex:PerformanceReq, ex:AvailabilityReq ;
    ad:makesUseConcept ex:OrdersDB ;
    ad:addsConcept ex:ReadReplica1, ex:ReadReplica2, ex:ConnectionProxy .

ex:CQRSOption a ad:Option ;
    skos:prefLabel "Option C — CQRS + Event Sourcing"@en ;
    skos:definition "Separate read and write models with an event store."@en ;
    ad:addressesForce ex:PerformanceReq, ex:AvailabilityReq ;
    ad:removesConcept ex:OrdersDB ;
    ad:addsConcept ex:EventStore, ex:ReadModel ;
    ad:hasRisk [ skos:prefLabel "Team has no event sourcing experience"@en ] .

Step 5 — The decision. Links everything together: the issue it resolves, the option selected, the alternatives rejected, the forces that drove it, the elements affected, and the justification.

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, ex:OrderService ;
    ad:justification
        """Read replicas provide horizontal read scaling without application changes.
        Cost is ~EUR 3,000/month for two replicas, within budget. Vertical scaling
        was rejected because it doesn't address availability. CQRS was rejected
        due to team skill gap and timeline constraints."""@en .

Querying Decisions¶

Once decisions are in the knowledge graph, you can answer questions that are impossible with document-based ADRs:

# Which elements are affected by decisions driven by availability concerns?
PREFIX ad:       <https://meta.linked.archi/arch-decision#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?decision ?decisionLabel ?element ?elementLabel WHERE {
    ?decision a ad:Decision ;
              skos:prefLabel ?decisionLabel ;
              ad:influencedByForce ?force ;
              ad:relatedConcept ?element .
    ?element skos:prefLabel ?elementLabel .
    ?force ad:onQualityAttribute iso25010:Availability .
}

# Which options were rejected and why?
PREFIX ad: <https://meta.linked.archi/arch-decision#>

SELECT ?decision ?rejected ?rejectedLabel WHERE {
    ?decision a ad:Decision ;
              ad:hasAlternative ?rejected .
    ?rejected skos:prefLabel ?rejectedLabel .
    FILTER NOT EXISTS { ?decision ad:hasSelectedOption ?rejected }
}

Force Hierarchy¶

Forces are organized in a class hierarchy under ad:Force. This matters because different force types have different characteristics — a constraint is non-negotiable, a trend is directional, a preference is subjective:

ad:Force
  ├── ad:Principle              Qualitative statements of intent
  ├── ad:Requirement
  │     ├── ad:FunctionalRequirement
  │     ├── ad:QualityAttributeRequirement   (with full QAS properties)
  │     └── ad:Constraint
  │           ├── ad:TechnicalConstraint
  │           └── ad:BusinessConstraint
  ├── ad:Trend                  Technology or domain trends
  ├── ad:PersonalPreference     Stakeholder preferences (real but subjective)
  └── ad:Policy                 Organizational policies

The name "Force" was chosen over "Driver" or "Motivation" because it is more generic and avoids collision with ArchiMate's Driver concept. See DD-12.

2. Architecture Processes (`ap:arch-processes`)¶

Why This Extension Exists¶

Architecture governance is often informal — review boards meet, decisions are made, but the process itself is not captured. When a new architect joins, they don't know what the governance workflow looks like, who approves what, or what deliverables are expected. When an audit asks "what process led to this architecture?", nobody can answer without manual research.

The architecture processes extension makes governance workflows into first-class model elements. A process has activities, tasks, roles, milestones, inputs, and outputs — all queryable, all traceable. You can model your Architecture Review Board process, your ADD iterations, your TOGAF ADM phases, or any custom governance workflow.

The extension is aligned with ISO/IEC/IEEE 42020 (architecture governance), 12207 (software lifecycle), and 15288 (system lifecycle). But it's not a copy of those standards — the standards live in standards/ as reference vocabularies. This extension provides the practical model elements that you use in architecture views.

When to Use¶

Import this extension when your metamodel needs to:

Model architecture governance workflows (review boards, design authorities)
Capture the decomposition of processes into activities and tasks
Assign roles and responsibilities to process steps
Track milestones and governance gates
Trace which processes produce which deliverables and decisions
Integrate with TOGAF ADM phases or ISO 42020 process areas

The Process Decomposition¶

The core structure is: Process → Activity → Task

An ArchitectureProcess is the top-level workflow. It has activities, inputs, outputs, milestones, and a responsible role. Processes can also have sub-processes for hierarchical decomposition.

A ProcessActivity is a cohesive set of tasks within a process. Activities are ordered (via precedes/follows) and assigned to roles (via performedBy).

A ProcessTask is the finest-grained unit of work — something a person actually does. Tasks belong to activities and can also be assigned to roles.

Supporting concepts:

ProcessDeliverable — a tangible output (document, model, report) that must be formally delivered
InformationItem — a body of information that flows between processes (a subclass of ProcessDeliverable)
ProcessMilestone — a governance checkpoint or phase gate
ProcessRole — a role that a stakeholder plays within a process (subclass of arch:Stakeholder)

Example: Architecture Review Board¶

This example models a formal architecture review process — the kind of governance workflow that organizations use to evaluate architecture proposals before implementation.

@prefix ap:   <https://meta.linked.archi/arch-processes#> .
@prefix ad:   <https://meta.linked.archi/arch-decision#> .
@prefix arch: <https://meta.linked.archi/core#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:   <https://model.example.com/governance#> .

The roles. Who participates in this process and what are their responsibilities?

ex:ChiefArchitect a ap:ProcessRole ;
    skos:prefLabel "Chief Architect"@en ;
    skos:definition "Senior architect responsible for architecture governance."@en ;
    ap:responsibleFor ex:ArchReviewProcess .

ex:SolutionArchitect a ap:ProcessRole ;
    skos:prefLabel "Solution Architect"@en ;
    skos:definition "Architect responsible for a specific solution domain."@en .

ex:SecurityArchitect a ap:ProcessRole ;
    skos:prefLabel "Security Architect"@en ;
    skos:definition "Specialist reviewing security aspects of proposals."@en .

The process. The top-level workflow with its activities and standards alignment.

ex:ArchReviewProcess a ap:ArchitectureProcess ;
    skos:prefLabel "Architecture Review Board Process"@en ;
    skos:definition """Formal governance process for evaluating architecture proposals
    against enterprise standards, quality attributes, and strategic alignment.
    Triggered when a project proposes significant architectural changes."""@en ;
    ap:hasActivity ex:RequestSubmission, ex:ReviewPreparation,
                   ex:ReviewExecution, ex:ReviewFollowUp ;
    rdfs:seeAlso <https://meta.linked.archi/iso42020#ArchitectureGovernance> .

The activities and tasks. Each activity decomposes into concrete tasks. Note the sequencing (precedes/follows) and role assignments (performedBy).

# Activity 1: The solution architect submits a proposal
ex:RequestSubmission a ap:ProcessActivity ;
    skos:prefLabel "1. Request Submission"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:performedBy ex:SolutionArchitect ;
    ap:precedes ex:ReviewPreparation ;
    ap:hasTask ex:PrepareProposal, ex:SubmitRequest .

ex:PrepareProposal a ap:ProcessTask ;
    skos:prefLabel "Prepare architecture proposal"@en ;
    skos:definition """Document the proposed architecture including context,
    requirements, options considered, and quality attribute analysis."""@en ;
    ap:taskOfActivity ex:RequestSubmission .

# Activity 2: The chief architect triages and assigns reviewers
ex:ReviewPreparation a ap:ProcessActivity ;
    skos:prefLabel "2. Review Preparation"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:performedBy ex:ChiefArchitect ;
    ap:follows ex:RequestSubmission ;
    ap:precedes ex:ReviewExecution ;
    ap:hasTask ex:TriageRequest, ex:AssignReviewers .

# Activity 3: The board evaluates the proposal
ex:ReviewExecution a ap:ProcessActivity ;
    skos:prefLabel "3. Review Execution"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:follows ex:ReviewPreparation ;
    ap:precedes ex:ReviewFollowUp ;
    ap:hasTask ex:IndividualReview, ex:BoardDiscussion, ex:RecordFindings .

ex:IndividualReview a ap:ProcessTask ;
    skos:prefLabel "Individual review by domain experts"@en ;
    ap:taskOfActivity ex:ReviewExecution ;
    ap:performedBy ex:SecurityArchitect .

# Activity 4: Follow-up and remediation tracking
ex:ReviewFollowUp a ap:ProcessActivity ;
    skos:prefLabel "4. Review Follow-Up"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:follows ex:ReviewExecution ;
    ap:hasTask ex:PublishReport, ex:TrackRemediation .

Milestones. Governance gates that must be passed before implementation can proceed.

ex:ReviewGate a ap:ProcessMilestone ;
    skos:prefLabel "Architecture Review Gate"@en ;
    skos:definition "Implementation may not proceed without board approval."@en ;
    ap:milestoneOfProcess ex:ArchReviewProcess ;
    ap:approvedBy ex:ChiefArchitect .

Inputs and outputs. What flows into and out of the process.

# Input: the proposal document
ex:ArchProposal a ap:InformationItem ;
    skos:prefLabel "Architecture Proposal Document"@en ;
    ap:consumedBy ex:ArchReviewProcess .

# Output: the review report
ex:ReviewReport a ap:ProcessDeliverable ;
    skos:prefLabel "Architecture Review Report"@en ;
    skos:definition "Formal report with findings, conditions, and the board decision."@en ;
    ap:producedBy ex:ArchReviewProcess ;
    ap:approvedBy ex:ChiefArchitect .

# Output: the formal decision (links to the decisions extension)
ex:ReviewDecision a ad:Decision ;
    skos:prefLabel "Architecture Review Board Decision"@en .

Standards vs Extension¶

A common question: why do we need both standards/iso42020/ and extensions/processes/?

The standards are reference vocabularies — they capture the normative terminology from ISO standards. Their concepts do not subclass arch:Element because they are not model elements; they are definitions you reference.

The extension provides practical model elements that you use in architecture views. Its classes subclass arch:Element so they can appear in diagrams, be governed by metamodels, and participate in relationships.

The extension references the standards via rdfs:seeAlso:

# In the extension (practical model element)
ap:ArchitectureProcess rdfs:seeAlso iso42020:Process .

# In your model (instance)
ex:MyReviewProcess a ap:ArchitectureProcess ;
    rdfs:seeAlso <https://meta.linked.archi/iso42020#ArchitectureGovernance> .

Querying Processes¶

# What deliverables does each process produce?
PREFIX ap: <https://meta.linked.archi/arch-processes#>

SELECT ?process ?processLabel ?deliverable ?deliverableLabel WHERE {
    ?deliverable ap:producedBy ?process .
    ?process skos:prefLabel ?processLabel .
    ?deliverable skos:prefLabel ?deliverableLabel .
}

# Which activities have no assigned performer? (governance gap)
PREFIX ap: <https://meta.linked.archi/arch-processes#>

SELECT ?activity ?label WHERE {
    ?activity a ap:ProcessActivity ;
              skos:prefLabel ?label .
    FILTER NOT EXISTS { ?activity ap:performedBy ?_ }
}

3. Reference Architecture (`refa:ref-arch`)¶

Why This Extension Exists¶

Architects don't design from scratch — they apply patterns, tactics, and reference architectures that encode proven solutions. But this reusable knowledge is usually trapped in books, wiki pages, and architects' heads. When someone asks "which patterns do we use for event processing?" or "what quality attributes does the Circuit Breaker tactic address?", the answer requires human memory.

The reference architecture extension makes reusable architectural knowledge into queryable, linked data. Patterns are connected to the tactics they contain. Tactics are connected to the quality attributes they address. Building blocks are connected to the patterns they implement. And all of this connects to the decisions extension — when an architect selects a pattern as part of a decision, the quality attribute trade-offs come along for free.

The extension is grounded in the academic work of Bass, Clements, Kazman ("Software Architecture in Practice"), Harrison & Avgeriou ("How do architecture patterns and tactics interact?"), and Farshidi et al. ("Capturing software architecture knowledge for pattern-driven design").

When to Use¶

Import this extension when your metamodel needs to:

Capture architectural patterns with their context, problem, and solution
Model tactics and their quality attribute trade-offs (addressed vs impacted)
Define reference architectures with applicable tactics
Classify building blocks as abstract (ABB) or concrete (SBB)
Analyze pattern-tactic interactions and compatibility
Connect decision options to the patterns and tactics they include

Key Concepts¶

A ReferenceArchitecture models abstract architectural elements independent of specific technologies. It defines what capabilities are needed without specifying how to implement them. Reference architectures have applicable tactics.

A Pattern is a general, reusable solution to a commonly occurring problem. Patterns are composed of context, problem, and solution descriptions. They contain tactics (appliedTactic), can be based on other patterns (basedOnPattern), and can contain sub-patterns (containsPattern). Patterns are categorized as Integration, Module, Allocation, or Deployment patterns.

A Tactic is a primitive design technique that addresses a specific quality attribute. Tactics are simpler than patterns — they use a single mechanism. The key properties are addressedQA (the quality attribute the tactic is designed to improve) and impactedQA (quality attributes affected as a side effect, positively or negatively).

ABB (Architecture Building Block) is an abstract capability — "we need an API Gateway." SBB (Solution Building Block) is a concrete implementation — "we'll use Kong." ABBs are refined into SBBs during solution design.

Example: Microservices Resilience Patterns¶

This example models a set of resilience patterns and tactics for a microservices architecture, showing how patterns contain tactics, tactics address quality attributes, and building blocks implement patterns.

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

Tactics. Each tactic addresses specific quality attributes and may impact others as a side effect. The appliedWithTactic property captures tactics that are commonly used together.

ex:CircuitBreakerTactic a refa:Tactic ;
    skos:prefLabel "Circuit Breaker"@en ;
    skos:definition """Detect failures and prevent cascading by failing fast
    when a downstream service is unavailable."""@en ;
    refa:addressedQA iso25010:Availability, iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour .

ex:RetryTactic a refa:Tactic ;
    skos:prefLabel "Retry with Exponential Backoff"@en ;
    skos:definition "Retry failed requests with increasing delays and jitter."@en ;
    refa:addressedQA iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour ;
    refa:appliedWithTactic ex:CircuitBreakerTactic .

ex:BulkheadTactic a refa:Tactic ;
    skos:prefLabel "Bulkhead Isolation"@en ;
    skos:definition "Isolate resource pools per dependency to prevent cascading exhaustion."@en ;
    refa:addressedQA iso25010:Availability ;
    refa:impactedQA iso25010:ResourceUtilization ;
    refa:relatedTactic ex:CircuitBreakerTactic .

ex:LoadBalancingTactic a refa:Tactic ;
    skos:prefLabel "Load Balancing"@en ;
    refa:addressedQA iso25010:Availability, iso25010:Capacity ;
    refa:broaderTactic ex:RedundancyTactic .

Patterns. Patterns contain tactics and can be composed hierarchically. The realizesTactic property means the pattern's primary purpose is to implement that tactic. The appliedTactic property means the tactic is used within the pattern but isn't its primary purpose.

ex:CircuitBreakerPattern a refa:IntegrationPattern ;
    skos:prefLabel "Circuit Breaker"@en ;
    skos:definition """Prevents cascading failures by wrapping remote calls in a
    circuit that opens (fails fast) when error rates exceed a threshold."""@en ;
    refa:patternContext "Distributed system with synchronous inter-service calls."@en ;
    refa:patternProblemOverview
        "A failing downstream service causes cascading timeouts."@en ;
    refa:patternSolutionOverview
        "A state machine (closed/open/half-open) that short-circuits failing calls."@en ;
    refa:realizesTactic ex:CircuitBreakerTactic ;
    refa:appliedTactic ex:RetryTactic .

ex:APIGatewayPattern a refa:IntegrationPattern ;
    skos:prefLabel "API Gateway"@en ;
    skos:definition """Single entry point for all client requests. Routes, authenticates,
    rate-limits, and aggregates responses."""@en ;
    refa:appliedTactic ex:LoadBalancingTactic, ex:RateLimitingTactic ;
    refa:containsPattern ex:BackendForFrontendPattern .

ex:BackendForFrontendPattern a refa:IntegrationPattern ;
    skos:prefLabel "Backend for Frontend (BFF)"@en ;
    refa:basedOnPattern ex:APIGatewayPattern ;
    refa:partOfPattern ex:APIGatewayPattern .

Reference architecture. Ties patterns and tactics together into a coherent architectural approach.

ex:MicroservicesRefArch a refa:ReferenceArchitecture ;
    skos:prefLabel "Microservices Reference Architecture"@en ;
    skos:definition """Reference architecture for distributed systems as independently
    deployable services communicating via APIs and messaging."""@en ;
    refa:applicableTactic ex:CircuitBreakerTactic, ex:RetryTactic,
                          ex:BulkheadTactic, ex:LoadBalancingTactic .

Building blocks. ABBs define what capability is needed; SBBs define what product implements it.

# Abstract: what capability do we need?
ex:APIGatewayABB a refa:ABB ;
    skos:prefLabel "API Gateway"@en ;
    skos:definition "Unified API entry point with routing, auth, and rate limiting."@en ;
    refa:implementsPattern ex:APIGatewayPattern .

ex:ServiceMeshABB a refa:ABB ;
    skos:prefLabel "Service Mesh"@en ;
    skos:definition "Transparent inter-service communication with observability."@en ;
    refa:implementsTactic ex:CircuitBreakerTactic, ex:RetryTactic .

# Concrete: what product implements it?
ex:KongGateway a refa:SBB ;
    skos:prefLabel "Kong API Gateway"@en ;
    refa:implementsPattern ex:APIGatewayPattern .

ex:IstioMesh a refa:SBB ;
    skos:prefLabel "Istio Service Mesh"@en ;
    refa:implementsTactic ex:CircuitBreakerTactic, ex:RetryTactic .

Tactic impact analysis. How does applying a tactic affect a specific pattern? The ImpactOfTactic class captures this with precision — which elements are already covered, which need to be added, which need modification.

ex:CircuitBreakerImpactOnGateway a refa:ImpactOfTactic ;
    skos:prefLabel "Circuit Breaker impact on API Gateway"@en ;
    refa:impactOfTactic ex:CircuitBreakerTactic ;
    refa:impactMeasure "medium"^^xsd:string ;
    refa:implementedAlreadyInElement ex:KongGateway ;
    refa:addsNewElement ex:CircuitBreakerSidecar .

ex:APIGatewayPattern refa:hasImpactOfTactic ex:CircuitBreakerImpactOnGateway .

Querying Patterns and Tactics¶

# Which tactics address availability? What patterns use them?
PREFIX refa:     <https://meta.linked.archi/ref-arch#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?tactic ?tacticLabel ?pattern ?patternLabel WHERE {
    ?tactic refa:addressedQA iso25010:Availability ;
            skos:prefLabel ?tacticLabel .
    { ?pattern refa:appliedTactic ?tactic }
    UNION
    { ?pattern refa:realizesTactic ?tactic }
    ?pattern skos:prefLabel ?patternLabel .
}

# For each ABB, which SBBs implement the same pattern?
PREFIX refa: <https://meta.linked.archi/ref-arch#>

SELECT ?abb ?abbLabel ?sbb ?sbbLabel ?pattern WHERE {
    ?abb a refa:ABB ;
         skos:prefLabel ?abbLabel ;
         refa:implementsPattern ?pattern .
    ?sbb a refa:SBB ;
         skos:prefLabel ?sbbLabel ;
         refa:implementsPattern ?pattern .
}

Pattern Hierarchy¶

refa:Pattern
  ├── refa:ArchitecturalPattern
  │     ├── refa:IntegrationPattern    (component-and-connector: Circuit Breaker, API Gateway)
  │     ├── refa:ModulePattern         (code-time: Layered, Hexagonal)
  │     └── refa:AllocationPattern     (software-to-hardware: Active-Passive, Leader-Follower)
  └── refa:DeploymentPattern           (infrastructure: Blue-Green, Canary, Rolling)

4. Composing Extensions — A Complete Scenario¶

The real power of extensions emerges when they work together. This section walks through a complete scenario: an ADD (Attribute-Driven Design) iteration where a governance process produces a decision that selects a pattern with tactics addressing quality requirements.

Scenario: Payment Service Resilience¶

The Payment Service is experiencing cascading failures when the downstream payment gateway becomes unreachable. The architecture team needs to select a resilience strategy through a formal governance process.

Step 1 — The Governance Process (ap:)¶

The ADD iteration is modeled as a process with activities, a responsible role, and outputs.

@prefix ap:   <https://meta.linked.archi/arch-processes#> .
@prefix ad:   <https://meta.linked.archi/arch-decision#> .
@prefix refa: <https://meta.linked.archi/ref-arch#> .
@prefix am:   <https://meta.linked.archi/archimate3/onto#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix ex:   <https://model.example.com/combined#> .

ex:ADDIteration1 a ap:ArchitectureProcess ;
    skos:prefLabel "ADD Iteration 1 — Establish Resilience Strategy"@en ;
    ap:hasActivity ex:IdentifyDrivers, ex:SelectPattern, ex:RecordDecision ;
    ap:output ex:ADR-101 .

ex:LeadArchitect a ap:ProcessRole ;
    skos:prefLabel "Lead Architect"@en ;
    ap:responsibleFor ex:ADDIteration1 .

ex:IdentifyDrivers a ap:ProcessActivity ;
    skos:prefLabel "Identify Architectural Drivers"@en ;
    ap:activityOfProcess ex:ADDIteration1 ;
    ap:performedBy ex:LeadArchitect ;
    ap:precedes ex:SelectPattern .

ex:SelectPattern a ap:ProcessActivity ;
    skos:prefLabel "Select Pattern and Tactics"@en ;
    ap:activityOfProcess ex:ADDIteration1 ;
    ap:follows ex:IdentifyDrivers ;
    ap:precedes ex:RecordDecision .

ex:RecordDecision a ap:ProcessActivity ;
    skos:prefLabel "Record Architecture Decision"@en ;
    ap:activityOfProcess ex:ADDIteration1 ;
    ap:follows ex:SelectPattern .

ex:ResilienceGate a ap:ProcessMilestone ;
    skos:prefLabel "Resilience Design Gate"@en ;
    skos:definition "Implementation may not proceed without approved resilience design."@en ;
    ap:milestoneOfProcess ex:ADDIteration1 .

Step 2 — The Forces (ad:)¶

The "Identify Drivers" activity produces the forces that will influence the decision. Quality attribute requirements use the full QAS structure.

ex:AvailabilityReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Payment Service 99.99% Availability"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasStimulus "Downstream payment gateway becomes unreachable"@en ;
    ad:qasEnvironment "Normal operation, peak transaction volume"@en ;
    ad:qasArtifact ex:PaymentService ;
    ad:qasResponse "Service queues transactions and retries when gateway recovers"@en ;
    ad:qasResponseMeasure "99.99% uptime, zero lost transactions"@en .

ex:FaultToleranceReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Graceful Degradation Under Partial Failure"@en ;
    ad:onQualityAttribute iso25010:FaultTolerance ;
    ad:qasStimulus "One of three payment gateway providers fails"@en ;
    ad:qasResponse "Service routes to remaining providers without user impact"@en ;
    ad:qasResponseMeasure "Failover within 5 seconds, no transaction loss"@en .

ex:LatencyConstraint a ad:TechnicalConstraint ;
    skos:prefLabel "Payment Latency SLA"@en ;
    skos:definition "Payment confirmation must complete within 2 seconds."@en .

Step 3 — The Options with Patterns (ad: + refa:)¶

The "Select Pattern" activity evaluates options. Each option includes patterns and tactics from the reference architecture extension. This is where the extensions compose — the decision's option includes a pattern, and that pattern contains tactics that address quality attributes.

# Option A includes the Circuit Breaker pattern
ex:CircuitBreakerOption a ad:Option ;
    skos:prefLabel "Option A — Circuit Breaker with Retry"@en ;
    skos:definition """Wrap payment gateway calls in a circuit breaker with
    exponential backoff retry."""@en ;
    ad:addressesForce ex:AvailabilityReq, ex:FaultToleranceReq ;
    ad:includesConcept ex:CircuitBreakerPattern ;
    ad:addsConcept ex:RetryQueue, ex:DeadLetterQueue .

# The pattern and its tactics (from the ref-arch extension)
ex:CircuitBreakerPattern a refa:IntegrationPattern ;
    skos:prefLabel "Circuit Breaker"@en ;
    refa:realizesTactic ex:CircuitBreakerTactic ;
    refa:appliedTactic ex:RetryTactic .

ex:CircuitBreakerTactic a refa:Tactic ;
    skos:prefLabel "Circuit Breaker"@en ;
    refa:addressedQA iso25010:Availability, iso25010:FaultTolerance ;
    refa:impactedQA iso25010:TimeBehaviour .

ex:RetryTactic a refa:Tactic ;
    skos:prefLabel "Retry with Exponential Backoff"@en ;
    refa:addressedQA iso25010:FaultTolerance ;
    refa:appliedWithTactic ex:CircuitBreakerTactic .

# Option B — a different approach
ex:MultiProviderOption a ad:Option ;
    skos:prefLabel "Option B — Active-Active Multi-Provider"@en ;
    ad:addressesForce ex:AvailabilityReq, ex:FaultToleranceReq ;
    ad:addsConcept ex:ProviderRouter, ex:HealthChecker ;
    ad:hasRisk [ skos:prefLabel "Inconsistent behavior across providers"@en ] .

Step 4 — The Decision (ad:) — Output of the Process¶

The "Record Decision" activity produces the formal decision. It links back to the process that produced it, the issue it resolves, the forces that drove it, and the elements it affects.

ex:PaymentResilienceIssue a ad:Issue ;
    skos:prefLabel "Payment gateway failures cause cascading timeouts"@en ;
    ad:problemStatement """When the primary payment gateway becomes unreachable,
    the Payment Service blocks on connection timeouts, exhausting the thread
    pool and halting all payment processing."""@en ;
    ad:influencingForce ex:AvailabilityReq, ex:FaultToleranceReq .

ex:ADR-101 a ad:Decision ;
    skos:prefLabel "ADR-101: Use Circuit Breaker for payment resilience"@en ;
    ad:hasIssue ex:PaymentResilienceIssue ;
    ad:hasSelectedOption ex:CircuitBreakerOption ;
    ad:hasAlternative ex:MultiProviderOption ;
    ad:influencedByForce ex:AvailabilityReq, ex:FaultToleranceReq, ex:LatencyConstraint ;
    ad:relatedConcept ex:PaymentService ;
    ad:justification """Circuit Breaker with retry provides the required fault tolerance
    with minimal latency overhead. The multi-provider option was rejected because
    it introduces provider-specific logic. The circuit breaker pattern is supported
    by the existing Istio service mesh."""@en .

ex:PaymentService a am:ApplicationComponent ;
    skos:prefLabel "Payment Service"@en .

The Full Trace¶

With all three extensions composed, you can trace the complete chain:

Governance Process (ap:)          Decision (ad:)              Pattern (refa:)
─────────────────────             ──────────────              ───────────────
ADDIteration1                     ADR-101                     CircuitBreakerPattern
  ├─ IdentifyDrivers                ├─ hasIssue                 ├─ realizesTactic
  ├─ SelectPattern                  ├─ hasSelectedOption          │   └─ CircuitBreakerTactic
  └─ RecordDecision                 │    └─ includesConcept ──────┤       ├─ addressedQA → Availability
       └─ output ──────────────────►│                             │       └─ impactedQA → TimeBehaviour
                                    ├─ influencedByForce          └─ appliedTactic
                                    │    └─ AvailabilityReq           └─ RetryTactic
                                    │         └─ onQualityAttribute       └─ addressedQA → FaultTolerance
                                    │              └─ iso25010:Availability
                                    └─ relatedConcept
                                         └─ PaymentService (am:ApplicationComponent)

Cross-Extension SPARQL¶

This query traverses all three extensions to answer: "For each decision, what quality attributes were addressed, through which patterns and tactics?"

PREFIX ad:       <https://meta.linked.archi/arch-decision#>
PREFIX refa:     <https://meta.linked.archi/ref-arch#>
PREFIX ap:       <https://meta.linked.archi/arch-processes#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?process ?decision ?pattern ?tactic ?qualityAttribute WHERE {
    # Process produced the decision
    ?process a ap:ArchitectureProcess ;
             ap:output ?decision .

    # Decision selected an option that includes a pattern
    ?decision a ad:Decision ;
              ad:hasSelectedOption ?option .
    ?option ad:includesConcept ?pattern .

    # Pattern contains tactics that address quality attributes
    ?pattern a refa:Pattern .
    { ?pattern refa:realizesTactic ?tactic }
    UNION
    { ?pattern refa:appliedTactic ?tactic }
    ?tactic refa:addressedQA ?qualityAttribute .
}

Topic	Document
Working examples	`examples/extensions/` — Complete Turtle files for each extension
Core ontology classes	Ontology Reference
Design rationale	Design Decisions — DD-12 (Force naming), DD-11 (ReferenceModel)
Standards alignment	Standards Alignment — How standards relate to extensions
Real-world scenarios	Use Cases — UC-3 (decisions), UC-4 (governance), UC-10 (processes)
Creating a metamodel	Quick Start Guide

Extensions Guide¶

Overview¶

How Extensions Compose¶

1. Architecture Decisions (ad:arch-decision)¶

Why This Extension Exists¶

When to Use¶

The Decision Lifecycle¶

Example: Database Scaling Decision¶

Querying Decisions¶

Force Hierarchy¶

2. Architecture Processes (ap:arch-processes)¶

Why This Extension Exists¶

When to Use¶

The Process Decomposition¶

Example: Architecture Review Board¶

Standards vs Extension¶

Querying Processes¶

3. Reference Architecture (refa:ref-arch)¶

Why This Extension Exists¶

When to Use¶

Key Concepts¶

Example: Microservices Resilience Patterns¶

Querying Patterns and Tactics¶

Pattern Hierarchy¶

4. Composing Extensions — A Complete Scenario¶

Scenario: Payment Service Resilience¶

Step 1 — The Governance Process (ap:)¶

Step 2 — The Forces (ad:)¶

Step 3 — The Options with Patterns (ad: + refa:)¶

Step 4 — The Decision (ad:) — Output of the Process¶

The Full Trace¶

Cross-Extension SPARQL¶

Further Reading¶

1. Architecture Decisions (`ad:arch-decision`)¶

2. Architecture Processes (`ap:arch-processes`)¶

3. Reference Architecture (`refa:ref-arch`)¶