Architecture Processes — Modeling Guide¶

What this extension is for¶

The architecture processes extension (ap:) describes the governance and lifecycle infrastructure that acts upon architecture elements. It answers questions like:

What governance process does this system go through before changes are approved?
Who is responsible for architecture reviews?
What deliverables does the elaboration process produce?
What lifecycle stage is this application at?

Process concepts are not constituents of the architecture — they govern it from the outside. An architecture review board process governs a system; it is not itself a system component. This separation is reflected in the design: process classes do not subclass arch:Element. They relate to architecture elements via linking properties.

Core concepts¶

Process decomposition¶

The fundamental structure is Process → Activity → Task:

@prefix ap:   <https://meta.linked.archi/arch-processes#> .
@prefix arch: <https://meta.linked.archi/core#> .

ex:ArchReviewProcess a ap:ArchitectureProcess ;
    skos:prefLabel "Architecture Review Board Process"@en ;
    ap:governs ex:PaymentPlatform, ex:OrderService ;
    ap:hasActivity ex:ReviewPreparation, ex:ReviewExecution, ex:ReviewFollowUp .

ex:ReviewPreparation a ap:ProcessActivity ;
    skos:prefLabel "Review Preparation"@en ;
    ap:activityOfProcess ex:ArchReviewProcess ;
    ap:hasTask ex:TriageRequest, ex:AssignReviewers ;
    ap:precedes ex:ReviewExecution .

ex:TriageRequest a ap:ProcessTask ;
    skos:prefLabel "Triage review request"@en ;
    ap:taskOfActivity ex:ReviewPreparation ;
    ap:performedBy ex:ChiefArchitect .

Linking processes to architecture elements¶

Processes relate to the architecture they govern via explicit properties:

Property	Direction	Purpose
`ap:governs`	Process → Element	Which elements this process governs
`ap:governedBy`	Element → Process	Which process governs this element
`ap:input`	Process → resource	What the process consumes (models, forces, info items)
`ap:output`	Process → resource	What the process produces (decisions, deliverables, models)
`ap:consumedBy`	resource → Process	Inverse of input
`ap:producedBy`	Deliverable → Process	Which process produced this deliverable

Example — linking a governance process to decisions and elements:

ex:ArchReviewProcess a ap:ArchitectureProcess ;
    ap:governs ex:PaymentPlatform ;
    ap:input ex:ArchitectureProposal ;
    ap:output ex:ReviewDecision .

ex:ReviewDecision a ad:Decision ;
    ad:status ad:Accepted ;
    ad:relatedConcept ex:PaymentPlatform .

Roles and responsibilities¶

ex:ChiefArchitect a ap:ProcessRole ;
    skos:prefLabel "Chief Architect"@en ;
    ap:responsibleFor ex:ArchReviewProcess .

ex:ReviewExecution a ap:ProcessActivity ;
    ap:performedBy ex:ChiefArchitect, ex:SecurityArchitect ;
    ap:approvedBy ex:ChiefArchitect .

Milestones and sequencing¶

ex:ReviewGate a ap:ProcessMilestone ;
    skos:prefLabel "Architecture Review Gate"@en ;
    ap:milestoneOfProcess ex:ArchReviewProcess .

ex:ReviewPreparation ap:precedes ex:ReviewExecution .
ex:ReviewExecution ap:precedes ex:ReviewFollowUp .

Lifecycle stages¶

Lifecycle stages represent the phases an entity passes through over time. They are complementary to processes — a process describes what happens; a stage describes where something is.

ex:PaymentPlatform a am:ApplicationComponent ;
    ap:atLifecycleStage timefw:Run ;
    ap:followsLifecycle ex:AppPortfolioLifecycle .

ap:LifecycleStage is a subclass of skos:Concept — stages are classification terms, not architectural elements.

A ap:LifecycleModel groups stages into a named progression:

