Frameworks Guide¶

Linked.Archi integrates several enterprise architecture frameworks as semantic assets. Each framework is modeled at the level of detail appropriate to its nature — some are full metamodels with elements and relationships, others are classification taxonomies, and some provide specialized assessment models.

This guide explains what each framework provides, its current relevance, and how it fits into the Linked.Archi ecosystem.

Overview¶

Framework	Type	Assets	Primary Value
TOGAF	Full metamodel	onto, metamodel, tax, viewpoints, deliverable-templates	Enterprise architecture governance and content metamodel
DoDAF	Full metamodel	onto, metamodel, tax, viewpoints	Defense architecture descriptions — 8 viewpoints, 52 models
ADMIT	Ontology + taxonomy	onto, tax, metamodel	Design forces checklist and architecture scoping
TIME	Assessment ontology	onto, tax, metamodel	Application portfolio rationalization
Zachman	Classification taxonomy	taxonomy	Artifact classification by perspective and interrogative
Platform Design	Vocabulary taxonomy	taxonomy	Platform business design concepts
EA on a Page	Full metamodel	onto, tax, metamodel, viewpoints, deliverable-templates, shapes	Evidence-based CSVLOD artifact taxonomy, EA processes, governance, maturity
ATAM	Evaluation ontology	onto, metamodel	Architecture tradeoff analysis — utility trees, sensitivity/tradeoff points, risks
ADD	Method alignment	— (covered by `ad:arch-decision` + `refa:ref-arch`)	Attribute-driven design — iterative quality-driven architecture design

TOGAF¶

Status: Complete semantic asset set Source: The Open Group — TOGAF Standard Namespace: https://meta.linked.archi/togaf/onto#

TOGAF is the most widely adopted enterprise architecture framework. The Linked.Archi representation covers the Content Metamodel (entity types and relationships), the ADM phase taxonomy, 60 viewpoints (catalogs, matrices, diagrams organized by ADM phase), 8 stakeholder roles, and 5 deliverable templates with SPARQL queries.

Assets¶

File	Namespace	Content
`togaf-onto.ttl`	`https://meta.linked.archi/togaf/onto#`	36 entity classes, 13 relationship types
`togaf-metamodel.ttl`	`https://meta.linked.archi/togaf/metamodel#`	Metamodel manifest
`togaf-tax.ttl`	`https://meta.linked.archi/togaf/tax#`	ADM phases and concept classification
`togaf-vp.ttl`	`https://meta.linked.archi/togaf/viewpoints#`	60 viewpoints, 8 stakeholders
`togaf-deliverable-templates.ttl`	`https://meta.linked.archi/togaf/deliverable-templates#`	5 document templates with SPARQL

Relevance¶

TOGAF remains the dominant EA framework globally. The Open Group actively maintains it (TOGAF 10 released 2022). The Content Metamodel provides a comprehensive set of entity types that map well to ArchiMate elements, enabling cross-framework queries.

DoDAF¶

Status: Full semantic asset set (ontology, taxonomy, viewpoints, metamodel manifest) Source: DoDAF V2.02 — U.S. Department of Defense Namespace: https://meta.linked.archi/dodaf/onto#

The U.S. Department of Defense Architecture Framework (DoDAF) is the standard for defense architecture descriptions. DoDAF 2.0 (2010) shifted from rigid "products" to a data-centric approach with "Fit-for-Purpose" presentation — the framework defines the underlying data model, and architects create views tailored to each decision-maker's needs.

DoDAF organizes architectural data into 8 viewpoints containing 52 DoDAF-described Models. It has influenced NATO Architecture Framework (NAF) and the British Ministry of Defence Architecture Framework (MODAF).

Assets¶

File	Namespace	Content
`dodaf-onto.ttl`	`https://meta.linked.archi/dodaf/onto#`	22 entity classes, 10 relationship types
`dodaf-tax.ttl`	`https://meta.linked.archi/dodaf/tax#`	SKOS taxonomy classifying entities by the 8 viewpoints
`dodaf-vp.ttl`	`https://meta.linked.archi/dodaf/viewpoints#`	28 viewpoint individuals, 9 stakeholders
`dodaf-metamodel.ttl`	`https://meta.linked.archi/dodaf/metamodel#`	Metamodel manifest

Viewpoints¶

Viewpoint	Models	Focus
All (AV)	AV-1, AV-2	Overarching context — overview, integrated dictionary
Capability (CV)	CV-1 through CV-7	Capability requirements, phasing, dependencies, mappings
Data & Information (DIV)	DIV-1, DIV-2, DIV-3	Conceptual, logical, and physical data models
Operational (OV)	OV-1 through OV-6c	Operational scenarios, activities, resource flows, rules, state transitions
Project (PV)	PV-1, PV-2, PV-3	Portfolio relationships, timelines, capability mapping
Services (SvcV)	SvcV-1 through SvcV-10c	Service-oriented solution design
Standards (StdV)	StdV-1, StdV-2	Standards profile and forecast
Systems (SV)	SV-1 through SV-10c	Legacy system descriptions

Relevance¶

DoDAF remains the mandated framework for U.S. Department of Defense architecture descriptions. Its influence extends to NATO (NAF v4) and allied defense organizations. The data-centric approach of DoDAF 2.0 aligns well with Linked.Archi's knowledge graph philosophy — both treat architectural data as the primary asset, with views as derived presentations.

The Data and Information Viewpoint (DIV-1/2/3) is particularly relevant to the ML-enabled systems discussion (Moin et al. 2023) — it provides the three-level data modeling pattern (conceptual → logical → physical) that the article contrasts with the missing ML data viewpoints.

How to Use DoDAF in Linked.Archi¶

@prefix dodaf: <https://meta.linked.archi/dodaf/onto#> .
@prefix ex:    <https://model.example.com/defense#> .

ex:ISRCapability a dodaf:Capability ;
    skos:prefLabel "Intelligence, Surveillance, and Reconnaissance"@en .

ex:TargetDetection a dodaf:OperationalActivity ;
    skos:prefLabel "Detect and Classify Targets"@en .

ex:ISRCapability dodaf:supports ex:TargetDetection .

ex:SensorFusionSystem a dodaf:System ;
    skos:prefLabel "Sensor Fusion System"@en ;
    dodaf:supports ex:TargetDetection .

Cross-framework query — map DoDAF capabilities to TOGAF business services:

PREFIX dodaf: <https://meta.linked.archi/dodaf/onto#>
PREFIX togaf: <https://meta.linked.archi/togaf/onto#>

SELECT ?capability ?capLabel ?service ?svcLabel WHERE {
    ?capability a dodaf:Capability ; skos:prefLabel ?capLabel .
    ?service a togaf:BusinessService ; skos:prefLabel ?svcLabel .
    ?service togaf:supports ?capability .
}

