Architecture Practice from Scratch — Part 2: Structuring Requirements into Viewpoints & Artifact Types¶
Part 1 produced a raw requirements summary: stakeholder concerns, viewpoint candidates, lifecycle rules, governance requirements. This part takes that unstructured input and organizes it into formal specifications precise enough to feed the metamodel conceptualization in Part 3.
The deliverable is a structured viewpoint catalog and artifact type specifications — still human-readable, no code, but precise enough that an enterprise architect or governance board can review and approve them.
The series:
- Stakeholder Discovery & Viewpoint Elicitation
- Structuring Requirements into Viewpoints & Artifact Types ← you are here
- Metamodel Conceptualized (upcoming)
- Governance & Lifecycle Management (upcoming)
- Formal Metamodel Definition (upcoming)
- Formal Governance & Validation (upcoming)
- Tool Integration (upcoming)
What We're Producing¶
By the end of this part, you'll have:
- A viewpoint catalog — each viewpoint fully specified with stakeholders, concerns, purpose, concept types, and CSVLOD classification
- An artifact type register — each artifact type classified along all five CSVLOD dimensions
- A cross-viewpoint dependency map — which viewpoints share concepts and how information flows between them
- Completeness criteria — what "good enough" looks like for each viewpoint
Step 1 — From Candidates to Viewpoint Specifications¶
Part 1 produced viewpoint candidates from stakeholder concerns. Now we formalize each one using a structure derived from ISO/IEC/IEEE 42010:
Viewpoint Specification Template¶
For each viewpoint, capture:
| Field | Description |
|---|---|
| Name | Short, descriptive identifier |
| Purpose | Why this viewpoint exists — Deciding, Designing, Informing, or Governing |
| Stakeholders | Who uses this viewpoint (roles, not people) |
| Key Question | The single most important question this viewpoint answers |
| Concerns Addressed | The specific concerns this viewpoint resolves |
| Concept Types | What element and relationship types appear in this viewpoint |
| CSVLOD Classification | Nature, focus, scope, lifecycle of the artifacts it produces |
| Governing Process | Which EA process owns this viewpoint |
| Source Viewpoints | Which other viewpoints provide input |
| Consuming Viewpoints | Which other viewpoints depend on this one |
| View Types | How it's typically rendered — diagram, matrix, catalog, or narrative |
Applying the Template: ACME Corp Viewpoints¶
Using the five viewpoint candidates from Part 1's worked example:
Viewpoint 1: Technology Radar¶
| Field | Value |
|---|---|
| Name | Technology Radar |
| Purpose | Governing, Deciding |
| Stakeholders | Enterprise Architect, CTO |
| Key Question | "Which technologies should we adopt, trial, hold, or retire?" |
| Concerns Addressed | Technology sprawl, obsolescence risk, standardization gaps |
| Concept Types | Technology Component, Technology Service, lifecycle status, adoption recommendation |
| CSVLOD Classification | Nature: Rules · Focus: IT-focused · Scope: Organization-wide · Lifecycle: Permanent |
| Governing Process | Technology Optimization |
| Source Viewpoints | Application Landscape (what technologies are in use) |
| Consuming Viewpoints | Solution Overview (constrains technology selection) |
| View Types | Matrix (radar rings), Catalog |
Artifacts produced: - Technology Reference Model (Essential) - Integration Patterns Catalog (Common — specialized guideline)
Viewpoint 2: Application Landscape¶
| Field | Value |
|---|---|
| Name | Application Landscape |
| Purpose | Informing, Deciding |
| Stakeholders | Enterprise Architect, Portfolio Manager, CTO |
| Key Question | "What applications do we have, who owns them, and how do they connect?" |
| Concerns Addressed | Duplication, integration complexity, orphaned systems, cost allocation |
| Concept Types | Application Component, Application Service, serving relationship, data flow, lifecycle status, owning team |
| CSVLOD Classification | Nature: Structures · Focus: IT-focused · Scope: Organization-wide · Lifecycle: Long-lived |
| Governing Process | Technology Optimization |
| Source Viewpoints | Technology Radar (standards compliance overlay) |
| Consuming Viewpoints | Solution Overview (integration context), Data Flow Map (application endpoints) |
| View Types | Diagram (boxes-and-arrows landscape), Catalog (application inventory) |
Artifacts produced: - Application Landscape Diagram (Essential) - Application Inventory (Common) - Enterprise System Portfolio (Common)
Viewpoint 3: Capability Heat Map¶
| Field | Value |
|---|---|
| Name | Capability Heat Map |
| Purpose | Deciding, Informing |
| Stakeholders | CTO, Enterprise Architect, Business Unit Heads |
| Key Question | "Where are the strategic capability gaps that need investment?" |
| Concerns Addressed | Strategic alignment, investment prioritization, capability maturity |
| Concept Types | Business Capability, maturity assessment, strategic initiative, gap, heat rating |
| CSVLOD Classification | Nature: Structures · Focus: Business-focused · Scope: Organization-wide · Lifecycle: Long-lived |
| Governing Process | Strategic Planning |
| Source Viewpoints | Application Landscape (which systems support which capabilities) |
| Consuming Viewpoints | Solution Overview (justifies new initiatives) |
| View Types | Diagram (capability map with heat overlay), Matrix |
Artifacts produced: - Enterprise Capability Map (Essential) - Digital Transformation Roadmap (Essential)
Viewpoint 4: Solution Overview¶
| Field | Value |
|---|---|
| Name | Solution Overview |
| Purpose | Deciding |
| Stakeholders | Solution Architect, Enterprise Architect, Business Sponsor |
| Key Question | "How does this proposed initiative fit into the existing landscape and standards?" |
| Concerns Addressed | Feasibility, integration risk, standards compliance, cost/benefit |
| Concept Types | Application Component, Business Process, Technology Service, interface, dependency, cost estimate, option |
| CSVLOD Classification | Nature: Changes · Focus: Business-focused · Scope: Initiative-scoped · Lifecycle: Short-lived |
| Governing Process | Initiative Delivery |
| Source Viewpoints | Application Landscape (environment), Technology Radar (constraints), Capability Heat Map (justification) |
| Consuming Viewpoints | Solution Design (provides basis) |
| View Types | Diagram (solution context), Narrative (options assessment) |
Artifacts produced: - Payment Platform Solution Overview (Essential)
Viewpoint 5: Data Flow Map¶
| Field | Value |
|---|---|
| Name | Data Flow Map |
| Purpose | Informing, Governing |
| Stakeholders | Data Protection Officer, Enterprise Architect, Compliance |
| Key Question | "Where does personal data flow, and is each flow justified and compliant?" |
| Concerns Addressed | GDPR compliance, data residency, unauthorized access, consent management |
| Concept Types | Data Object, Application Component, flow relationship, data classification, processing purpose, legal basis |
| CSVLOD Classification | Nature: Structures · Focus: IT-focused · Scope: Organization-wide · Lifecycle: Long-lived |
| Governing Process | Technology Optimization |
| Source Viewpoints | Application Landscape (system endpoints) |
| Consuming Viewpoints | Solution Overview (data impact assessment for new initiatives) |
| View Types | Diagram (data flow), Catalog (data register) |
Artifacts produced: - Personal Data Flow Map (specialized landscape diagram)
Step 2 — Classify Artifacts Along CSVLOD Dimensions¶
Each artifact from the viewpoint specifications gets classified along all five dimensions. This produces the artifact type register:
ACME Corp Artifact Type Register¶
| Artifact | CSVLOD Type | Nature | Focus | Scope | Lifecycle | Frequency | Process | Owner |
|---|---|---|---|---|---|---|---|---|
| Architecture Principles | Considerations | Rules | Business | Org-wide | Permanent | Essential | Strategic Planning | Enterprise Architect |
| Data Governance Policy | Considerations | Rules | Business | Org-wide | Permanent | Common | Strategic Planning | DPO |
| Cloud-First Direction | Considerations | Rules | Business | Org-wide | Permanent | Uncommon | Strategic Planning | CTO |
| Technology Reference Model | Standards | Rules | IT | Org-wide | Permanent | Essential | Tech Optimization | Enterprise Architect |
| Integration Patterns | Standards | Rules | IT | Org-wide | Permanent | Common | Tech Optimization | Enterprise Architect |
| Enterprise Capability Map | Visions | Structures | Business | Org-wide | Long-lived | Essential | Strategic Planning | Enterprise Architect |
| Digital Transformation Roadmap | Visions | Structures | Business | Org-wide | Long-lived | Essential | Strategic Planning | CTO |
| Application Landscape Diagram | Landscapes | Structures | IT | Org-wide | Long-lived | Essential | Tech Optimization | Enterprise Architect |
| Application Inventory | Landscapes | Structures | IT | Org-wide | Long-lived | Common | Tech Optimization | Portfolio Manager |
| Personal Data Flow Map | Landscapes | Structures | IT | Org-wide | Long-lived | Common | Tech Optimization | DPO |
| Payment Platform Solution Overview | Outlines | Changes | Business | Initiative | Short-lived | Essential | Initiative Delivery | Solution Architect |
| Payment Service Solution Design | Designs | Changes | IT | Project | Short-lived | Essential | Initiative Delivery | Solution Architect |
What This Register Gives You¶
- Coverage check — are all six CSVLOD types represented? (Yes — the practice covers all three processes)
- Ownership clarity — every artifact has exactly one owner role
- Lifecycle expectations — permanent artifacts need different governance than short-lived ones
- Maturity signal — having all six types indicates Stage Three maturity per EA on a Page
Step 3 — Map Cross-Viewpoint Dependencies¶
Viewpoints don't exist in isolation. Information flows between them — one viewpoint's output is another's input. Map these dependencies explicitly:
Dependency Matrix¶
| Viewpoint | Depends On | Shared Concepts | Dependency Type |
|---|---|---|---|
| Application Landscape | Technology Radar | Technology Component (compliance status) | Standards overlay |
| Capability Heat Map | Application Landscape | Application Component (supporting capability) | System-capability mapping |
| Solution Overview | Application Landscape | Application Component (integration context) | Environment context |
| Solution Overview | Technology Radar | Technology Component (allowed technologies) | Constraint |
| Solution Overview | Capability Heat Map | Business Capability (strategic justification) | Justification |
| Data Flow Map | Application Landscape | Application Component (flow endpoints) | System identity |
| Solution Overview | Data Flow Map | Data Object (data impact assessment) | Compliance check |
What Dependencies Tell You About the Metamodel¶
Each dependency identifies a shared concept — a type that must be defined once and referenced from multiple viewpoints. These shared concepts become the backbone of the metamodel:
| Shared Concept | Used By | Implication |
|---|---|---|
| Application Component | Landscape, Solution Overview, Data Flow Map, Capability Heat Map | Central entity — needs rich properties (owner, lifecycle, cost, integrations) |
| Technology Component | Technology Radar, Application Landscape, Solution Overview | Needs lifecycle status + adoption recommendation |
| Business Capability | Capability Heat Map, Solution Overview | Needs maturity rating + strategic priority |
| Data Object | Data Flow Map, Solution Overview | Needs classification (personal/sensitive) + processing purpose |
These are the concepts that Part 3 will model first — they're the load-bearing structures of the metamodel.
Step 4 — Define Completeness Criteria¶
For each viewpoint, define what "complete enough" means. This prevents both perfectionism (modeling every detail before anyone can use it) and inadequacy (publishing half-empty views that erode trust).
Completeness Criteria Template¶
| Viewpoint | Minimum Viable | Complete | Gold Standard |
|---|---|---|---|
| Technology Radar | All technology categories populated; each technology has an adoption recommendation (adopt/trial/hold/retire) | + lifecycle dates, replacement path for "retire" items | + cost data, skills availability, vendor risk |
| Application Landscape | All business-critical applications listed with owner and primary integrations | + all applications (incl. departmental), integration protocols, data flows | + cost, capacity metrics, technology stack detail |
| Capability Heat Map | L1 and L2 capabilities mapped; each L1 has a maturity assessment | + L3 capabilities, system-to-capability mapping, investment pipeline | + target maturity, gap analysis, benefit projections |
| Solution Overview | Problem statement, 2+ options with trade-offs, recommended option, integration impact | + cost estimate, timeline, standards compliance check, risk register | + benefit realization plan, transition architecture |
| Data Flow Map | All personal data flows identified with source, destination, legal basis | + data classification for all objects, retention periods, cross-border transfers | + automated lineage validation, consent flow mapping |
How Completeness Criteria Feed Governance¶
- Minimum Viable = the quality gate for initial publication (solution architects can produce this in a sprint)
- Complete = the quality gate for governance approval (architecture review board signs off at this level)
- Gold Standard = the target state for mature artifacts (achieved over time, not required at launch)
These levels will become SHACL severity levels in Part 6: Minimum Viable = sh:Violation (must have), Complete = sh:Warning (should have), Gold Standard = sh:Info (nice to have).
Step 5 — Produce the Structured Specification¶
Consolidate Steps 1–4 into the structured specification that feeds Part 3:
Specification Summary for ACME Corp¶
VIEWPOINT & ARTIFACT SPECIFICATION
===================================
VIEWPOINT CATALOG (5 viewpoints)
─────────────────────────────────
1. Technology Radar
Purpose: Governing, Deciding
Process: Technology Optimization
Nature: Rules · Focus: IT · Scope: Org-wide · Lifecycle: Permanent
Concepts: Technology Component, Technology Service, lifecycle status
Depends on: Application Landscape
Fed by: (none — root viewpoint)
2. Application Landscape
Purpose: Informing, Deciding
Process: Technology Optimization
Nature: Structures · Focus: IT · Scope: Org-wide · Lifecycle: Long-lived
Concepts: Application Component, Application Service, serving, data flow
Depends on: Technology Radar (overlay)
Feeds: Solution Overview, Data Flow Map, Capability Heat Map
3. Capability Heat Map
Purpose: Deciding, Informing
Process: Strategic Planning
Nature: Structures · Focus: Business · Scope: Org-wide · Lifecycle: Long-lived
Concepts: Business Capability, maturity, gap, strategic initiative
Depends on: Application Landscape
Feeds: Solution Overview
4. Solution Overview
Purpose: Deciding
Process: Initiative Delivery
Nature: Changes · Focus: Business · Scope: Initiative · Lifecycle: Short-lived
Concepts: Application Component, Business Process, Technology Service, option
Depends on: Application Landscape, Technology Radar, Capability Heat Map, Data Flow Map
Feeds: Solution Design (Part not yet in scope)
5. Data Flow Map
Purpose: Informing, Governing
Process: Technology Optimization
Nature: Structures · Focus: IT · Scope: Org-wide · Lifecycle: Long-lived
Concepts: Data Object, Application Component, flow, classification
Depends on: Application Landscape
Feeds: Solution Overview (compliance check)
SHARED CONCEPTS (metamodel backbone)
─────────────────────────────────────
- Application Component — used by 4 viewpoints (central entity)
- Technology Component — used by 3 viewpoints
- Business Capability — used by 2 viewpoints
- Data Object — used by 2 viewpoints
ARTIFACT TYPES (12 artifacts across 6 CSVLOD types)
─────────────────────────────────────────────────────
- 3 Considerations (permanent, business-focused)
- 2 Standards (permanent, IT-focused)
- 2 Visions (long-lived, business-focused)
- 3 Landscapes (long-lived, IT-focused)
- 1 Outline (short-lived, initiative-scoped)
- 1 Design (short-lived, project-scoped)
COMPLETENESS LEVELS
───────────────────
- Minimum Viable → sh:Violation in Part 6
- Complete → sh:Warning
- Gold Standard → sh:Info
How This Differs from Part 1¶
| Part 1 (Discovery) | Part 2 (Structuring) |
|---|---|
| "What do stakeholders need?" | "How do we organize what they need?" |
| Concern clusters | Formal viewpoint specifications |
| Lifecycle questions | Dimension classifications |
| Governance questions | Completeness criteria |
| Free-form notes | Structured, reviewable specification |
Part 1's output is a conversation record. Part 2's output is an architecture specification that a governance board can approve.
Practical Tips¶
Do¶
- Validate with stakeholders. Show each viewpoint specification back to the stakeholders who raised the concerns. Ask: "Does this cover what you need?"
- Start with 5–7 viewpoints. That's enough to cover the three EA processes. Add more based on demand, not speculation.
- Name shared concepts carefully. If Application Landscape calls something "System" and Solution Overview calls it "Application Component", resolve that now — not in Part 5 when it's encoded in OWL.
- Make dependencies explicit. If a viewpoint depends on another, the artifacts of the source viewpoint become prerequisites for the consuming viewpoint. This drives governance sequencing.
Don't¶
- Don't over-specify view types. At this stage, saying "diagram + catalog" is enough. The exact notation comes in Part 3.
- Don't conflate viewpoint with diagram. A viewpoint can produce multiple views (diagram, catalog, matrix). The viewpoint defines what information, not how it's rendered.
- Don't skip completeness criteria. Without them, every artifact is either "not done yet" or "done" — which means nothing gets published because perfection is unattainable.
What Comes Next¶
Part 3 takes this structured specification and produces the conceptual metamodel: concept maps showing elements, relationships, domain boundaries, and inheritance. Still visual, still reviewable, but precise enough for direct translation to RDF in Part 5.
References¶
- ISO/IEC/IEEE 42010:2022. Software, systems and enterprise — Architecture description.
- Kotusev, S. (2021). The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment. 2nd ed. SK Publishing.
- The Open Group. (2024). ArchiMate 4.0 Specification. https://pubs.opengroup.org/architecture/archimate4-doc/
- EA on a Page Primer & Modeling Guide
- ArchiMate 4.0 Primer & Modeling Guide
- Part 1 — Stakeholder Discovery & Viewpoint Elicitation
This is Part 2 of the Architecture Practice from Scratch series. Part 3: Metamodel Conceptualized continues from the structured specification produced here.