Skip to content

Architecture Practice from Scratch

How do you go from nothing — no metamodel, no governance, no repository — to a fully governed, tool-integrated architecture practice that is open, interoperable, and AI-ready?

This series answers that question in seven parts. It starts with business-level conversations and ends with formal semantic assets that a tool can consume. Each part produces a concrete deliverable that feeds the next, and each can stand alone at its level of formality.

Who This Is For

Organizations facing one or more of these situations:

  • Starting from zero — no formal architecture practice exists, and leadership has decided to introduce one
  • Increasing maturity — ad-hoc architecture work exists but lacks governance, consistency, or tool support
  • Replacing tooling — migrating from proprietary, siloed tools to an open, connected approach
  • Going semantic — making architectural knowledge machine-readable, queryable, and AI-ready

If you already have a working metamodel and want to extend or customize it, Build Your Own Metamodel is the shorter path. This series covers the thinking that comes before that — and the governance and tooling that comes after.

The Approach

The series uses two reference frames:

EA on a Page provides the governance and artifact structure. Its CSVLOD taxonomy classifies architecture artifacts by nature, focus, and lifecycle. Its three core processes (Strategic Planning, Technology Optimization, Initiative Delivery) define who produces and consumes each artifact type. See the EA on a Page Primer.

ArchiMate 4.0 provides the modeling vocabulary. Its domain-based structure and typed relationships give a classification backbone for expressing architecture concepts formally. See the ArchiMate 4.0 Primer.

Together they answer the complete set of questions: EA on a Page tells you which artifacts your practice needs and who uses them; ArchiMate tells you what concepts and relationships those artifacts contain.

The Architecture Knowledge Lifecycle provides the theoretical backing for how architectural knowledge is conceived, captured, validated, shared, applied, evolved, and retired — the operational reality that the governance design in Part 4 must support.

The Series

Part Title What It Produces
1 Stakeholder Discovery & Viewpoint Elicitation Requirements summary: stakeholder register, viewpoint candidates, lifecycle rules, governance requirements
2 Structuring Requirements into Viewpoints & Artifact Types Structured viewpoint catalog, artifact type specifications, cross-viewpoint dependencies
3 Metamodel Conceptualized Concept maps, element/relationship catalog, domain boundaries, design decisions
4 Governance & Lifecycle Management Governance handbook: roles, cadences, quality gates, evolution rules, retirement processes
5 Formal Metamodel Definition OWL ontology, SKOS taxonomy, metamodel manifest, viewpoint definitions in RDF
6 Formal Governance & Validation SHACL shapes, CI/CD pipeline configuration, SPARQL governance queries
7 Tool Integration Build-or-buy decision framework, integration architecture patterns

Progression

The series follows a deliberate arc from business to technical:

Series progression — from business-level discovery through conceptual design, formal definition, to implementation

You can stop at any boundary:

  • After Part 2 you have a structured requirements document — enough to brief a vendor or internal team
  • After Part 4 you have a complete conceptual architecture practice design — reviewable by governance boards and architecture managers without any technical background
  • After Part 6 you have a tool-ready set of semantic assets — consumable by any RDF-aware repository
  • After Part 7 you have a running practice with tooling in place

Worked Example

A fictional mid-size enterprise (2,000 staff, 150 applications, 3 business units) threads through the entire series, growing in detail with each part:

  • Part 1 introduces the stakeholders and their concerns
  • Part 2 structures those into five viewpoints
  • Part 3 maps the concepts and relationships
  • Part 4 defines who governs what and when
  • Parts 5–6 produce the formal Turtle and SHACL files
  • Part 7 connects those assets to tooling