ADMIT¶

Status: Ontology + taxonomy with metamodel manifest Source: IT Architecture Design Framework: ADMIT — InfoQ (2013) Author: Prasad Rao Namespace: https://meta.linked.archi/admit/onto#

ADMIT (Architecture-Driven Modernization of IT) is a practical architecture framework published as a single InfoQ article in 2013. It has not been updated since publication and has no active community, tooling, or certification program.

Assets¶

File	Namespace	Content
`admit-onto.ttl`	`admit/onto#`	20 design force classes (`rdfs:subClassOf ad:Force`)
`admit-tax.ttl`	`admit/tax#`	SKOS taxonomy (levels, domains, resources, lifecycle)
`admit-metamodel.ttl`	`admit/metamodel#`	Metamodel manifest

What ADMIT Provides¶

ADMIT defines five concept groups:

Architecture Levels — Enterprise, Solution, System. The standard three-tier scoping model used across the industry. Maps to organizational hierarchy (company, department, team).
Architecture Domains — Business (Why), Information/Data (What), Application/Service (How), Technology (Where). The four standard EA domains, identical to TOGAF's four architecture domains.
Architecture and Resource Dimensions — Workload, Demand, Throughput, Latency, Capacity, Redundancy. The fundamental dimensions for infrastructure sizing and performance architecture.
Architecture Design Forces (ADF) — 20 forces organized into a checklist for systematic architecture decision-making. These are modeled as owl:Class rdfs:subClassOf ad:Force, making them usable with the architecture decisions extension.
Architecture Development Lifecycle (ADLC) — A 15-process lifecycle in five phases: Planning/Strategy, Design/Execution, Management/Governance, Optimization, Automation.

Relevance Assessment¶

Concept Group	Still Relevant?	Notes
Architecture Levels	Yes	Universal scoping concept. TOGAF, SAFe, and most EA practices use the same three tiers.
Architecture Domains	Yes	The four standard EA domains. Unchanged since the 1990s.
Design Forces	Yes	The most valuable part of ADMIT. A practical 20-item checklist covering business, operations, aesthetics, future-proofing, simplicity, change, process, integration, patterns, enterprise concerns, constraints, failure, channels, content, platform, infrastructure, network, storage, security, and cost. These are timeless architecture concerns.
Resource Dimensions	Yes	Workload, Demand, Throughput, Latency, Capacity, Redundancy remain the fundamental dimensions. Cloud made them elastic, not obsolete.
Development Lifecycle	Partially	A simplified TOGAF ADM. Doesn't add much beyond what TOGAF provides. Predates continuous architecture, evolutionary architecture, and architecture-as-code approaches.

What's Missing (Post-2013 Concerns)¶

ADMIT predates several major architectural paradigms:

Cloud-native architecture and serverless
DevOps and platform engineering
API-first and event-driven design
Data mesh and data products
Site reliability engineering (SRE)
Zero-trust security architecture
AI/ML integration patterns

The design forces are generic enough to accommodate these (e.g., the Platform Force covers cloud platforms, the Security Force covers zero-trust), but the framework doesn't address them explicitly.

How to Use ADMIT in Linked.Archi¶

The primary value of ADMIT in Linked.Archi is the design forces. They are modeled as OWL classes extending ad:Force from the architecture decisions extension, so they can be used directly in architecture decision records:

@prefix ad:    <https://meta.linked.archi/arch-decision#> .
@prefix admit: <https://meta.linked.archi/admit/onto#> .
@prefix ex:    <https://model.example.com/myarch#> .

# Use ADMIT forces in a decision record
ex:PerformanceForce a admit:OperationForce ;
    skos:prefLabel "Payment latency SLA"@en ;
    ad:hasImportanceMeasure "critical" .

ex:BudgetForce a admit:CostForce ;
    skos:prefLabel "Infrastructure budget limit"@en .

ex:ADR-001 a ad:Decision ;
    ad:influencedByForce ex:PerformanceForce, ex:BudgetForce .

The architecture levels are useful for scoping architecture work:

@prefix admit: <https://meta.linked.archi/admit/tax#> .

# Tag a model with its architecture level
ex:MyModel a arch:Model ;
    arch:modelScope admit:SolutionArchitecture .

TIME Framework¶

Status: Full assessment ontology with metamodel manifest Source: Gartner TIME Model | SAP LeanIX TIME Documentation | LeanIX Wiki Namespace: https://meta.linked.archi/time-framework/onto#

The TIME (Tolerate, Invest, Migrate, Eliminate) framework is Gartner's model for application portfolio rationalization. It classifies applications into four quadrants based on functional fit (business value) and technical fit (technical health).

Assets¶

File	Namespace	Content
`time-onto.ttl`	`time-framework/onto#`	9 classes, 20+ properties, 6 enumeration types, OWL quadrant classification
`time-tax.ttl`	`time-framework/tax#`	6 SKOS ConceptSchemes for controlled vocabularies
`time-shapes.ttl`	`time-framework/shapes#`	SHACL shapes for validation (required fields, value constraints, score ranges)
`time-metamodel.ttl`	`time-framework/metamodel#`	Metamodel manifest
`examples/time-framework-d3-demo.html`	—	Interactive D3 visualization
`examples/time-framework-example-data.jsonld`	—	Example assessment data

What TIME Provides¶

The TIME ontology is the most complete framework ontology after TOGAF. It defines:

Core classes: - timefw:Application — an application in the portfolio - timefw:FitAssessment — a point-in-time assessment with functional and technical fit scores - timefw:FitCriterion — a criterion used to evaluate fit (e.g., capability coverage, maintainability) - timefw:FitCriterionScore — a scored evaluation of one criterion - timefw:Evidence — supporting evidence (security reports, vendor roadmaps, operations metrics) - timefw:TimeAssessmentModel — the scoring model (scale, thresholds) - timefw:Person — assessors and owners

Controlled vocabularies: - TIME dispositions: Tolerate, Invest, Migrate, Eliminate - Fit ratings: High, Low - Fit dimensions: Functional, Technical, Cost - Assessment statuses: Draft, Approved, Superseded, Rejected - Evidence types: Architecture Review, Security Assessment, Operations Metrics, Cost Analysis, etc. - Lifecycle states: Plan, Build, Run, Retire

OWL classification: The ontology includes OWL equivalent class definitions that automatically classify assessments into TIME quadrants based on their fit ratings: - High functional + High technical = Invest - High functional + Low technical = Migrate - Low functional + High technical = Tolerate - Low functional + Low technical = Eliminate

Relevance¶

TIME is actively used across the industry. SAP LeanIX, Ardoq, and other EA tools implement it natively. The model is simple, actionable, and well-understood by business stakeholders. It's the standard approach for application portfolio rationalization.

Why Both an Ontology and a Taxonomy?¶

