Skip to content

Architecture Practice from Scratch — Part 1: Stakeholder Discovery & Viewpoint Elicitation

Most architecture practice efforts fail not because of bad modeling — but because nobody asked the right people the right questions first.

This is Part 1 of a series that guides you from early stakeholder conversations through to a fully governed, tool-integrated architecture practice built on open, interoperable, and AI-ready semantic foundations. This first instalment stays entirely at the business level: no Turtle, no OWL, no SHACL. Just the questions, patterns, and thinking that produce a solid requirements foundation.

The series:

  1. Stakeholder Discovery & Viewpoint Elicitation ← you are here
  2. Structuring Requirements into Viewpoints & Artifact Types (upcoming)
  3. Metamodel Conceptualized (upcoming)
  4. Governance & Lifecycle Management (upcoming) — connects to the Architecture Knowledge Lifecycle
  5. Formal Metamodel Definition (upcoming)
  6. Formal Governance & Validation (upcoming)
  7. Tool Integration (upcoming) — build-or-buy framing, refers to Build Your Own Modeling Tool

Who This Series Is For

Organizations that need to stand up — or fundamentally reshape — their architecture practice. Typical triggers:

  • Increasing architecture maturity from ad-hoc to governed
  • Introducing or replacing an architecture repository toolset
  • Moving from proprietary, siloed tools to an open, connected, semantically rich approach
  • Making architectural knowledge machine-readable and AI-ready

The series assumes no existing metamodel or formal practice. If you already have one and want to extend it, Build Your Own Metamodel is the shorter path.

Why This Matters

A metamodel defines what can be expressed in an architecture practice — the concepts, relationships, views, and rules that shape how an organization describes itself. But the metamodel is only one piece. A working practice also needs governance (who maintains what, when, and how), tool integration (how the metamodel connects to repositories, validators, and generators), and a maintenance lifecycle (how the practice evolves without rotting).

Get any of these wrong and you end up with either:

  • A model nobody uses because it doesn't answer their questions
  • A model everyone uses differently because it lacks constraints
  • A model that can't evolve because nobody knows who owns what
  • A tool that enforces rules nobody agreed to

The fix is straightforward: treat the architecture practice as a product and the stakeholders as its users. Start with their information needs, not with a taxonomy of element types.

The Reference Frame: EA on a Page + ArchiMate 4

This article uses two reference points:

EA on a Page provides the governance and artifact structure — the what, who, and when of architecture information. Its CSVLOD taxonomy classifies artifacts by their nature (rules vs. structures vs. changes), focus (business vs. IT), and lifecycle (permanent → long-lived → short-lived). See the EA on a Page Primer for a full introduction.

ArchiMate 4.0 provides the modeling language — the vocabulary for expressing architecture concepts. Its domain-based structure (Business, Application, Technology, Strategy, Motivation, Implementation & Migration) and typed relationships give a classification backbone for any metamodel that needs to describe enterprise architecture. See the ArchiMate 4.0 Primer.

Together they answer a 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 can contain.

Step 1 — Identify Your Stakeholders

Before defining any concept or relationship, identify who will consume and produce architecture information. Not "stakeholders" in the abstract — real roles with real information needs.

The Key Question

"Who makes decisions that depend on architecture information, and who produces the information those decisions require?"

A Practical Stakeholder Map

Use this as a starting template and adapt to your organization:

Stakeholder Role Typical Concerns Consumes Produces
CxO / Board Investment direction, risk, capability gaps Roadmaps, capability models, heat maps Strategic priorities, funding decisions
Enterprise Architect Coherence, standards compliance, target state Landscapes, principles, patterns Visions, standards, governance rules
Solution Architect Feasibility, integration, delivery risk Standards, landscapes, patterns Solution overviews, designs
Portfolio Manager Cost, duplication, lifecycle planning Inventories, landscapes, heat maps Portfolio classifications, retirement decisions
Engineering Lead Implementation detail, dependencies, contracts Designs, interface specs, deployment views Technical designs, build artefacts
Risk / Compliance Regulatory adherence, data sensitivity Data flows, system classifications, controls Compliance assessments, exception registers
Data Steward Data ownership, quality, lineage Data landscapes, data flows, glossaries Data definitions, quality rules

