Skip to content

Architecture Practice from Scratch — Part 4: Governance & Lifecycle Management

Part 3 produced a conceptual metamodel — the element types, relationships, and domains. That tells you what can be modelled. This part defines who keeps it alive: governance roles, review cadences, quality gates, evolution rules, and retirement processes.

Without governance, a metamodel becomes shelfware within 6 months. This is the operational backbone.

The series:

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

What We're Producing

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

  1. A governance model — tier structure, bodies, escalation paths
  2. A RACI matrix — who is Responsible, Accountable, Consulted, Informed for each artifact type
  3. Review cadences — how often each artifact class gets reviewed and what triggers ad-hoc reviews
  4. Quality gates — the checkpoints artifacts must pass at each lifecycle stage
  5. Evolution rules — how the metamodel itself changes over time
  6. Retirement process — how artifacts are decommissioned without losing institutional memory

Background: The Architecture Knowledge Lifecycle describes the full seven-stage model (conceive → capture → validate → share → apply → evolve → retire) that this governance design must support.

Step 1 — Define the Governance Model

Choosing a Tier Model

EA on a Page describes three governance arrangements (Part 1, Step 4). For ACME Corp (2,000 staff, 150 applications), the two-tier model is appropriate:

ACME Corp governance model — two tiers with three bodies and escalation paths

Tier Scope Focus
Enterprise Organization-wide artifacts Strategic direction, standards, landscapes, capabilities
Solution Initiative/project-scoped artifacts Solution overviews, designs, implementation decisions

A three-tier model (adding domain architects) would be overkill at this size. A one-tier model would overload the enterprise architects with project-level reviews.

Governance Bodies

Body Composition Meets Responsibility
Architecture Steering Group CTO, Enterprise Architects, Business Unit Heads Quarterly Approves Considerations and Visions, resolves strategic conflicts, oversees practice health
Architecture Review Board (ARB) Enterprise Architects, Solution Architects (rotating) Fortnightly Reviews Outlines and Designs, checks standards compliance, approves solution approaches
Technology Council Enterprise Architects, Senior Engineers, Security Lead Monthly Governs the Technology Reference Model, reviews adoption recommendations, manages technology lifecycle

Escalation Path

Solution Architect → ARB → Architecture Steering Group → CTO
  • ARB handles: solution-level disagreements, standards exceptions, integration conflicts
  • Steering Group handles: strategic direction changes, cross-business-unit conflicts, budget allocation for architecture work
  • CTO handles: unresolved escalations, practice-level decisions (hire architects, change tooling)

Step 2 — RACI Matrix

For each artifact type, define who is Responsible (does the work), Accountable (approves), Consulted (provides input), Informed (needs to know):

Permanent Artifacts (Rules)

Artifact Responsible Accountable Consulted Informed
Architecture Principles Enterprise Architect Steering Group Business Unit Heads, CTO All architects, Engineering Leads
Data Governance Policy DPO Steering Group Enterprise Architect, Legal All teams handling personal data
Cloud-First Direction CTO Steering Group Enterprise Architects, Engineering Leads All delivery teams
Technology Reference Model Enterprise Architect Technology Council Senior Engineers, Security Lead Solution Architects, Engineering Leads
Integration Patterns Catalog Enterprise Architect Technology Council Solution Architects, Senior Engineers Delivery teams

Long-Lived Artifacts (Structures)

Artifact Responsible Accountable Consulted Informed
Enterprise Capability Map Enterprise Architect Steering Group Business Unit Heads Portfolio Manager, Solution Architects
Digital Transformation Roadmap CTO Steering Group Enterprise Architects, Business Unit Heads All architects
Application Landscape Diagram Enterprise Architect Enterprise Architect Portfolio Manager, Solution Architects Steering Group
Application Inventory Portfolio Manager Enterprise Architect Team leads (per application) Steering Group, Finance
Personal Data Flow Map DPO DPO Enterprise Architect, Application Owners Compliance, Steering Group

Short-Lived Artifacts (Changes)

Artifact Responsible Accountable Consulted Informed
Solution Overview Solution Architect ARB Enterprise Architect, Business Sponsor Steering Group (summary)
Solution Design Solution Architect ARB Enterprise Architect, Engineering Lead Delivery team