The TIME framework is split into three layers — time-onto.ttl (OWL), time-shapes.ttl (SHACL), and time-tax.ttl (SKOS) — because they serve different consumers:

Concern	Ontology (`time-onto.ttl`)	Shapes (`time-shapes.ttl`)	Taxonomy (`time-tax.ttl`)
Purpose	Define structure, enable reasoning	Validate completeness and correctness	Organize concepts for navigation
World assumption	Open (infers new facts)	Closed (flags missing data)	N/A (classification)
Contains	Classes, properties, OWL restrictions, enumeration individuals	NodeShapes with cardinalities, value constraints, score ranges	SKOS ConceptSchemes grouping individuals
Used by	DL reasoners, SPARQL queries, model authoring	SHACL validators, CI/CD pipelines, data quality checks	Documentation generators, UI dropdowns, faceted search
Example	`owl:equivalentClass` auto-classifies High/High → InvestAssessment	`sh:in (Tolerate Invest Migrate Eliminate)` rejects invalid values	`skos:hasTopConcept` lists dispositions for a dropdown

The individuals (timefw:Tolerate, timefw:Invest, etc.) are dual-typed as both owl:NamedIndividual, timefw:TimeDisposition and skos:Concept. This is not punning — it's multi-typing. The OWL type enables a reasoner to classify assessments automatically. The SKOS type enables docgen to render a navigable tree. The SHACL shapes use sh:in to enforce the same values as closed-world constraints.

Concrete example — the same four TIME dispositions are used by all three layers:

# OWL (time-onto.ttl) — defines the enumeration and enables reasoning
timefw:TimeDisposition
    a owl:Class ;
    owl:oneOf ( timefw:Tolerate timefw:Invest timefw:Migrate timefw:Eliminate ) .

timefw:InvestAssessment
    owl:equivalentClass [
        owl:intersectionOf (
            timefw:FitAssessment
            [ owl:onProperty timefw:functionalFitRating ; owl:hasValue timefw:High ]
            [ owl:onProperty timefw:technicalFitRating ; owl:hasValue timefw:High ]
        )
    ] .

# SHACL (time-shapes.ttl) — validates that every assessment has a valid disposition
:FitAssessmentShape a sh:NodeShape ;
    sh:targetClass timefw:FitAssessment ;
    sh:property [
        sh:path     timefw:timeDisposition ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:in       ( timefw:Tolerate timefw:Invest timefw:Migrate timefw:Eliminate ) ;
        sh:message  "Every FitAssessment must have a valid timeDisposition."@en ;
    ] .

# SKOS (time-tax.ttl) — UI dropdown query
PREFIX timetax: <https://meta.linked.archi/time-framework/tax#>

SELECT ?disposition ?label WHERE {
    timetax:TimeDispositionScheme skos:hasTopConcept ?disposition .
    ?disposition skos:prefLabel ?label .
}

This three-layer pattern (OWL for structure, SHACL for validation, SKOS for navigation) follows the Linked.Archi design principles — see DD-2: Minimal OWL Profile with SHACL Constraints and DD-5: SKOS for Taxonomies and Classification. TIME is the only framework that uses OWL restrictions beyond the minimal profile, because automatic quadrant classification is the core value proposition of the TIME model.

How to Use TIME in Linked.Archi¶

@prefix timefw: <https://meta.linked.archi/time-framework/onto#> .
@prefix ex:     <https://model.example.com/portfolio#> .

ex:LegacyCRM a timefw:Application ;
    skos:prefLabel "Legacy CRM System"@en ;
    timefw:businessOwner ex:SalesDirector ;
    timefw:lifecycleState timefw:Run ;
    timefw:hasFitAssessment ex:CRM-Assessment-2026 .

ex:CRM-Assessment-2026 a timefw:FitAssessment ;
    timefw:assessmentDate "2026-03-15"^^xsd:date ;
    timefw:functionalFitScore 4 ;
    timefw:technicalFitScore 2 ;
    timefw:functionalFitRating timefw:High ;
    timefw:technicalFitRating timefw:Low ;
    timefw:timeDisposition timefw:Migrate ;
    timefw:rationale "Strong business fit but aging technology stack (Java 8, on-prem only)."@en ;
    timefw:assessmentStatus timefw:Approved .

Query for migration candidates:

PREFIX timefw: <https://meta.linked.archi/time-framework/onto#>

SELECT ?app ?label ?funcScore ?techScore WHERE {
    ?app a timefw:Application ;
         skos:prefLabel ?label ;
         timefw:hasFitAssessment ?assess .
    ?assess timefw:timeDisposition timefw:Migrate ;
            timefw:functionalFitScore ?funcScore ;
            timefw:technicalFitScore ?techScore ;
            timefw:assessmentStatus timefw:Approved .
}
ORDER BY ?techScore

Zachman Framework¶

Status: Classification taxonomy Source: Zachman International Author: John Zachman (1987) Namespace: https://meta.linked.archi/zachman#

The Zachman Framework is a 6×6 classification schema for enterprise architecture artifacts. It is not a methodology — it does not prescribe how to create artifacts, but rather how to classify them by the intersection of stakeholder perspective and descriptive focus.

Assets¶

File	Namespace	Content
`zachman.ttl`	`https://meta.linked.archi/zachman#`	SKOS taxonomy: 6 interrogatives, 6 perspectives

What Zachman Provides¶

Interrogatives (columns) — the six fundamental questions: - What (Data), How (Function), Where (Network), Who (People), When (Time), Why (Motivation)

Perspectives (rows) — six stakeholder viewpoints representing progressive reification: - Executive/Planner → Business Management/Owner → Architect/Designer → Engineer/Builder → Technician/Implementer → User/Worker

Relevance¶

The Zachman Framework is historically significant (1987) and still referenced in EA education and certification programs. However, it's rarely used as a primary framework in practice — most organizations use TOGAF, ArchiMate, or C4 for actual architecture work. Its value is as a classification lens: "have we covered all perspectives and all interrogatives?"

In Linked.Archi, the Zachman taxonomy is useful for tagging architecture artifacts with their perspective and focus, enabling completeness analysis.

How to Use Zachman in Linked.Archi¶

@prefix zach: <https://meta.linked.archi/zachman#> .

# Tag a viewpoint with its Zachman classification
ex:DataModelViewpoint a arch:Viewpoint ;
    skos:prefLabel "Logical Data Model"@en ;
    arch:viewpointCoversAspect zach:What ;
    arch:viewpointFromPerspective zach:ArchitectPerspective .

Platform Design¶

Status: Vocabulary taxonomy Source: Platform Design Toolkit Author: Simone Cicero Namespace: https://meta.linked.archi/platform-design#

A SKOS taxonomy capturing the key concepts of platform business design — stakeholders (consumer, producer, enabler, keystone), assets, capabilities, stories, needs, solutions, touchpoints, value exchange, compensation, and channels.

