Skip to content

Architecture Practice from Scratch — Part 3: Metamodel Conceptualized

Part 2 produced a structured viewpoint catalog with shared concepts identified. This part turns that into a conceptual metamodel — the visual and narrative design that architects, governance boards, and stakeholders can review and approve before any code is written.

No Turtle. No OWL. Just diagrams, tables, and plain-language definitions precise enough to translate directly into RDF in Part 5.

The series:

  1. Stakeholder Discovery & Viewpoint Elicitation
  2. Structuring Requirements into Viewpoints & Artifact Types
  3. Metamodel Conceptualized ← you are here
  4. Governance & Lifecycle Management (upcoming)
  5. Formal Metamodel Definition (upcoming)
  6. Formal Governance & Validation (upcoming)
  7. Tool Integration (upcoming)

What We're Producing

By the end of this part, you'll have:

  1. A concept map showing all element types, their groupings, and hierarchical relationships
  2. An element catalog with plain-language definitions for every type
  3. A relationship catalog defining what connects to what and what it means
  4. Domain boundaries — which concepts belong to which domain
  5. A design decision log — the key choices made and their rationale

Step 1 — Identify the Element Types

Part 2's shared concepts analysis showed which concepts appear across viewpoints. Start there — they're the load-bearing structures. Then add the viewpoint-specific types.

From Shared Concepts to Element Types

Shared Concept (Part 2) Element Type Domain Why It's Central
Application Component ApplicationComponent Application Used by 4 of 5 viewpoints — the most connected type
Technology Component TechnologyComponent Technology Technology lifecycle management, standards compliance
Business Capability BusinessCapability Strategy Strategic planning anchor, investment justification
Data Object DataObject Common Compliance driver, flows between applications

Viewpoint-Specific Types

Each viewpoint introduces types that don't cross viewpoint boundaries (or cross only one):

Viewpoint Additional Types Domain
Technology Radar AdoptionRecommendation (adopt/trial/hold/retire) Technology
Application Landscape IntegrationPoint, Team (owning team) Application
Capability Heat Map MaturityAssessment, StrategicInitiative, Gap Strategy
Solution Overview Option, CostEstimate, RiskAssessment Implementation
Data Flow Map DataClassification, ProcessingPurpose, LegalBasis Common

The Full Element Catalog

# Element Type Domain Definition Example
1 Service Common An externally visible unit of functionality provided by any component — shared across Application, Technology, and Business "Process Payment", "Object Storage"
2 Process Common A sequence of behaviors that achieves a specific result — shared across domains "Order Fulfilment", "Incident Resolution"
3 DataObject Common A coherent, self-contained piece of information accessible by services "Customer Record", "Payment Transaction"
4 ApplicationComponent Application A modular, deployable, and replaceable part of a software system that encapsulates behavior and data "Payment Gateway", "Customer Portal"
5 IntegrationPoint Application A defined interface through which two application components exchange data or invoke services "REST API /payments/v2", "Event topic: order.placed"
6 TechnologyComponent Technology A physical or virtual technology resource — platform, runtime, database engine, framework "PostgreSQL 15", "Kubernetes 1.28", "Java 21"
7 AdoptionRecommendation Technology A governance classification indicating the recommended usage status of a technology "Adopt", "Trial", "Hold", "Retire"
8 BusinessCapability Strategy An ability the organization possesses or needs to achieve a business outcome "Payment Processing", "Customer Onboarding"
9 MaturityAssessment Strategy A point-in-time evaluation of a capability's maturity relative to target state "Payment Processing: Level 3 (Target: 4)"
10 StrategicInitiative Strategy A planned programme of work to close a capability gap or achieve a strategic goal "Payment Modernization Programme"
11 Team Motivation / Organization An organizational unit responsible for one or more application components "Payments Team", "Platform Engineering"
12 Gap Implementation & Migration An identified difference between current and target capability maturity "No real-time payment capability"
13 Option Implementation & Migration An alternative approach for implementing an initiative, with trade-offs "Option A: Buy SaaS vs Option B: Build in-house"
14 DataClassification Compliance Extension A sensitivity classification for a data object (personal, sensitive, public) "Personal Data (GDPR Art. 4)", "Public"
15 ProcessingPurpose Compliance Extension The stated purpose for processing a data object, as required by data protection regulation "Contract fulfilment", "Legitimate interest"
16 LegalBasis Compliance Extension The legal ground under which personal data is processed "GDPR Art. 6(1)(b) — Contract"