What to Avoid

  • Don't list 40 stakeholder types. Focus on the 5–8 roles that produce or consume architecture artifacts regularly.
  • Don't conflate a person with a role. One person may fill multiple roles, but the metamodel serves the role's information needs — not the person's preferences.

Step 2 — Elicit Viewpoints Through Concerns

A viewpoint is not a diagram template. It is the frame through which a specific stakeholder understands the enterprise. The metamodel exists to populate those frames with structured data.

The Key Questions

Ask each stakeholder group:

  1. "What decisions do you make that depend on architecture information?" → This reveals the actual use of the model. If a CxO needs to decide where to invest, the model must express capabilities, gaps, and strategic alignment.

  2. "What questions do you ask that nobody can answer quickly today?" → This reveals the gaps in the current practice. Unanswered questions point directly at missing concepts or relationships.

  3. "When you get a document or diagram today, what's missing or confusing?" → This reveals quality and completeness issues. If solution architects complain that landscape diagrams lack integration points, that's a metamodel gap.

  4. "Who do you need to share information with, and in what form?" → This reveals cross-viewpoint dependencies. A data flow diagram that an engineer produces may be exactly what a compliance officer needs — but rendered differently.

From Concerns to Viewpoint Candidates

Group the answers into clusters. Each cluster is a candidate viewpoint:

Concern Cluster Stakeholders Candidate Viewpoint Key Concepts Needed
"What capabilities do we have and where are the gaps?" CxO, Enterprise Architect Capability Assessment Capability, maturity, gap, strategic initiative
"Which systems support this business process?" Portfolio Manager, Solution Architect Application Landscape Application, process, serving relationship, lifecycle status
"What data flows between systems?" Data Steward, Compliance, Engineering Data Flow Data object, application, flow relationship, classification
"What does the target state look like for this domain?" Enterprise Architect, CxO Target Architecture Current/target element states, transition, roadmap
"How does this solution integrate with existing systems?" Solution Architect, Engineering Integration & Dependencies Interface, service, dependency, protocol

Mapping to EA on a Page

Each viewpoint candidate maps naturally to the CSVLOD structure:

  • Capability Assessment → Visions (business-focused, long-lived, strategic planning process)
  • Application Landscape → Landscapes (IT-focused, long-lived, technology optimization process)
  • Data Flow → Landscapes or Designs (depending on scope)
  • Target Architecture → Visions (business-focused, long-lived)
  • Integration & Dependencies → Outlines or Designs (initiative-scoped, short-lived)

This mapping tells you which EA process owns the viewpoint, how long its artifacts live, and who governs updates. That governance context is something most metamodel efforts ignore until it's too late.

Step 3 — Define the Data Lifecycle

A metamodel without lifecycle rules is a schema waiting to rot. Every concept in your metamodel will have instances that are created, maintained, and eventually retired. Define this early.

Background: The Architecture Knowledge Lifecycle article describes the full seven-stage lifecycle (conceive → capture → validate → share → apply → evolve → retire) and explains how each stage demands different tooling and governance. The questions below are derived from that model.

The Key Questions

  1. "Who is the authoritative source for this information?" → Determines data ownership. If the CMDB is the source of truth for application inventory, the metamodel should reference it — not duplicate it.

  2. "How often does this information change?" → Determines update frequency and governance overhead. Principles change rarely; solution designs change weekly during delivery.

  3. "What triggers an update?" → Determines the events that drive maintenance. A new project approval triggers outline creation; a decommissioning decision triggers landscape updates.

  4. "What happens when this information becomes stale?" → Determines retirement and archiving rules. Outdated landscape diagrams are worse than no diagrams — they erode trust.

Lifecycle Classification (Derived from CSVLOD)