Assets¶

File	Namespace	Content
`pd-tax.ttl`	`https://meta.linked.archi/platform-design#`	SKOS concept scheme with 15 concepts

Relevance¶

Platform design is increasingly relevant as organizations build platform ecosystems (API platforms, marketplace platforms, developer platforms). The taxonomy provides the vocabulary for describing platform stakeholders and their interactions. It complements the Backstage modeling language (which focuses on the developer portal catalog) with the broader platform business model perspective.

EA on a Page (Kotusev)¶

Status: Full semantic asset set (ontology, taxonomy, metamodel, viewpoints, deliverable templates, SHACL shapes) Source: EA on a Page | BCS Article — Artifacts | BCS Article — Practice Author: Svyatoslav Kotusev Academic source: Kotusev, S. (2019). Enterprise architecture and enterprise architecture artifacts. Journal of Information Technology, 34(2), 102-128. Namespace: https://meta.linked.archi/eaonapage/onto#

EA on a Page is an evidence-based EA framework rooted in empirical research across 27+ organizations. Unlike prescriptive frameworks (TOGAF, Zachman), it describes how EA practices actually work — what artifacts organizations produce, what processes they follow, and what benefits they realize.

Assets¶

File	Namespace	Content
`eaonapage-onto.ttl`	`https://meta.linked.archi/eaonapage/onto#`	7 artifact type classes (CSVLOD), 3 process classes with I/O and phases, 4 participant roles, governance model (bodies, tiers, arrangements), maturity stages, governance activities, 24 properties
`eaonapage-tax.ttl`	`https://meta.linked.archi/eaonapage/tax#`	SKOS taxonomy of 24 artifacts with process linkage and nature/focus axes, maturity model (Stage 0–3 with challenges/benefits), governance classification (tiers, bodies, activities)
`eaonapage-metamodel.ttl`	`https://meta.linked.archi/eaonapage/metamodel#`	Metamodel manifest (v0.3.0) wiring all assets together
`eaonapage-viewpoints.ttl`	`https://meta.linked.archi/eaonapage/viewpoints#`	8 viewpoints in 4 categories (Strategic, Optimization, Delivery, Governance) with viewpoint catalog
`eaonapage-deliverable-templates.ttl`	`https://meta.linked.archi/eaonapage/deliverable-templates#`	8 deliverable templates with 32 structured sections
`eaonapage-shapes.ttl`	`https://meta.linked.archi/eaonapage/shapes#`	SHACL validation shapes for artifacts, processes, governance, and maturity

The CSVLOD Artifact Taxonomy¶

The core contribution of EA on a Page is the CSVLOD taxonomy — six general types of EA artifacts classified by their usage and purpose:

Type	Purpose	Scope	Lifecycle	Nature	Focus	Examples
Considerations	Governance rules for IT decisions	Organization-wide	Permanent	Rules	Business	Principles, Policies, Guidelines
Standards	Approved technologies and patterns	Organization-wide	Permanent	Rules	IT	Technology Reference Models, Patterns
Visions	Desired future state	Organization-wide	Long-lived	Structures	Business	Business Capability Models, Target Architectures, Roadmaps
Landscapes	Current state baseline	Organization-wide	Long-lived	Structures	IT	Landscape Diagrams, Inventories, System Portfolios
Outlines	Initiative-level architecture	Initiative-scoped	Short-lived	Solutions	Business	Solution Overviews, Options Assessments
Designs	Implementation specifications	Project-scoped	Short-lived	Solutions	IT	Solution Designs, Interface Contracts

The Three EA Processes¶

Each process uses two artifact types:

Process	Artifacts Used	Goal	Participants
Strategic Planning	Considerations + Visions	Convert business strategy into IT investment portfolio	Business leaders, IT leaders, Enterprise architects
Initiative Delivery	Outlines + Designs	Turn each investment into a working solution	Solution architects, Delivery teams
Technology Optimization	Standards + Landscapes	Rationalize the existing IT landscape	Enterprise architects, Technology specialists

Mapping to Linked.Archi¶

The CSVLOD types map to existing Linked.Archi concepts, but from a different angle — by usage and purpose rather than content type:

CSVLOD Type	Linked.Archi Equivalent	Mapping Rationale
Considerations	`ad:Principle`, `ad:Policy`, `ad:Constraint`	Governance rules that constrain decisions
Standards	`refa:ReferenceArchitecture`, `refa:Pattern`, `refa:Standard`	Reusable approved solutions
Visions	`arch:Model` (purpose: Designing) + `togaf:Capability`	Future-state models
Landscapes	`arch:Model` (purpose: Informing) + TIME assessments	Current-state inventories
Outlines	`ad:Decision` + `ad:Option`	Initiative-level decision records
Designs	`arch:Model` (purpose: Designing)	Project-level specifications

How to Use EA on a Page in Linked.Archi¶

Classify your architecture artifacts using the CSVLOD types:

@prefix eaop:  <https://meta.linked.archi/eaonapage/onto#> .
@prefix arch:  <https://meta.linked.archi/core#> .
@prefix togaf: <https://meta.linked.archi/togaf/onto#> .
@prefix ad:    <https://meta.linked.archi/arch-decision#> .
@prefix ex:    <https://model.example.com/myea#> .

# A Vision artifact — business capability model
ex:CapabilityModel a arch:Model, eaop:Vision ;
    skos:prefLabel "Enterprise Capability Model 2027"@en ;
    eaop:artifactScope "organization-wide" ;
    eaop:artifactLifecycle "long-lived" ;
    eaop:artifactNature "structures" ;
    eaop:artifactFocus "business-focused" .

# A Landscape artifact — application inventory
ex:AppInventory a arch:Model, eaop:Landscape ;
    skos:prefLabel "Application Portfolio Inventory"@en ;
    eaop:artifactScope "organization-wide" ;
    eaop:artifactLifecycle "long-lived" ;
    eaop:artifactNature "structures" ;
    eaop:artifactFocus "IT-focused" .

# An Outline artifact — solution overview for an initiative
ex:PaymentModernization a arch:Model, eaop:Outline ;
    skos:prefLabel "Payment Platform Modernization — Solution Overview"@en ;
    eaop:artifactScope "initiative-scoped" ;
    eaop:artifactLifecycle "short-lived" ;
    eaop:artifactNature "solutions" ;
    eaop:artifactFocus "business-focused" .

# A Consideration — architecture principle
ex:CloudFirstPrinciple a ad:Principle, eaop:Consideration ;
    skos:prefLabel "Cloud-First Principle"@en ;
    eaop:artifactScope "organization-wide" ;
    eaop:artifactLifecycle "permanent" ;
    eaop:artifactNature "rules" ;
    eaop:artifactFocus "business-focused" .