Step 2 — Define Domain Boundaries

Group elements into domains. Each domain is a coherent area of concern that a specific group of stakeholders understands:

Domain Map

Domain Elements Primary Stakeholders Description
Common DataObject, Service, Process All architects Cross-domain behavioral and structural elements shared across Application, Technology, and Business
Application ApplicationComponent, IntegrationPoint Enterprise Architect, Solution Architect, Portfolio Manager The application landscape — what software exists and how it connects
Technology TechnologyComponent, AdoptionRecommendation Enterprise Architect, CTO The technology stack — what platforms, runtimes, and tools are in use
Strategy BusinessCapability, MaturityAssessment, StrategicInitiative CTO, Enterprise Architect, Business Unit Heads Strategic planning — capabilities, maturity, investments
Motivation / Organization Team Portfolio Manager, Enterprise Architect Organizational structure relevant to architecture ownership
Implementation & Migration Gap, Option Solution Architect, Business Sponsor Transition and decision concepts (short-lived)
Compliance Extension DataClassification, ProcessingPurpose, LegalBasis DPO, Compliance GDPR-specific overlay — custom extension not in ArchiMate core

Design Decision: Reuse ArchiMate 4 Where Possible

ArchiMate 4 already defines many of these element types. Rather than inventing new types, we reuse ArchiMate concepts and extend only where the framework doesn't cover our needs:

Our Element ArchiMate 4 Equivalent Action
Service am4:Service Reuse directly (Common domain)
Process am4:Process Reuse directly (Common domain)
DataObject am4:DataObject Reuse directly (Common domain)
ApplicationComponent am4:ApplicationComponent Reuse directly
TechnologyComponent am4:TechnologyComponent Reuse directly
BusinessCapability am4:Capability Reuse directly
StrategicInitiative am4:WorkPackage Reuse (initiative maps to work package)
Gap am4:Gap Reuse directly
IntegrationPoint — Extend — not in ArchiMate core
Team — Extend — organizational assignment
AdoptionRecommendation — Extend — governance controlled vocabulary
MaturityAssessment — Extend — point-in-time evaluation
Option — Extend — decision modeling
DataClassification — Extend — compliance overlay
ProcessingPurpose — Extend — GDPR-specific
LegalBasis — Extend — GDPR-specific

Result: 8 types reused from ArchiMate 4, 8 types extended. The compliance extensions are a separate layer — organizations without GDPR requirements can omit them entirely.

Step 3 — Define the Relationships

Relationships connect element types. Define each with its meaning, source type, target type, and which viewpoints use it.

Relationship Catalog

# Relationship Source → Target Meaning Used By
1 realizes ApplicationComponent → Service "This application provides this service" Application Landscape, Solution Overview
2 serves ApplicationComponent → BusinessCapability "This application supports this capability" Capability Heat Map, Application Landscape
3 flowsTo ApplicationComponent → ApplicationComponent "Data flows from source to target" Data Flow Map, Application Landscape
4 runsOn ApplicationComponent → TechnologyComponent "This application is deployed on this technology" Application Landscape, Technology Radar
5 integratesWith ApplicationComponent → ApplicationComponent "These applications exchange data via an integration point" Application Landscape, Solution Overview
6 ownedBy ApplicationComponent → Team "This team is responsible for this application" Application Landscape
7 triggeredBy Service → Process "This service triggers this process when invoked" Solution Overview, Solution Design
8 hasRecommendation TechnologyComponent → AdoptionRecommendation "This technology has this governance recommendation" Technology Radar
9 hasMaturity BusinessCapability → MaturityAssessment "This capability is at this maturity level" Capability Heat Map
10 closesGap StrategicInitiative → Gap "This initiative addresses this gap" Capability Heat Map
11 addresses Option → StrategicInitiative "This option is a candidate approach for this initiative" Solution Overview
12 carriesData IntegrationPoint → DataObject "This integration carries this data" Data Flow Map
13 hasClassification DataObject → DataClassification "This data has this sensitivity classification" Data Flow Map
14 processedFor DataObject → ProcessingPurpose "This data is processed for this purpose" Data Flow Map
15 hasLegalBasis ProcessingPurpose → LegalBasis "This processing purpose is justified by this legal basis" Data Flow Map
16 exposedBy IntegrationPoint → ApplicationComponent "This integration point is provided by this application" Application Landscape