Lifecycle Class Update Frequency Governance Retirement Trigger Example Artifacts
Permanent Annually or on governance trigger Architecture board approval Superseded by new version Principles, standards, technology reference models
Long-lived Quarterly or on significant change Enterprise architect review Irrelevance (org restructure, strategy pivot) Capability models, landscape diagrams, inventories
Short-lived Weekly during active use Solution architect ownership Project closure or delivery Solution overviews, designs, integration specs

Data Ownership Template

For each concept cluster that will become part of the metamodel, capture:

Concept Area Authoritative Source Owner Role Review Cadence Consumers
Application inventory CMDB / ServiceNow Portfolio Manager Quarterly All viewpoints referencing applications
Business capabilities Strategy team Enterprise Architect Annually Strategic planning, portfolio heat maps
Solution designs Project teams Solution Architect Per sprint (active) Engineering, integration testing
Data classifications Data governance office Data Steward On regulatory change Compliance, data flow views

Step 4 — Assess Governance Requirements

The metamodel doesn't just define what can be modeled — it implies how the practice is governed. Make that explicit.

The Key Questions

  1. "Who can create or modify instances of this type?" → Determines authoring permissions. Not everyone should be able to change a principle or modify the reference architecture.

  2. "What quality gates must an artifact pass before it's considered authoritative?" → Determines validation and approval workflows. A solution design might need peer review; a landscape diagram might need reconciliation against the CMDB.

  3. "How do you know the model is complete enough for its purpose?" → Determines completeness criteria. A viewpoint that requires cost information but has none populated is incomplete — the metamodel should express that expectation.

  4. "What are the consequences of non-compliance?" → Determines enforcement level. If ignoring a standard has no consequence, it's not really a standard — it's a suggestion. The metamodel should distinguish these.

Governance Tiers (Derived from EA on a Page)

EA on a Page describes governance through architecture tiers and governance bodies:

Tier Scope Governed By Artifacts Governed Enforcement
Enterprise Organization-wide Architecture board / CTO office Principles, standards, capability models, reference architectures Mandatory compliance, exception process
Domain Business unit or technology domain Domain architect / domain governance body Domain landscapes, domain standards, patterns Compliance within domain, escalation path
Solution Project or initiative Solution architect / project board Solution overviews, designs, deployment specs Peer review, architecture sign-off gate

What This Means for the Metamodel

Each governance tier implies different metamodel requirements:

  • Enterprise-tier concepts need version control, approval status, effective dates, and exception tracking
  • Domain-tier concepts need scope boundaries, domain ownership, and cross-domain dependency declarations
  • Solution-tier concepts need project context, lifecycle status, and traceability to higher-tier constraints

Step 5 — Consolidate into a Requirements Summary

After Steps 1–4, consolidate findings into a structured summary that becomes the input for Part 2 (viewpoint structuring) and Part 3 (formal metamodel definition).

Requirements Summary Template

METAMODEL REQUIREMENTS SUMMARY
==============================

1. STAKEHOLDER REGISTER
   - [Role]: [Key concerns], [Artifacts consumed], [Artifacts produced]
   - ...

2. VIEWPOINT CATALOG (candidates)
   - [Viewpoint Name]
     - Stakeholders: [who uses it]
     - Key Question: [the decision it supports]
     - Concepts Required: [element/relationship types needed]
     - CSVLOD Classification: [type + lifecycle]
     - Governing Process: [strategic planning / tech optimization / initiative delivery]

3. DATA LIFECYCLE RULES
   - [Concept Area]: source=[system], owner=[role], cadence=[frequency], retirement=[trigger]
   - ...

4. GOVERNANCE REQUIREMENTS
   - [Tier]: [scope], [governance body], [enforcement level]
   - Quality gates: [description]
   - Completeness criteria: [description]

5. CROSS-VIEWPOINT DEPENDENCIES
   - [Viewpoint A] depends on [Viewpoint B] for: [shared concepts]
   - ...