SPARQL: Artifact Portfolio by CSVLOD Type¶

PREFIX eaop: <https://meta.linked.archi/eaonapage/onto#>

SELECT ?type (COUNT(?artifact) AS ?count) WHERE {
    ?artifact a ?type .
    VALUES ?type {
        eaop:Consideration eaop:Standard eaop:Vision
        eaop:Landscape eaop:Outline eaop:Design
    }
}
GROUP BY ?type
ORDER BY DESC(?count)

Why EA on a Page Matters¶

Most EA frameworks tell you what you should do. EA on a Page tells you what actually works. The CSVLOD taxonomy is particularly valuable because it provides a simple, empirically validated classification that helps organizations understand what artifacts they need and why — without the overhead of TOGAF's 1800 pages.

In Linked.Archi, the CSVLOD types serve as a cross-cutting classification layer. Any arch:Model, ad:Decision, or ad:Principle can be additionally typed with a CSVLOD class to indicate its role in the EA practice. This enables portfolio-level queries like "show me all our Visions" or "which Landscapes are outdated?"

ATAM (SEI/CMU)¶

Status: Evaluation ontology with metamodel manifest Source: SEI ATAM Collection | ATAM Technical Report (PDF) Authors: Rick Kazman, Mark Klein, Paul Clements (SEI/CMU, 2000) Namespace: https://meta.linked.archi/atam/onto#

The Architecture Tradeoff Analysis Method (ATAM) is the industry standard for evaluating software architectures against quality attribute goals. Developed by the Software Engineering Institute at Carnegie Mellon University, ATAM systematically identifies risks, sensitivity points, and tradeoff points in an architecture.

Assets¶

File	Namespace	Content
`atam-onto.ttl`	`atam/onto#`	7 classes (UtilityTree, QABranch, SensitivityPoint, TradeoffPoint, ArchitecturalRisk, NonRisk, RiskTheme, ATAMEvaluation), 15+ properties
`atam-metamodel.ttl`	`atam/metamodel#`	Metamodel manifest

What ATAM Adds Beyond Existing Extensions¶

ATAM's QA scenarios are already modeled as ad:QualityAttributeRequirement with the full QAS structure (stimulus, response, measure). Architectural approaches are already refa:Pattern and refa:Tactic. What ATAM adds is the evaluation layer — concepts that emerge when you analyze scenarios against approaches:

ATAM Concept	What it captures	Linked.Archi Class
Utility Tree	Hierarchical decomposition of quality attributes into prioritized scenarios	`atam:UtilityTree` + `atam:QualityAttributeBranch`
Sensitivity Point	An element where a small change has a large QA impact	`atam:SensitivityPoint`
Tradeoff Point	An element that's a sensitivity point for multiple competing QAs	`atam:TradeoffPoint` (subclass of SensitivityPoint)
Architectural Risk	A decision that may not achieve its QA response	`atam:ArchitecturalRisk`
Non-Risk	A decision confirmed safe upon analysis	`atam:NonRisk`
Risk Theme	A systemic pattern of risks across the architecture	`atam:RiskTheme`
ATAM Evaluation	A complete evaluation session linking all findings	`atam:ATAMEvaluation`

How ATAM Connects to Other Extensions¶

ATAM is designed to compose with the decisions and ref-arch extensions:

ad:arch-decision                    atam:atam/onto                    refa:ref-arch
────────────────                    ──────────────                    ─────────────
ad:QualityAttributeRequirement ←──→ atam:hasScenario                  refa:Pattern
  (QAS: stimulus/response/measure)  atam:identifiedInScenario         refa:Tactic
                                                                        ↓
ad:Decision ←───────────────────── atam:riskInDecision          atam:riskInApproach
                                    atam:ArchitecturalRisk
                                    atam:SensitivityPoint
                                    atam:TradeoffPoint

Example: ATAM Evaluation of a Payment Platform¶

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

# The evaluation
ex:PaymentATAM a atam:ATAMEvaluation ;
    skos:prefLabel "Payment Platform ATAM — Q1 2026"@en ;
    atam:evaluatesArchitecture ex:PaymentPlatformModel ;
    atam:hasUtilityTree ex:PaymentUtilityTree ;
    atam:identifiedRisk ex:Risk-SingleDB ;
    atam:identifiedTradeoffPoint ex:TP-Encryption ;
    atam:identifiedSensitivityPoint ex:SP-PoolSize ;
    atam:identifiedRiskTheme ex:RT-DataTierRedundancy .

# Utility tree
ex:PaymentUtilityTree a atam:UtilityTree ;
    skos:prefLabel "Payment Platform Utility Tree"@en ;
    atam:hasQABranch ex:AvailabilityBranch, ex:PerformanceBranch, ex:SecurityBranch .

ex:AvailabilityBranch a atam:QualityAttributeBranch ;
    skos:prefLabel "Availability"@en ;
    atam:branchQualityAttribute iso25010:Availability ;
    atam:hasScenario ex:FailoverScenario, ex:PeakLoadScenario .

# A QA scenario (reuses ad:QualityAttributeRequirement)
ex:FailoverScenario a ad:QualityAttributeRequirement ;
    skos:prefLabel "Payment gateway failover"@en ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasStimulus "Primary payment gateway becomes unreachable"@en ;
    ad:qasResponse "System fails over to secondary within 5 seconds"@en ;
    ad:qasResponseMeasure "Zero lost transactions"@en ;
    atam:scenarioPriority "(H,M)" .

# A tradeoff point — encryption helps security but hurts performance
ex:TP-Encryption a atam:TradeoffPoint ;
    skos:prefLabel "Encryption at rest for payment data"@en ;
    atam:sensitiveToQA iso25010:Confidentiality, iso25010:TimeBehaviour ;
    atam:affectsElement ex:PaymentDB ;
    atam:identifiedInScenario ex:EncryptionScenario ;
    skos:scopeNote "Enabling encryption improves confidentiality but degrades query performance by ~15%."@en .

# A risk — single database has no failover
ex:Risk-SingleDB a atam:ArchitecturalRisk ;
    skos:prefLabel "Single database instance — no failover"@en ;
    atam:riskForQA iso25010:Availability ;
    atam:riskInDecision ex:ADR-042 ;
    atam:identifiedInScenario ex:FailoverScenario .

# A risk theme — pattern across multiple risks
ex:RT-DataTierRedundancy a atam:RiskTheme ;
    skos:prefLabel "Insufficient redundancy in data tier"@en ;
    atam:themeIncludesRisk ex:Risk-SingleDB, ex:Risk-NoBackup .

SPARQL: Find All Tradeoff Points¶