Step 3 — Review Cadences

Scheduled Reviews

Review cadences by artifact lifecycle class with staleness thresholds

The review cadences are organized by the CSVLOD lifecycle classification defined in the EA on a Page taxonomy:

Lifecycle Class Taxonomy Concept CSVLOD Types Governance Meaning
Permanent eaoptax:Permanent Considerations, Standards Created once, updated periodically — rules that persist across initiatives
Long-lived eaoptax:LongLived Visions, Landscapes Maintained continuously, evolving as the organization changes
Short-lived eaoptax:ShortLived Outlines, Designs Produced for a specific initiative/project, then archived

Within a lifecycle class, different artifact types may have different operational cadences (e.g., Standards are reviewed quarterly while Considerations are reviewed annually) — the lifecycle class defines the nature of maintenance, while the cadence defines the frequency.

Artifact Class Lifecycle Review Cadence Review Depth Reviewer
Considerations Permanent Annually (aligned with strategy cycle) Full content review — still relevant? Still followed? Steering Group
Standards Permanent Quarterly Technology currency — any "retire" candidates? New "adopt" additions? Technology Council
Visions Long-lived Annually (post-strategy) Alignment with updated business strategy Steering Group
Landscapes Long-lived Quarterly Reconcile against CMDB, check for missing/decommissioned systems Enterprise Architect
Outlines Short-lived At initiative gates (initiation, mid-point) Standards compliance, integration feasibility ARB
Designs Short-lived At project gates (design, pre-delivery) Implementation readiness, deviation from outline ARB

Event-Triggered Reviews

Beyond scheduled cadences, certain events trigger immediate review:

Trigger Event Artifacts Affected Action
Major acquisition or divestiture All Visions, capability map, landscapes Full re-baseline within 90 days
Regulatory change (GDPR update, new sector regulation) Data Governance Policy, Data Flow Map, affected Standards Impact assessment within 30 days
Critical incident (outage caused by architecture gap) Related Landscapes, Standards, Designs Post-incident review, update affected artifacts
Technology end-of-life announcement Technology Reference Model, affected Landscapes Add "retire" recommendation, assess affected applications
New strategic initiative approved Capability Map (add gap/initiative), Roadmap Update within sprint of approval

Staleness Detection

An artifact is considered stale when:

Lifecycle Class Stale After Action on Staleness
Permanent Missed annual review Flag to Steering Group, block new approvals referencing it
Long-lived Missed quarterly reconciliation OR 6 months without update Flag to owner, add "needs review" status
Short-lived 30 days after initiative/project closes Archive automatically, notify owner

Step 4 — Quality Gates

Each artifact passes through lifecycle stages. Define what must be true at each gate:

Lifecycle Stages

Artifact lifecycle stages — from Draft through Current to Retired

Draft → Under Review → Approved → Current → Needs Review → Superseded/Retired

Gate Definitions

Gate From → To What Must Be True Who Approves
Submit for Review Draft → Under Review All "minimum viable" fields populated (per Part 2 completeness criteria) Author (self-assessed)
Approve Under Review → Approved Peer review passed, no blocking conflicts with existing artifacts, governance body sign-off ARB or Steering Group (per artifact class)
Publish Approved → Current Approved artifact is accessible in the repository, supersession links created if replacing an existing artifact Enterprise Architect (mechanical step)
Flag for Review Current → Needs Review Scheduled review date reached, or event trigger fired Automated (staleness detection)
Supersede Current → Superseded New version approved, supersession chain recorded, old version remains accessible but clearly marked Governance body that approved the original
Retire Current/Superseded → Retired Artifact no longer applicable (system decommissioned, initiative closed), cascading impact assessed Owner + governance body confirmation

Completeness Criteria at Each Gate (per Part 2)

Gate Minimum Viable (must-have) Complete (should-have) Gold Standard (nice-to-have)
Submit for Review ✅ Required — —
Approve ✅ Required ✅ Required —
Publish ✅ Required ✅ Required Optional

These map directly to SHACL severity levels in Part 6: - Minimum Viable → sh:Violation (blocks submission) - Complete → sh:Warning (blocks approval) - Gold Standard → sh:Info (advisory)

