Architecture Practice from Scratch — Series Plan¶

Internal planning document. Not published.

Purpose¶

A 7-part series guiding organizations from zero architecture practice to a fully governed, tool-integrated, AI-ready architecture knowledge system built on Linked.Archi semantic foundations.

Target Audience¶

Organizations increasing architecture maturity (ad-hoc → governed)
Teams introducing or replacing architecture repository tooling
Practices migrating from proprietary/siloed tools to open, interoperable, semantically rich approaches
Architecture leads who need to justify and plan the initiative end-to-end

Narrative Arc¶

The series follows a deliberate progression:

Business-level discovery (Parts 1–2) — no technical jargon, approachable by non-architects
Conceptual design (Parts 3–4) — visual, reviewable, still no code
Formal definition (Parts 5–6) — RDF, SHACL, tool-consumable assets
Implementation (Part 7) — connecting the formal assets to actual tooling

Each part produces a concrete deliverable that feeds the next. A reader can stop at any point and still have something usable at that level of formality.

Reference Frames¶

EA on a Page — governance structure, CSVLOD artifact classification, maturity model, three core processes
ArchiMate 4.0 — modeling vocabulary, domain structure, relationship types, viewpoints
Linked.Archi core ontology — arch:Metamodel, arch:Viewpoint, arch:Stakeholder, semantic asset structure
Architecture Knowledge Lifecycle — the 7-stage lifecycle (conceive → capture → validate → share → apply → evolve → retire)

Part 1 — Stakeholder Discovery & Viewpoint Elicitation¶

Status: ✅ Written

File: part1-stakeholder-discovery.md

Scope: - Identify stakeholder roles as producers/consumers of architecture information - Elicit viewpoints through concern-based interviews (not diagram templates) - Define data lifecycle requirements (ownership, cadence, retirement) - Assess governance requirements per tier (enterprise/domain/solution) - Consolidate into a requirements summary template

Deliverable: Requirements summary document (stakeholder register, viewpoint candidates, lifecycle rules, governance requirements)

Tone: Entirely business-level. No Turtle, no OWL, no SHACL. Accessible to CxOs and non-technical stakeholders.

Key references: - EA on a Page CSVLOD taxonomy and processes - ArchiMate 4 domains (for concept coverage mapping) - Architecture Knowledge Lifecycle (background for lifecycle questions)

Part 2 — Structuring Requirements into Viewpoints & Artifact Types¶

Status: 🔲 Not started

File: part2-viewpoint-structuring.md

Scope: - Take the raw requirements summary from Part 1 and organize it - Define formal viewpoint specifications (stakeholders, concerns, element types, relationship types) - Classify artifacts using the CSVLOD taxonomy (type, lifecycle, governing process) - Map cross-viewpoint dependencies (shared concepts, data flows between views) - Define completeness criteria per viewpoint - Produce a structured specification that's precise enough for Part 3

Deliverable: Structured viewpoint catalog + artifact type specifications (tabular/narrative, no code)

Tone: More structured than Part 1 but still human-readable. Tables, matrices, dependency diagrams. A solution architect or enterprise architect should be able to review and approve.

Key references: - ISO/IEC/IEEE 42010 viewpoint specification structure - EA on a Page viewpoints (as concrete examples) - ArchiMate 4 viewpoint catalog (as concrete examples)

Part 3 — Metamodel Conceptualized¶

Status: 🔲 Not started

File: part3-metamodel-conceptualized.md

Scope: - Translate the viewpoint catalog into a conceptual metamodel - Concept maps showing element types, relationship types, and their domains - Domain boundaries (which concepts belong where) - Inheritance and specialization decisions (when to subclass vs. classify) - Relationship semantics (what each connection means in plain language) - Notation design decisions (how concepts will be visually represented) - Mapping to ArchiMate 4 base types where applicable (what to reuse vs. extend)

Deliverable: Concept map diagrams (D2/Mermaid), element/relationship catalog with plain-language definitions, design decision log

Tone: Visual and narrative. Diagrams with accompanying explanations. Reviewable by architects and informed business stakeholders. No RDF syntax — but precise enough that an ontology engineer could translate directly.

Key references: - ArchiMate 4 metamodel structure (as base language to extend) - EA on a Page metamodel manifest (as reference architecture for metamodel composition) - Linked.Archi core ontology (arch:Element, arch:Relationship, arch:Metamodel structure)

Part 4 — Governance & Lifecycle Management¶

Status: 🔲 Not started

File: part4-governance-and-lifecycle.md

Scope: - Define the governance model for the architecture practice - Roles and responsibilities (who creates, reviews, approves, retires each artifact type) - Review cadences per lifecycle class (permanent/long-lived/short-lived) - Quality gates and approval workflows - Evolution rules (how the metamodel itself evolves — versioning, backward compatibility) - Maintenance operations (how instances are kept current, staleness detection) - Exception handling (what happens when rules are violated) - Retirement processes (cascading cleanup, archive policies) - Connect to the Architecture Knowledge Lifecycle stages: validate, share, apply, evolve, retire

Deliverable: Governance handbook (roles, cadences, gates, processes) — could be directly adopted as an organization's architecture governance document