PREFIX atam:     <https://meta.linked.archi/atam/onto#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?tp ?label ?qa1 ?qa2 WHERE {
    ?tp a atam:TradeoffPoint ;
        skos:prefLabel ?label ;
        atam:sensitiveToQA ?qa1, ?qa2 .
    ?qa1 skos:prefLabel ?qa1Label .
    ?qa2 skos:prefLabel ?qa2Label .
    FILTER(?qa1 != ?qa2)
}

Relevance¶

ATAM remains the most widely referenced architecture evaluation method. It's taught in university courses, used in government and defense procurement, and referenced by BTABoK, SEI, and ISO 42030 (architecture evaluation). The concepts (utility trees, sensitivity/tradeoff points, risks) are used even by teams that don't formally run ATAM evaluations.

ADD Alignment (SEI/CMU)¶

Source: ADD Version 2.0 — SEI | ADD 3.0 — Rethinking Drivers and Decisions | Designing Software Architectures (Cervantes & Kazman, 2016) Authors: Len Bass, Paul Clements, Rick Kazman, Humberto Cervantes (SEI/CMU)

The Attribute-Driven Design (ADD) method is the SEI's systematic approach to designing software architectures based on quality attribute requirements. ADD is the design companion to ATAM (which evaluates architectures). Together they form a complete design-evaluate cycle.

Why ADD Doesn't Need Separate Semantic Assets¶

The ad:arch-decision extension was explicitly designed around ADD concepts. Every ADD concept maps directly to an existing Linked.Archi class:

ADD Concept	Linked.Archi Class	Notes
Iteration	`ad:Iteration`	Groups decisions and goals for one ADD cycle
Design Goal	`ad:hasDecisionGoal` → `skos:Concept`	What the iteration aims to achieve (select ref-arch, choose tactic, etc.)
ASR (Architecturally Significant Requirement)	`ad:QualityAttributeRequirement`, `ad:FunctionalRequirement`, `ad:Constraint`	The forces driving the iteration
Quality Attribute Scenario	`ad:QualityAttributeRequirement` with QAS properties	Full stimulus → response → measure structure
Candidate Design Concept	`ad:Option`	Each option addresses forces and impacts elements
Selected Design Concept	`ad:hasSelectedOption`	The chosen option
Architectural Pattern	`refa:Pattern`, `refa:ArchitecturalPattern`	Reusable solutions applied in options
Tactic	`refa:Tactic` with `addressedQA`/`impactedQA`	Primitive design techniques
Design Decision	`ad:Decision`	Records the choice, rationale, and affected elements
Element Decomposition	`arch:hasPart` / `arch:partOf`	Recursive decomposition of the system
Design Concept Catalog (ADD 3.0)	`refa:ReferenceArchitecture`, `refa:ReferenceModel`	Catalogs of approved patterns and technologies

The ADD Process in Linked.Archi¶

ADD's 5 steps map to the existing extensions:

Step 1 — Choose an element to design → Select an arch:Element from the arch:Model

Step 2 — Identify ASRs → Gather ad:QualityAttributeRequirement, ad:FunctionalRequirement, and ad:Constraint instances. Prioritize using ad:hasImportanceMeasure.

Step 3 — Generate a design solution → Create ad:Option instances, each including refa:Pattern and refa:Tactic via ad:includesConcept. Record element impact via ad:addsConcept, ad:modifiesConcept, ad:removesConcept.

Step 4 — Inventory remaining requirements → Check which ad:Force instances are addressed by the selected option. Identify unsatisfied requirements for the next iteration.

Step 5 — Repeat → Create a new ad:Iteration with its own goals and decisions.

Example: One ADD Iteration¶

@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/add#> .

# The iteration
ex:Iteration1 a ad:Iteration ;
    skos:prefLabel "ADD Iteration 1 — Establish Overall Structure"@en ;
    ad:hasDecisionGoal ex:GoalSelectRefArch .

ex:GoalSelectRefArch a skos:Concept ;
    skos:prefLabel "Select reference architecture for the payment platform"@en .

# The driving ASRs (forces)
ex:AvailabilityReq 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:qasResponseMeasure "Failover within 5 seconds"@en ;
    ad:hasImportanceMeasure "critical" .

ex:ModifiabilityReq a ad:QualityAttributeRequirement ;
    skos:prefLabel "Add new payment provider in < 2 weeks"@en ;
    ad:onQualityAttribute iso25010:Modifiability ;
    ad:hasImportanceMeasure "high" .

# The options — each includes patterns and tactics
ex:MicroservicesOption a ad:Option ;
    skos:prefLabel "Microservices with Event-Driven Processing"@en ;
    ad:addressesForce ex:AvailabilityReq, ex:ModifiabilityReq ;
    ad:includesConcept ex:MicroservicesPattern, ex:EventDrivenPattern ;
    ad:addsConcept ex:APIGateway, ex:EventBus, ex:PaymentAdapter .

ex:MonolithOption a ad:Option ;
    skos:prefLabel "Modular Monolith with Plugin Architecture"@en ;
    ad:addressesForce ex:ModifiabilityReq ;
    ad:includesConcept ex:ModularMonolithPattern ;
    ad:hasRisk [ skos:prefLabel "Scaling limited to vertical"@en ] .

# Patterns from the ref-arch extension
ex:MicroservicesPattern a refa:ArchitecturalPattern ;
    skos:prefLabel "Microservices"@en ;
    refa:appliedTactic ex:CircuitBreakerTactic, ex:ServiceDiscoveryTactic .

# The decision
ex:ADR-001 a ad:Decision ;
    skos:prefLabel "ADR-001: Use microservices for payment platform"@en ;
    ad:hasIssue ex:PlatformStructureIssue ;
    ad:hasSelectedOption ex:MicroservicesOption ;
    ad:hasAlternative ex:MonolithOption ;
    ad:influencedByForce ex:AvailabilityReq, ex:ModifiabilityReq ;
    ad:justification "Microservices address both availability (independent scaling) and modifiability (independent deployment)."@en .

# Link decision to iteration
ex:Iteration1 ad:hasDecision ex:ADR-001 .

ADD + ATAM: The Design-Evaluate Cycle¶

ADD and ATAM form a natural cycle:

ADD Iteration → produces architecture decisions and a design
ATAM Evaluation → evaluates the design, identifies risks and tradeoffs
ADD Iteration → addresses the risks identified by ATAM
Repeat until risks are acceptable

In Linked.Archi, this cycle is traceable:

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

# Decisions that were revised after ATAM identified risks
SELECT ?originalDecision ?risk ?revisedDecision WHERE {
    ?risk a atam:ArchitecturalRisk ;
          atam:riskInDecision ?originalDecision .
    ?revisedDecision a ad:Decision ;
                     ad:hasIssue ?issue .
    ?issue ad:issueCausedBy ?risk .
}

BTABoK Alignment (IASA)¶

Source: BTABoK — Business Technology Architecture Body of Knowledge | GitHub Author: IASA (International Association of Software Architects) License: Open source