Step 5 — Evolution Rules

The metamodel itself evolves — new element types, new relationships, new viewpoints. Define how that happens without breaking existing content:

Metamodel Change Classification

Change Type Impact Approval Required Examples
Additive New types, properties, or viewpoints — no existing content affected Technology Council Add "CostCenter" element type, add "sustainability" viewpoint
Deprecation Existing type marked as deprecated, migration path defined Steering Group Deprecate "IntegrationPoint" in favour of ArchiMate Interface
Breaking Existing type removed or semantics changed — existing content must migrate Steering Group + 90-day migration period Rename relationship, change domain/range constraint

Versioning Rules

  • Metamodel version follows semantic versioning: MAJOR.MINOR.PATCH
  • MAJOR: breaking changes
  • MINOR: additive changes (new types, viewpoints)
  • PATCH: definition corrections, documentation updates
  • Artifact instances do not version-stamp to the metamodel version — they're validated against the current metamodel at query time
  • SHACL shapes version-track alongside the metamodel — a MINOR bump may add new shapes (warnings for new required fields)

Change Process

  1. Propose — any architect can propose a metamodel change via a change request
  2. Assess — Enterprise Architect evaluates impact (how many existing instances affected?)
  3. Approve — appropriate body approves (per change type above)
  4. Implement — metamodel files updated, SHACL shapes adjusted, validation run against existing content
  5. Communicate — change note published, affected artifact owners notified
  6. Migrate — for breaking changes, 90-day window for content owners to update instances

Step 6 — Retirement Process

Retirement is not deletion. It's marking knowledge as no longer active while preserving institutional memory.

What Gets Retired

Trigger Artifacts to Retire Cascading Check
Application decommissioned Related Designs, Integration Points, Data Flows Update Landscape, check Capability Map (is capability still covered?)
Initiative completed Solution Overview, Solution Design Archive with outcome (successful? partial? cancelled?)
Technology end-of-life reached Technology Reference Model entry, related Standards Update Landscape (what still runs on it?), create migration initiative
Principle superseded Old Principle artifact Verify no Designs or Outlines still reference it as active constraint
Organization restructured Affected team assignments, governance body compositions Update Landscape ownership, verify capability map alignment

Retirement Checklist

For each artifact being retired:

  • Set lifecycle status to Retired
  • Record retirement reason and date
  • Link to successor (if superseded) or note "no replacement needed"
  • Check for active references from other artifacts — notify owners
  • Remove from active viewpoint queries (but keep accessible in archive queries)
  • Update landscape/inventory counts
  • Record outcome for short-lived artifacts (initiative: successful/cancelled; design: built as designed/deviated)

Archive vs. Active

State Visible in Active Queries Visible in Archive Queries Editable Purpose
Current ✅ ✅ ✅ Active governance
Needs Review ✅ (flagged) ✅ ✅ Maintenance trigger
Superseded ❌ ✅ ❌ (read-only) Historical reference
Retired ❌ ✅ ❌ (read-only) Institutional memory

Worked Example: ACME Corp Governance Summary

Governance Model

  • Two-tier: Enterprise + Solution
  • Three bodies: Steering Group (quarterly), ARB (fortnightly), Technology Council (monthly)
  • Escalation: Solution Architect → ARB → Steering Group → CTO

Key Cadences

  • Principles and Capability Map: annual review (January, aligned with strategy)
  • Technology Reference Model: quarterly review (March, June, September, December)
  • Application Landscape: quarterly reconciliation against ServiceNow CMDB
  • Data Flow Map: annual review + triggered on regulatory change
  • Solution artifacts: per-initiative gates

Quality Gate Summary

  • 12 artifacts in the practice
  • 5 permanent (annual governance review)
  • 5 long-lived (quarterly maintenance)
  • 2 short-lived (gate-based, archived on closure)

First-Year Milestones

Month Milestone
1 Governance bodies established, RACI agreed, initial artifact stubs created
3 First Technology Council review, Technology Reference Model baselined
6 First ARB cycle complete, 2+ Solution Overviews reviewed, Landscape reconciled
9 First staleness detection run, stale artifacts flagged and addressed
12 Annual Steering Group review, Principles and Capability Map refreshed, practice health assessment