Relationship Semantics: What ArchiMate 4 Gives Us

Several of our relationships map directly to ArchiMate 4 relationship types:

Our Relationship ArchiMate 4 Equivalent Notes
realizes am4:realizes Direct reuse — Realization relationship
serves am4:serves Direct reuse — Serving relationship
flowsTo am4:flowsTo Direct reuse — Flow relationship
runsOn am4:realizes (inverted) Technology realizes Application
triggeredBy am4:triggers (inverted) Direct reuse — Triggering relationship
integratesWith — Extension — association with integration point detail
ownedBy — Extension — organizational assignment
Others — Domain extensions for governance, compliance, strategy

Step 4 — Concept Map

The concept map shows the full picture — all elements, their domains, and the relationships between them. This is what you present to stakeholders for review.

Conceptual metamodel for ACME Corp

Reading the Concept Map

  • Boxes are element types, grouped by domain (colour-coded)
  • Arrows are relationships, labeled with their meaning
  • Bold elements (ApplicationComponent, TechnologyComponent, BusinessCapability, DataObject) are the shared backbone — they cross viewpoint boundaries
  • Dashed boundary separates reused ArchiMate types from extensions

Domain Colour Key

Domain Colour ArchiMate 4 Hex Character
Common Warm grey #E5DFD3 Cross-domain behavioral and structural elements (Service, Process, DataObject)
Application Cyan #AFFFFF Software systems and their interfaces
Technology Green #AFFFAF Infrastructure, platforms, runtimes
Strategy Peach/Gold #F5DEAA Capabilities, resources, value streams
Motivation / Organization Lavender #CBCBFF People, teams, stakeholders
Implementation & Migration Pink #FFE0E0 Transition concepts (Gap, WorkPackage, Option)
Compliance Extension Dashed border — GDPR-specific overlay (not in ArchiMate core)

Step 5 — Design Decision Log

Record the key design choices and their rationale. These will be referenced in Part 5 when translating to RDF:

DD-1: Reuse ArchiMate 4 Types as Base Language

Decision: Reuse ArchiMate 4 element and relationship types where they exist. Extend with custom types only for domain-specific concepts not covered by ArchiMate.

Rationale: ArchiMate 4 is a well-established, tool-supported modeling language. Reusing its types means: - Existing ArchiMate models can be imported without transformation - Tools that understand ArchiMate understand our base types - Less vocabulary to learn for architects already familiar with ArchiMate