The BTABoK is the world's largest open-source body of knowledge for architecture professionals. Unlike the other frameworks in this section, BTABoK is not modeled as a separate semantic asset set — instead, Linked.Archi assets reference BTABoK pages via rdfs:seeAlso links, because BTABoK's core concepts are already covered by existing Linked.Archi ontologies.

BTABoK is a people and practice framework — it describes how architects work, what competencies they need, and how architecture teams engage with organizations. Its architectural concepts (decisions, quality attributes, viewpoints, stakeholders, requirements) align directly with Linked.Archi's existing vocabulary.

Concept Mapping¶

BTABoK Concept	Linked.Archi Asset	BTABoK Page
Decisions	`ad:Decision`	Decisions
Options	`ad:Option`	Decisions
Quality Attributes	`arch:QualityAttribute`, `iso25010:*`	Quality Attributes
QA Scenarios (ATAM)	`ad:QualityAttributeRequirement` (QAS properties)	QA Card
Balancing QAs	`refa:Tactic` (addressedQA / impactedQA)	Balancing and Optimizing QAs
Requirements (ASRs)	`ad:Requirement`, `ad:Force`	Requirements
Principles	`ad:Principle`	Principles
Views & Viewpoints	`arch:View`, `arch:Viewpoint`	Views
Stakeholders	`arch:Stakeholder`	Stakeholders
Architecture Lifecycle (ADLC)	`ap:ArchitectureProcess`	Architecture Lifecycle
Value Streams	`togaf:ValueStream`	Value Streams
Business Model Canvas	`modelingLanguages/bmc/`	Business Model Canvas
Engagement Model	`ap:ArchitectureProcess` (governance workflows)	Engagement Models
Competency Model (5 Pillars)	— (not modeled, practice/HR concern)	Competency

How BTABoK References Are Used¶

Linked.Archi assets include rdfs:seeAlso links to BTABoK pages on the relevant classes. When docgen renders the ontology documentation, these links appear as "See Also" references, connecting the formal ontology definition to the practitioner-oriented BTABoK guidance.

For example, the ad:Decision class links to both the academic sources (Jansen & Bosch, Kruchten) and the BTABoK decisions page:

ad:Decision
    rdfs:seeAlso <https://adr.github.io/> ;
    rdfs:seeAlso <https://iasa-global.github.io/btabok/decisions.html> ;
.

BTABoK's "Red Thread" and Linked.Archi Extensions¶

BTABoK defines a "Red Thread" — the minimum architecture steps for any product or project:

Usage and Value — measure outcomes against OKRs
Agile DevOps — integrate with delivery
Viewpoints — look at the architecture from multiple perspectives
Quality Attributes — design for cross-cutting concerns
Decisions — trace decisions to outcomes
Options — evaluate alternatives
Requirements — capture architecturally significant requirements
Business Case — justify the investment
OKRs — define measurable success criteria

This maps almost exactly to the Linked.Archi extension composition:

# BTABoK Red Thread → Linked.Archi extensions
# Viewpoints        → arch:Viewpoint (core)
# Quality Attributes → arch:QualityAttribute (core) + iso25010 (standards)
# Decisions          → ad:Decision, ad:Option (arch-decision extension)
# Requirements       → ad:Requirement, ad:QualityAttributeRequirement (arch-decision)
# Business Case      → ad:Force, ad:BusinessConstraint (arch-decision)
# Patterns/Tactics   → refa:Pattern, refa:Tactic (ref-arch extension)
# Process/Lifecycle  → ap:ArchitectureProcess (arch-processes extension)

A model that imports the three core extensions (arch-decision, arch-processes, ref-arch) plus the quality attributes and tactics extensions covers the full BTABoK Red Thread.

BTABoK Canvases as Deliverable Templates¶

BTABoK defines several structured canvases (QA Card, Capability Card, NABC Business Case Card, Stakeholder Engagement Canvas). These are conceptually equivalent to arch:DeliverableTemplate instances — they define a structured format for capturing architecture information.

An organization could model BTABoK canvases as deliverable templates:

@prefix arch:  <https://meta.linked.archi/core#> .
@prefix archdt: <https://meta.linked.archi/core-deliverable-templates#> .
@prefix ex:    <https://model.example.com/btabok#> .

ex:QualityAttributeCard a arch:DeliverableTemplate ;
    skos:prefLabel "Quality Attribute Card (BTABoK)"@en ;
    skos:definition "ATAM-style scenario card for testing architecture decisions against quality attributes."@en ;
    arch:templateTargetsPurpose archdt:Deciding ;
    rdfs:seeAlso <https://iasa-global.github.io/btabok/qatt_card.html> .

ex:NABCBusinessCase a arch:DeliverableTemplate ;
    skos:prefLabel "NABC Business Case Card (BTABoK)"@en ;
    skos:definition "Need, Approach, Benefit, Competition — structured business case for architecture investments."@en ;
    arch:templateTargetsPurpose archdt:Deciding ;
    rdfs:seeAlso <https://iasa-global.github.io/btabok/business_case_nabc_card.html> .

BizBOK Alignment (Business Architecture Guild)¶

Source: Business Architecture Guild — BIZBOK Guide | OMG BACM Specification Author: Business Architecture Guild Standard: OMG Business Architecture Core Metamodel (BACM) v1.1

The BIZBOK Guide (Guide to the Business Architecture Body of Knowledge) is the industry standard for business architecture practice, maintained by the Business Architecture Guild. The OMG has formalized its core concepts as the BACM (Business Architecture Core Metamodel) specification.

Like BTABoK, BizBOK is not modeled as a separate semantic asset set — its core concepts are already covered by the TOGAF ontology and ArchiMate modeling language. Linked.Archi assets include rdfs:seeAlso links to BizBOK-related resources on the relevant classes.

BizBOK Core Domains¶

BizBOK defines four core mapping domains and five extended mapping domains:

Core domains:

BizBOK Domain	What it maps	Linked.Archi Asset
Capability Mapping	What the organization does (abilities, not how)	`togaf:Capability`, `am:Capability`
Value Stream Mapping	How value flows from trigger to outcome	`am:ValueStream`
Organization Mapping	Who does the work (units, roles, partners)	`togaf:Organization`, `togaf:Actor`, `togaf:Role`
Information Mapping	What information the business uses	`togaf:DataEntity`, `togaf:LogicalDataComponent`

Extended domains:

BizBOK Domain	What it maps	Linked.Archi Asset
Strategy Mapping	Goals, objectives, courses of action	`togaf:Goal`, `togaf:Objective`, `am:Goal`, `am:CourseOfAction`
Stakeholder Mapping	Who cares and what they care about	`arch:Stakeholder`, `arch:Concern`
Initiative Mapping	Projects and programs that realize change	`togaf:WorkPackage`, `am:WorkPackage`
Product Mapping	Products and services offered	`togaf:Product`, `am:Product`, `togaf:BusinessService`
Policy Mapping	Rules and regulations that constrain	`ad:Policy`, `ad:Constraint`