Process Framework Alignment

The governance design above is expressed in operational terms — bodies, cadences, gates. It also maps cleanly onto the formal architecture processes of ISO/IEC/IEEE 42020, which Linked.Archi publishes as a queryable vocabulary (iso42020:, built on the Architecture Processes extension). Naming the mapping lets you position this practice against a recognized standard without changing any of the design decisions.

ISO 42020 process Where it appears in this series
iso42020:ArchitectureGovernance Step 1 governance model, bodies, and escalation path; the Steering Group and ARB directing and controlling architecture work
iso42020:ArchitectureManagement Step 2 RACI, Step 3 review cadences, and the first-year milestones — planning, organizing, and controlling the architecture effort
iso42020:ArchitectureConceptualization Parts 1–3: stakeholder discovery, viewpoint elicitation, and conceptual metamodel
iso42020:ArchitectureEvaluation Step 4 quality gates and the Part 6 SHACL/SPARQL checks; for scenario-based evaluation of a specific architecture, see ATAM Evaluation in Practice
iso42020:ArchitectureElaboration Part 5 formal metamodel definition, where conceptual artifacts are refined into implementation-ready RDF
iso42020:ArchitectureEnablement Step 5 evolution rules and Part 7 tooling — establishing and maintaining the methods, tools, and iso42020:ArchitectureRepository that keep the practice running

A few points to keep the mapping honest:

  • These are concurrent, repeating processes, not sequential phases. The series presents them in a build order for teaching, but in a running practice governance, management, and enablement operate continuously alongside conceptualization, evaluation, and elaboration.
  • ISO 42020 says what processes a practice needs; it does not prescribe bodies, cadences, or a repository technology. The choices in Steps 1–6 are one valid realization, not the only one.
  • If your organization frames its work in TOGAF ADM terms, the governance bodies here play the ADM Phase G (Implementation Governance) and the Architecture Board role, while the artifact lifecycle corresponds to the ADM's iterative development of Architecture Definition content. The series does not follow the ADM phase structure — it is organized around the CSVLOD artifact model instead.

To query which processes a modelled practice actually exercises, type your governance instances against the ISO 42020 vocabulary and traverse ap: properties. See the Processes Modelling Guide for the full usage pattern.

Who Owns Enablement?

The governance design so far answers "who owns the content" — the artifacts. It leaves a second question unanswered: who owns the means — the metamodel, the repository, the SHACL shapes, the generation pipeline, the tool integrations, the modelling methods? That is the job of Architecture Enablement (iso42020:ArchitectureEnablement), which corresponds directly to establishing and running TOGAF's Architecture Capability — the organization structures, processes, roles, and repository that let an architecture function operate at all.

The distinction is means vs. ends:

  • Enterprise, Solution, and Technical architects produce architecture — the ends: models, decisions, designs, evaluations.
  • Architecture Enablement produces and maintains the means of architecture — the repository, the metamodel, the tooling, and the methods that make everyone else's work possible.

This series builds those means in the parts that follow: the metamodel and ontologies in Part 5, the SHACL shapes and validation in Part 6, and the generation pipeline, tooling, and AI access in Part 7. Enablement is the function that keeps all of that alive after launch.

The architecture enablement unit operates the architecture platform consumed by the three architect roles under the governance bodies The enablement unit operates the architecture platform (repository, metamodel, tooling, methods) as an internal product. Architects populate and consume it; governance bodies hold it accountable.

Does it need a dedicated unit?

The function is always required; whether it becomes a standalone unit depends on scale and how asset-heavy the practice is. The operative rule: a named process with continuous outputs needs a single accountable owner.