Consequence: The metamodel depends on the ArchiMate 4 ontology. Custom types subclass arch:Element directly, not ArchiMate types (to avoid coupling extension semantics to ArchiMate's internal class hierarchy).

DD-2: Flat Extension Types (No Deep Inheritance)

Decision: Extension types (IntegrationPoint, Team, AdoptionRecommendation, etc.) are direct subclasses of arch:Element. No multi-level inheritance hierarchies for custom types.

Rationale: Deep inheritance creates coupling — changing a mid-hierarchy class affects everything below it. For a practice-specific metamodel, flat is maintainable. If a concept doesn't clearly "inherit" behavior from another, it shouldn't subclass it.

Consequence: Some types (e.g., IntegrationPoint) might share properties with ArchiMate types (e.g., am4:Interface). We use rdfs:seeAlso to declare similarity without formal inheritance.

DD-3: Data Compliance as First-Class Domain

Decision: Data classification, processing purpose, and legal basis are modeled as first-class element types — not as annotation properties on DataObject.

Rationale: GDPR compliance requires querying "all flows of personal data", "all processing without valid legal basis", etc. If these are just string annotations, those queries are impossible. As typed elements with relationships, they're fully queryable.

Consequence: The metamodel is richer than a pure infrastructure model. This adds maintenance cost (someone must keep legal basis current). Part 4 will define who owns this.

DD-4: Governance Classifications as Controlled Vocabularies

Decision: AdoptionRecommendation, DataClassification, MaturityAssessment levels are modeled as SKOS concept schemes (controlled vocabularies) — not as OWL classes or free-text fields.

Rationale: These are closed, organization-defined value sets that change slowly and require governance approval to modify. SKOS gives: - Enumerable values (adopt/trial/hold/retire) - Labels and definitions - Hierarchy if needed (e.g., Personal Data → Special Category Data) - Change tracking via concept scheme versioning

Consequence: Validating that an element has a valid classification requires a SHACL constraint checking against the concept scheme (Part 6).

DD-5: Viewpoint Boundaries Are Not Model Partitions

Decision: The metamodel is one connected graph. Viewpoints are lenses (filters) on that graph — they don't partition it into separate models.

Rationale: An ApplicationComponent appears in the Landscape viewpoint, the Solution Overview, the Data Flow Map, and the Capability Heat Map. It's one element with one IRI, seen from different angles. Partitioning into separate models would create duplication and synchronization problems.

Consequence: Viewpoint conformance (what's allowed in a viewpoint) is enforced through SHACL viewpoint shapes (Part 6) — not through separate model boundaries.

How This Connects to Part 5

Every element type becomes an OWL class. Every relationship becomes an OWL object property. Every domain becomes a namespace grouping. Every controlled vocabulary becomes a SKOS concept scheme. The design decisions become comments and rdfs:seeAlso links in the Turtle files.

Part 3 Concept Part 5 Formalization
Element type owl:Class subclassing arch:Element or ArchiMate type
Relationship owl:ObjectProperty with domain/range constraints
Domain Namespace grouping (same file or namespace prefix)
Controlled vocabulary skos:ConceptScheme with skos:Concept members
Design decision Comment block + dcterms:description on the ontology

Practical Tips

Do

  • Present the concept map first. Stakeholders grasp visual structures faster than tables. Use the map as the conversation anchor, then drill into the catalog for details.
  • Name things in stakeholder language. If the CTO calls it "Technology Radar", name the viewpoint and its artifacts that way — even if ArchiMate calls it something different internally.
  • Keep the design decision log. Every choice you don't record will be re-debated in 6 months. Future architects need to know why, not just what.
  • Validate with data. Take 3–5 real artifacts from the organization and try to classify them using your element and relationship types. If they don't fit cleanly, the model needs adjustment.

Don't

  • Don't over-model. 16 element types and 14 relationships is plenty for a mid-size enterprise. If you're above 30 element types, you're probably modeling too fine-grained for the practice to maintain.
  • Don't model what you won't maintain. Every relationship type implies someone will create and update instances. If nobody will populate hasLegalBasis, remove it from the metamodel.
  • Don't confuse conceptual model with data model. This is an ontology — it defines types and relationships, not database tables. Instances will be created by architects, not ETL processes.

What Comes Next

Part 4 defines the governance and lifecycle management for this metamodel: who maintains each artifact type, review cadences, quality gates, evolution rules, and retirement processes. The conceptual metamodel tells you what can be modeled. Governance tells you who keeps it alive.

References

This is Part 3 of the Architecture Practice from Scratch series. Part 4: Governance & Lifecycle Management continues from the conceptual metamodel produced here.