Concept Mapping¶

BizBOK Concept	Linked.Archi Class	Source
Capability	`togaf:Capability`, `am:Capability`	TOGAF Business Capabilities Guide
Value Stream	`am:ValueStream`	TOGAF Value Streams Guide
Value Stream Stage	`am:ValueStream` (composed via `am:composedOf`)	—
Organization Unit	`togaf:Organization`	—
Information Concept	`togaf:DataEntity`	—
Stakeholder	`arch:Stakeholder`	—
Strategy / Goal	`togaf:Goal`, `am:Goal`	—
Initiative	`togaf:WorkPackage`, `am:WorkPackage`	—
Product	`togaf:Product`, `am:Product`	—
Policy	`ad:Policy`, `ad:Constraint`	—
Business Process	`togaf:BusinessProcess`, `am:BusinessProcess`	—
Business Service	`togaf:BusinessService`, `am:BusinessService`	—
Metric / KPI	`togaf:Measure`, `arch:QualityMeasure`	—

Why Not a Separate Semantic Asset Set?¶

BizBOK's core metamodel concepts (capabilities, value streams, organization, information) are already fully represented in the TOGAF ontology and ArchiMate modeling language. Creating a separate bizbok-onto.ttl would duplicate these classes without adding semantic value.

The TOGAF Content Metamodel was explicitly designed to align with BizBOK — The Open Group and the Business Architecture Guild collaborated on the TOGAF Business Architecture guides. The ArchiMate Strategy layer (Capability, ValueStream, Resource, CourseOfAction) was similarly influenced by BizBOK thinking.

What BizBOK adds beyond TOGAF/ArchiMate is practice guidance — how to create capability maps, how to run value stream workshops, how to do heat mapping. This is documentation, not ontology content.

Using BizBOK Concepts in Linked.Archi¶

Since BizBOK concepts map directly to existing classes, you use them through the TOGAF or ArchiMate ontologies:

@prefix togaf: <https://meta.linked.archi/togaf/onto#> .
@prefix am:    <https://meta.linked.archi/archimate3/onto#> .
@prefix arch:  <https://meta.linked.archi/core#> .
@prefix ex:    <https://model.example.com/bizarch#> .

# BizBOK Capability Map → TOGAF/ArchiMate capabilities
ex:CustomerManagement a togaf:Capability ;
    skos:prefLabel "Customer Management"@en ;
    skos:definition "Ability to acquire, retain, and grow customer relationships."@en .

ex:CustomerOnboarding a togaf:Capability ;
    skos:prefLabel "Customer Onboarding"@en ;
    arch:hasPart ex:CustomerManagement .

# BizBOK Value Stream → ArchiMate value stream
ex:OrderToFulfillment a am:ValueStream ;
    skos:prefLabel "Order to Fulfillment"@en ;
    skos:definition "End-to-end value delivery from order placement to delivery."@en .

# BizBOK Organization Map → TOGAF organization
ex:SalesDepartment a togaf:Organization ;
    skos:prefLabel "Sales Department"@en .

# BizBOK cross-mapping: capability realized by value stream stage
ex:OrderToFulfillment am:realizes ex:CustomerManagement .

SPARQL: BizBOK-Style Capability Heat Map¶

A common BizBOK technique is heat mapping — overlaying assessment data on a capability map. With Linked.Archi, this is a SPARQL query combining TOGAF capabilities with TIME assessments:

PREFIX togaf:  <https://meta.linked.archi/togaf/onto#>
PREFIX timefw: <https://meta.linked.archi/time-framework/onto#>

# Capabilities supported by applications with Migrate disposition
SELECT ?capability ?capLabel ?app ?appLabel ?disposition WHERE {
    ?app a timefw:Application ;
         skos:prefLabel ?appLabel ;
         timefw:hasFitAssessment ?assess ;
         timefw:supportsCapability ?capability .
    ?capability skos:prefLabel ?capLabel .
    ?assess timefw:timeDisposition ?disposition ;
            timefw:assessmentStatus timefw:Approved .
    FILTER(?disposition = timefw:Migrate || ?disposition = timefw:Eliminate)
}
ORDER BY ?capLabel

Topic	Document
TOGAF ontology details	Ontology Reference — TOGAF
TIME use case	UC-2: Application Portfolio Rationalization
ADMIT use case	UC-4: Multi-Framework Architecture Governance
TIME interactive demo	TIME Framework Matrix Demo
Design decisions	Design Decisions
Standards alignment	Standards Alignment

Frameworks Guide¶

Overview¶

TOGAF¶

Assets¶

Relevance¶

DoDAF¶

Assets¶

Viewpoints¶

Relevance¶

How to Use DoDAF in Linked.Archi¶

ADMIT¶

Assets¶

What ADMIT Provides¶

Relevance Assessment¶

What's Missing (Post-2013 Concerns)¶

How to Use ADMIT in Linked.Archi¶

TIME Framework¶

Assets¶

What TIME Provides¶

Relevance¶

Why Both an Ontology and a Taxonomy?¶

How to Use TIME in Linked.Archi¶

Zachman Framework¶

Assets¶

What Zachman Provides¶

Relevance¶

How to Use Zachman in Linked.Archi¶

Platform Design¶

Assets¶

Relevance¶

EA on a Page (Kotusev)¶

Assets¶

The CSVLOD Artifact Taxonomy¶

The Three EA Processes¶

Mapping to Linked.Archi¶

How to Use EA on a Page in Linked.Archi¶

SPARQL: Artifact Portfolio by CSVLOD Type¶

Why EA on a Page Matters¶

ATAM (SEI/CMU)¶

Assets¶

What ATAM Adds Beyond Existing Extensions¶

How ATAM Connects to Other Extensions¶

Example: ATAM Evaluation of a Payment Platform¶

SPARQL: Find All Tradeoff Points¶

Relevance¶

ADD Alignment (SEI/CMU)¶

Why ADD Doesn't Need Separate Semantic Assets¶

The ADD Process in Linked.Archi¶

Example: One ADD Iteration¶

ADD + ATAM: The Design-Evaluate Cycle¶

BTABoK Alignment (IASA)¶

Concept Mapping¶

How BTABoK References Are Used¶

BTABoK's "Red Thread" and Linked.Archi Extensions¶

BTABoK Canvases as Deliverable Templates¶

BizBOK Alignment (Business Architecture Guild)¶

BizBOK Core Domains¶

Concept Mapping¶

Why Not a Separate Semantic Asset Set?¶

Using BizBOK Concepts in Linked.Archi¶

SPARQL: BizBOK-Style Capability Heat Map¶

Further Reading¶