ex:AppPortfolioLifecycle a ap:LifecycleModel ;
    skos:prefLabel "Application Portfolio Lifecycle"@en ;
    ap:hasStage timefw:Plan, timefw:Build, timefw:Run, timefw:Retire .

Architecture state (baseline / target / transitional)¶

Orthogonal to lifecycle, the arch:architectureState property (defined in core) classifies whether a model or element represents the current reality or a planned future:

ex:CurrentPaymentArch a arch:Model ;
    arch:architectureState arch:Baseline ;
    arch:modelRepresentsSystem ex:PaymentPlatform .

ex:TargetPaymentArch a arch:Model ;
    arch:architectureState arch:Target ;
    arch:modelRepresentsSystem ex:PaymentPlatform .

Architecture state and lifecycle are independent dimensions:

Dimension	Question	Examples
`arch:architectureState`	Which temporal reality does this model describe?	Baseline, Target, Transitional
`ap:atLifecycleStage`	Where is this entity in its lifecycle?	Plan, Build, Run, Retire

An application can be ap:atLifecycleStage timefw:Run in the baseline model and ap:atLifecycleStage timefw:Retire in the target model.

ISO/IEC/IEEE 42020 — Architecture Governance¶

https://meta.linked.archi/iso42020#

ISO 42020 defines the processes for governing and managing architecture. Its classes subclass the arch-processes extension (iso42020:Process rdfs:subClassOf ap:ArchitectureProcess), so all AP properties are inherited.

Process areas¶

Individual	Description
`iso42020:ArchitectureGovernance`	Overarching framework that directs and controls architecture activities
`iso42020:ArchitectureConceptualization`	Developing initial architecture concepts from stakeholder concerns
`iso42020:ArchitectureEvaluation`	Assessing architecture against requirements and quality attributes
`iso42020:ArchitectureElaboration`	Refining architecture to implementation-ready detail
`iso42020:ArchitectureTransition`	Planning and executing migration from current to target state

Usage¶

These are concurrent, repeating processes — not sequential stages. Use them via ap:governs or as types for your own process instances:

# Direct use of the ISO 42020 individual
iso42020:ArchitectureElaboration
    ap:governs ex:PaymentPlatform ;
    ap:output ex:DetailedPaymentArch .

# Or type your own instance
ex:PaymentElaboration a iso42020:Process ;
    skos:prefLabel "Payment Platform Elaboration"@en ;
    ap:governs ex:PaymentPlatform ;
    ap:hasActivity ex:ElaborateContracts, ex:ElaborateDeployment ;
    ap:output ex:PaymentArchDefinitionDoc .

ISO/IEC/IEEE 12207 — Software Lifecycle Processes¶

https://meta.linked.archi/iso12207#

ISO 12207 defines processes for the software life cycle. Classes subclass arch-processes (iso12207:Process rdfs:subClassOf ap:ArchitectureProcess).

Process groups¶

Individual	Description
`iso12207:AgreementProcesses`	Acquisition and supply agreements
`iso12207:OrganizationalProjectEnablingProcesses`	Portfolio, infrastructure, HR, quality, knowledge management
`iso12207:TechnicalManagementProcesses`	Planning, risk, configuration, decision management
`iso12207:TechnicalProcesses`	Requirements, design, implementation, integration, verification, validation

Lifecycle stages¶

ISO 12207 also defines a generic software lifecycle model with six stages (as ap:LifecycleStage instances):

Stage	Order	Description
`iso12207:ConceptStage`	1	Need identified, feasibility assessed
`iso12207:DevelopmentStage`	2	Design, implementation, testing
`iso12207:ProductionStage`	3	Manufacturing, packaging, deployment
`iso12207:UtilizationStage`	4	Active operational use
`iso12207:SupportStage`	5	Maintenance and support
`iso12207:RetirementStage`	6	Withdrawal from service

Usage:

ex:LegacyCRM a am:ApplicationComponent ;
    ap:atLifecycleStage iso12207:SupportStage ;
    ap:followsLifecycle iso12207:SoftwareLifecycleModel .

The TIME framework's lifecycle states (Plan, Build, Run, Retire) map to ISO 12207 stages via skos:closeMatch:

TIME	ISO 12207
`timefw:Plan`	`iso12207:ConceptStage`
`timefw:Build`	`iso12207:DevelopmentStage`
`timefw:Run`	`iso12207:UtilizationStage`
`timefw:Retire`	`iso12207:RetirementStage`

ISO/IEC/IEEE 15288 — System Lifecycle Processes¶

https://meta.linked.archi/iso15288#

ISO 15288 has the same structure as 12207 but applies to systems engineering (hardware + software + people + processes). Classes subclass arch-processes (iso15288:Process rdfs:subClassOf ap:ArchitectureProcess).

Process groups¶

Individual	Description
`iso15288:AgreementProcesses`	Acquisition and supply for systems
`iso15288:OrganizationalProjectEnablingProcesses`	Organizational capability for systems engineering
`iso15288:TechnicalManagementProcesses`	Technical project management for systems
`iso15288:TechnicalProcesses`	Full systems engineering lifecycle (concept through disposal)

When to use 15288 vs 12207¶

Use 12207 when the subject is a software system or software product
Use 15288 when the subject is a system that includes hardware, firmware, people, or physical infrastructure alongside software

Both share the same generic process structure; the difference is scope and applicable domain.

Querying¶

What processes govern a given element?¶

PREFIX ap: <https://meta.linked.archi/arch-processes#>

SELECT ?process ?label WHERE {
    ?process ap:governs ex:PaymentPlatform ;
             skos:prefLabel ?label .
}

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 ?_ }
}

What lifecycle stage are applications at?¶

PREFIX ap:   <https://meta.linked.archi/arch-processes#>
PREFIX arch: <https://meta.linked.archi/core#>

SELECT ?app ?appLabel ?stage ?stageLabel WHERE {
    ?app a/rdfs:subClassOf* arch:Element ;
         skos:prefLabel ?appLabel ;
         ap:atLifecycleStage ?stage .
    ?stage skos:prefLabel ?stageLabel .
}

Design rationale¶

Architecture processes are not subclasses of arch:Element because they are categorically different from the things they govern. A system, a service, or an application is a constituent of the architecture. A review process, an elaboration activity, or a governance gate is infrastructure that acts upon the architecture from outside.

This distinction avoids the category error of treating governance processes as architectural constituents — which would conflate "what the system is" with "how we manage it." The linking properties (ap:governs, ap:input, ap:output) make the relationship between the two layers explicit and queryable without flattening them into one.

The ISO standards (42020, 12207, 15288) subclass the arch-processes extension rather than existing independently because they define the same concepts at a more specific level. iso42020:Process is an ap:ArchitectureProcess — it refines the generic concept with ISO-specific terminology and process areas. This means a single SPARQL query for ?p a ap:ArchitectureProcess returns processes from all three standards via subsumption.

Architecture Processes — Modeling Guide¶

What this extension is for¶

Core concepts¶

Process decomposition¶

Linking processes to architecture elements¶

Roles and responsibilities¶

Milestones and sequencing¶

Lifecycle stages¶

Architecture state (baseline / target / transitional)¶

ISO/IEC/IEEE 42020 — Architecture Governance¶

Process areas¶

Usage¶

ISO/IEC/IEEE 12207 — Software Lifecycle Processes¶

Process groups¶

Lifecycle stages¶

ISO/IEC/IEEE 15288 — System Lifecycle Processes¶

Process groups¶

When to use 15288 vs 12207¶

Querying¶

What processes govern a given element?¶

What deliverables does each process produce?¶

Which activities have no assigned performer? (governance gap)¶

What lifecycle stage are applications at?¶

Design rationale¶

References¶