Practice scale How to assign enablement
Small (like ACME's two-tier model) Not a separate unit. Assign it as an explicit accountability to a lead/chief architect, governed by the Technology Council. The point is that it is named and owned — not that it needs headcount.
Large / asset-heavy / AI-ready A dedicated Architecture Enablement team is justified — a platform-style team that runs the "architecture platform" as an internal product, with genuine engineering and product skills (ontology, SHACL, CI/CD, integration).

The "platform team running an internal product" framing comes from Team Topologies: enablement is a platform team (it provides the repository and tooling as a product to other architects) with a touch of enabling team (it raises modelling competence across the practice). The Open Group's Leader's Guide to Establishing and Evolving an EA Capability covers the organizational structures, roles, and funding for standing up this function in larger organizations.

Leaving enablement as "everyone's responsibility" makes it no one's, which produces exactly the shelfware, schema drift, and broken-integration failure modes this part exists to prevent.

Accountability split — schema vs. instance

Enablement extends the Part 2 RACI with one clean boundary:

Layer Accountable Responsible
Schema (metamodel, ontologies, SHACL, repository, tooling) Architecture Enablement Architecture Enablement
Instances (the architecture artifacts themselves) Governance bodies (ARB / Steering Group) Enterprise / Solution / Technical architects

Enablement provides the rails; governance sets the rules; architects drive the train. Enablement does not approve models or make architecture decisions — that stays with the governance bodies.

Relationship with the architect roles

The model is supply/demand with feedback loops, not hierarchy:

Role Relationship to Architecture Enablement
Enterprise Architect Primary customer. Defines which concepts, viewpoints, and standards the metamodel must support (demand); enablement realizes them in the schema and tooling (supply). Closest partnership — EA drives what, enablement delivers how.
Solution Architect Highest-volume consumer/producer. Uses templates, validation, and tooling daily; feeds back friction and gaps that shape the backlog.
Technical Architect Co-owner of integration. The platform touches CI/CD, triplestore, CMDB, Backstage, and MCP (the tooling built in Part 7) — so enablement either carries the engineering skill itself or partners closely with technical architects.

Making it traceable

Record the enablement owner as an ap:ProcessRole so the accountability is queryable, not just documented:

ex:ArchitectureEnablementLead a ap:ProcessRole ;
    skos:prefLabel "Architecture Enablement Lead"@en ;
    ap:responsibleFor iso42020:ArchitectureEnablement .

iso42020:ArchitectureEnablement
    ap:governs ex:ArchitectureRepository ;
    iso42020:maintains ex:ArchitectureRepository .

ex:ArchitectureRepository a iso42020:ArchitectureRepository ;
    skos:prefLabel "ACME Architecture Repository"@en .

This lets a governance query answer "who owns our enablement function, and what does it maintain?" directly from the graph — the same way the SPARQL health checks in Part 6 assess coverage and staleness.

Practical Tips

Do

  • Start governing before you're "ready." The first ARB meeting can review one Solution Overview. You don't need a perfect metamodel to start governance — you need governance to make the metamodel worth building.
  • Make staleness visible. A dashboard showing "3 artifacts past review date" creates healthy pressure. Hidden staleness is silent decay.
  • Separate authority from authorship. The Enterprise Architect writes the Technology Reference Model but the Technology Council approves it. This prevents single points of failure.
  • Keep the retirement backlog. Track retired artifacts and their outcomes. This is gold for pattern mining — "last time we chose SaaS for payment processing, it went well because..."

Don't

  • Don't over-govern short-lived artifacts. A Solution Design that lives for 3 months doesn't need quarterly review. Gate-based governance (review at submission, archive at closure) is enough.
  • Don't skip the RACI conversation. Ambiguous ownership is the #1 cause of stale artifacts. If two people think the other is responsible, nobody updates it.
  • Don't forget the metamodel itself. The governance model governs both the instances (architecture artifacts) and the schema (metamodel evolution). Neglecting the latter means the metamodel drifts from reality.
  • Don't treat governance as bureaucracy. If an ARB meeting adds no value, it should be shorter or less frequent — not eliminated. The rhythm is what keeps knowledge current.

What Comes Next

Part 5 takes the conceptual metamodel (Part 3) and this governance design (Part 4) and formalizes them into RDF: OWL classes for element types, SKOS concept schemes for controlled vocabularies, a metamodel manifest, and viewpoint definitions. The governance rules defined here become the requirements for the SHACL shapes in Part 6.

References

Worked Example: Browse the ACME Corp Artifact Catalog to see the concepts from this series applied to a fictional mid-size enterprise.

This is Part 4 of the Architecture Practice from Scratch series. Part 5: Formal Metamodel Definition continues by translating the conceptual metamodel and governance requirements into RDF.