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 modeled. 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 (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 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

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

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.