6. CONSTRAINTS & NON-GOALS
   - What the metamodel explicitly will NOT cover
   - Integration points with existing systems (CMDB, PPM, etc.)
   - Known limitations accepted by stakeholders

Worked Example: A Mid-Size Enterprise

To make this concrete, here's a compressed example for a fictional mid-size enterprise (2,000 staff, 150 applications, 3 business units):

Stakeholders Identified

  • CTO (investment decisions)
  • 2 Enterprise Architects (coherence, standards)
  • 6 Solution Architects (delivery)
  • 1 Portfolio Manager (application lifecycle)
  • 1 Data Protection Officer (GDPR compliance)

Viewpoint Candidates Derived

Viewpoint Key Question CSVLOD Type Process
Technology Radar "What should we adopt, hold, or retire?" Standards Technology Optimization
Application Landscape "What do we have and who owns it?" Landscapes Technology Optimization
Capability Heat Map "Where are the strategic gaps?" Visions Strategic Planning
Solution Overview "How does this initiative fit?" Outlines Initiative Delivery
Data Flow Map "Where does personal data flow?" Landscapes Technology Optimization

ArchiMate 4 Concept Coverage

Each viewpoint maps to ArchiMate 4 concepts that will form the metamodel vocabulary in Part 3:

Viewpoint ArchiMate 4 Domains Involved Key Element Types
Technology Radar Technology, Common Technology Service, Technology Component, Artifact
Application Landscape Application, Technology Application Component, Application Service, Node
Capability Heat Map Strategy, Business Capability, Resource, Value Stream
Solution Overview All domains Application Component, Business Process, Technology Service
Data Flow Map Application, Common Data Object, Application Component, Flow relationship

This mapping provides a direct bridge from business requirements to the formal language that Part 3 will use to define the metamodel in RDF.

Practical Tips for Stakeholder Conversations

Do

  • Start with decisions, not diagrams. Ask "what decisions does this support?" before "what should the diagram look like?"
  • Use existing artifacts as conversation starters. Bring current documents, spreadsheets, and diagrams to interviews. Ask "what's missing? what's wrong? what do you ignore?"
  • Timebox discovery. Two weeks of conversations with 5–8 stakeholders is enough for a first pass. Perfectionism kills metamodel initiatives.
  • Capture what they don't want. Constraints and non-goals are as valuable as requirements. "We don't model below the application layer" is a critical boundary.

Don't

  • Don't show stakeholders a metamodel diagram. They don't care about class hierarchies. Show them the viewpoints and artifacts the metamodel will enable.
  • Don't ask "what concepts do you need?" That's your job to derive from their concerns. Ask about their questions, decisions, and pain points instead.
  • Don't try to be comprehensive. A metamodel that covers 6 viewpoints well is worth more than one that covers 20 poorly. Start narrow, extend based on demand.
  • Don't ignore the maintenance story. For every concept you add, someone has to keep instances current. If nobody will maintain it, don't model it.

What Comes Next

Part 2 takes the requirements summary produced here and structures it into formal viewpoint definitions, artifact type specifications, and concept dependencies — still human-readable, but precise enough to feed the conceptualization phase.

Part 3 conceptualizes the metamodel: concept maps, relationship diagrams, and domain boundaries — the visual and narrative design that everyone from architects to business stakeholders can review before any code is written.

Part 4 defines governance and lifecycle management: who maintains what, review cadences, quality gates, and evolution rules. This is the operational backbone that keeps the practice alive after launch.

Parts 5 and 6 formalize the design into RDF — first the metamodel itself (OWL classes, SKOS taxonomies, metamodel manifest), then the governance rules as SHACL shapes with CI/CD integration.

Part 7 frames the build-or-buy decision for tooling and refers to Build Your Own Modeling Tool for the implementation path.

References

This is Part 1 of the Architecture Practice from Scratch series. Part 2: Structuring Requirements into Viewpoints & Artifact Types continues from the requirements summary produced here.