Tone: Operational/process-oriented. Readable by governance boards and architecture managers. Concrete enough to implement as organizational procedures.

Key references: - EA on a Page governance model (tiers, bodies, activities) - Architecture Knowledge Lifecycle (all 7 stages) - CSVLOD lifecycle classification (permanent/long-lived/short-lived)

Part 5 — Formal Metamodel Definition¶

Status: 🔲 Not started

File: part5-formal-metamodel-definition.md

Scope: - Translate the conceptual metamodel (Part 3) into formal RDF - OWL ontology: classes, properties, domain/range, inheritance - SKOS taxonomy: concept classification schemes - Metamodel manifest: the arch:Metamodel instance tying everything together - Viewpoint definitions in RDF - Deliverable template declarations - Notation set (visual appearance definitions) - Worked example: building the fictional mid-size enterprise's metamodel step by step

Deliverable: Complete Turtle (.ttl) files for a reference metamodel, with inline explanation of every design choice

Tone: Technical. Turtle code with detailed commentary. Target audience: ontology engineers, semantic web practitioners, senior architects comfortable with RDF.

Key references: - Build Your Own Metamodel (pattern reference — this article provides the conceptual foundation that one assumes) - ArchiMate 4 semantic assets (as reference implementation) - EA on a Page semantic assets (as reference implementation) - Linked.Archi core ontology (arch:Metamodel properties and structure)

Part 6 — Formal Governance & Validation¶

Status: 🔲 Not started

File: part6-formal-governance-and-validation.md

Scope: - Translate governance rules (Part 4) into formal SHACL shapes - Completeness shapes (required properties per element type) - Relationship constraint shapes (valid source/target combinations) - Lifecycle validation (staleness detection, mandatory review dates) - Viewpoint conformance shapes (what's allowed in each viewpoint) - Governance process shapes (approval status, ownership requirements) - CI/CD integration: running SHACL validation on commit - Severity levels: sh:Warning vs sh:Violation — when to block vs. advise - SPARQL-based governance queries (staleness reports, completeness dashboards)

Deliverable: SHACL shapes files + CI/CD pipeline configuration + SPARQL governance queries

Tone: Technical. SHACL/SPARQL code with operational commentary. Target audience: same as Part 5 plus DevOps/platform engineers setting up pipelines.

Key references: - Validation guide (existing doc/guide/validation.md) - ArchiMate 4 shapes (relationship-shapes, element-shapes, principle-shapes, viewpoint-shapes) - Architecture Knowledge Lifecycle — validate, apply stages

Part 7 — Tool Integration¶

Status: 🔲 Not started

File: part7-tool-integration.md

Scope: - Frame the build-or-buy decision for architecture tooling - Evaluation criteria for repository tools (semantic support, API access, validation hooks, export formats) - How the formal metamodel (Part 5) connects to tool palettes, validation, and generation - Integration patterns: tool-native storage vs. RDF export/sync vs. RDF-native repository - The role of MCP servers for AI agent access to the knowledge graph - Deliverable generation from metamodel + templates + data - Brief worked example showing tool consumption of the metamodel manifest - Refer to "Build Your Own Modeling Tool" for the full build path - Refer to "Build Your Own Metamodel" for extending existing tool configurations

Deliverable: Decision framework for tool selection + integration architecture patterns

Tone: Mixed — decision-level framing (readable by architecture managers) + integration patterns (technical). Short and referential rather than comprehensive — points to existing articles for depth.

Key references: - Build Your Own Modeling Tool (full build guide) - Build Your Own Metamodel (extending/customizing) - Deliverable Templates guide - Generator Spec - Semantic Architecture as Code

Cross-Cutting Concerns¶

Worked Example Thread¶

The fictional mid-size enterprise introduced in Part 1 (2,000 staff, 150 applications, 3 business units) carries through the entire series. Each part develops the same example further, so readers see continuity.

Diagram Strategy¶

Parts 1–2: Mermaid diagrams (simple, inline)
Parts 3–4: D2 diagrams (concept maps, process flows) — committed as D2 source + rendered SVG in doc/assets/diagrams/practice/architecture-practice-from-scratch/
Parts 5–7: Inline code blocks (Turtle, SHACL, SPARQL) with supporting Mermaid for architecture diagrams

Relationship to Existing Articles¶

Existing Article	Relationship
Build Your Own Metamodel	Part 5 provides the conceptual foundation; that article provides the implementation recipe
Build Your Own Modeling Tool	Part 7 frames the decision; that article is the "build" path
Architecture Knowledge Lifecycle	Provides theoretical backing for Parts 1 (lifecycle questions) and 4 (governance design)
EA on a Page Primer	Referenced throughout for CSVLOD classification and governance model
ArchiMate 4.0 Primer	Referenced throughout for modeling vocabulary
Zachman vs EA on a Page	Complementary reading for framework selection context

What This Series Does NOT Cover¶

Organizational change management (how to get buy-in for the initiative)
Specific vendor tool configuration (Sparx EA, Archi, LeanIX, etc.)
Data migration from existing tools (deserves its own guide)
Training and enablement programs