ArchiMate Model Quality
This skill provides guidance on creating high-quality, maintainable ArchiMate models.
Naming Conventions
Element Naming by Type
| Element Category |
Convention |
Examples |
| Structural Elements |
Singular Noun Phrases |
Customer Portal, Data Warehouse |
| Behavioral Elements |
Verb Phrases |
Manage Applications, Process Payments |
| Processes |
Present-tense Verb + Noun |
Handle Claim, Submit Order |
| Services |
Noun or Gerund Phrase |
Customer Information Service, Payment Processing |
| Capabilities |
Compound Noun/Gerund |
Risk Management, Customer Onboarding |
| Value Streams |
Verb-Noun Active |
Acquire Insurance Product |
General Guidelines
- Use Title Case for element names
- Use compound terms for clarity ("Student Information System" not "System")
- Avoid abbreviations unless domain-standard
- Don't include element type in name when tool shows it visually
- Use namespacing prefixes for large models:
[Business Systems][Customer System]
- Prefix views with state:
ASIS_ApplicationLandscape, TOBE_Integration
EA Smells (Quality Issues)
| EA Smell |
Description |
Correction |
| Lonely Component |
Element with no relations |
Connect or remove orphans |
| Strict Layers Violation |
Business directly linked to Technology |
Add Application layer intermediation |
| Dead Element |
Element not in any view |
Review for deletion or include |
| God Component |
One element with too many responsibilities |
Decompose into focused components |
| Chatty Interface |
Too many fine-grained relationships |
Consolidate at appropriate abstraction |
| Missing Relationship |
Implicit dependencies not modeled |
Make relationships explicit |
| Circular Dependencies |
Cyclic relationships |
Restructure to eliminate cycles |
Common Modeling Errors
- Mixing abstraction levels: Detailed processes alongside strategic capabilities
- Using Association as default: When specific relationship type applies
- Over-modeling: Every detail captured, creating maintenance burden
- Wrong element type: Using Process when Function is correct
- Missing services layer: Direct connections bypassing service abstraction
- View-centric thinking: Creating elements for single view, not reusing
- Inconsistent naming: Same concept with different names across views
Abstraction and Granularity
Abstraction Levels by Purpose
| Purpose |
Abstraction Level |
Audience |
| Informing |
High (Overview) |
CxOs, broad stakeholders |
| Deciding |
Medium (Coherence) |
Managers, analysts |
| Designing |
Low (Details) |
Subject matter experts |
Granularity by Element Type
| Element Type |
Right Level |
Over-Modeling Signs |
| Business Processes |
Level 2-3 decomposition |
Every task modeled |
| Applications |
Logical components |
Individual modules as components |
| Technology |
Platform/service level |
Individual servers |
| Capabilities |
2-3 levels deep |
Operational activities |
Key Principles
- 80/20 Rule: Only a subset of ArchiMate elements needed for most modeling
- Match stakeholder needs: Detail viewpoints = one layer/one aspect
- Limit view complexity: Target ~20 elements per view (40 max)
Viewpoint Selection
Stakeholder-to-Viewpoint Mapping
| Stakeholder Type |
Recommended Viewpoints |
| CxOs, Business Managers |
Strategy, Capability Map, Motivation |
| Enterprise Architects |
Layered, Application Cooperation, Implementation |
| Process Architects |
Business Process Cooperation, Service Realization |
| Application Architects |
Application Usage, Implementation and Deployment |
| Infrastructure Architects |
Technology, Technology Usage, Physical |
Pattern-to-Viewpoint Mapping
| Architecture Pattern |
Primary Viewpoints |
| Microservices |
Application Cooperation, Layered, Technology Usage |
| API/Integration |
Application Cooperation, Service Realization |
| Cloud Infrastructure |
Technology, Deployment, Layered |
| Data Architecture |
Information Structure, Application Cooperation |
| Capability Mapping |
Capability Map, Strategy, Resource Map |
Model Quality Checklist
Before Creating
During Modeling
Model Review
Model Organization
Folder Structure (By Layer)
Model
├── Strategy
├── Business
├── Application
├── Technology
├── Physical
├── Motivation
├── Implementation & Migration
├── Relations
└── Views
Folder Structure (By Domain)
Model
├── Customer Domain
│ ├── Business
│ ├── Application
│ └── Technology
├── Finance Domain
└── Shared Services
Additional Resources
Reference Files
For detailed viewpoint guidance and framework integration:
references/viewpoints.md - Complete ArchiMate viewpoints catalogreferences/framework-integration.md - TOGAF, BPMN, IT4IT integration patterns
1---2name: archimate-model-quality3description: This skill should be used when the user asks about "ArchiMate naming conventions", "model quality", "EA smells", "anti-patterns", "ArchiMate best practices", "model review", "abstraction levels", "viewpoints", "model organization", or needs guidance on creating high-quality ArchiMate models.4---56# ArchiMate Model Quality78This skill provides guidance on creating high-quality, maintainable ArchiMate models.910## Naming Conventions1112### Element Naming by Type1314| Element Category | Convention | Examples |15|-----------------|------------|----------|16| **Structural Elements** | Singular Noun Phrases | `Customer Portal`, `Data Warehouse` |17| **Behavioral Elements** | Verb Phrases | `Manage Applications`, `Process Payments` |18| **Processes** | Present-tense Verb + Noun | `Handle Claim`, `Submit Order` |19| **Services** | Noun or Gerund Phrase | `Customer Information Service`, `Payment Processing` |20| **Capabilities** | Compound Noun/Gerund | `Risk Management`, `Customer Onboarding` |21| **Value Streams** | Verb-Noun Active | `Acquire Insurance Product` |2223### General Guidelines2425- Use **Title Case** for element names26- Use compound terms for clarity ("Student Information System" not "System")27- Avoid abbreviations unless domain-standard28- Don't include element type in name when tool shows it visually29- Use namespacing prefixes for large models: `[Business Systems][Customer System]`30- Prefix views with state: `ASIS_ApplicationLandscape`, `TOBE_Integration`3132## EA Smells (Quality Issues)3334| EA Smell | Description | Correction |35|----------|-------------|------------|36| **Lonely Component** | Element with no relations | Connect or remove orphans |37| **Strict Layers Violation** | Business directly linked to Technology | Add Application layer intermediation |38| **Dead Element** | Element not in any view | Review for deletion or include |39| **God Component** | One element with too many responsibilities | Decompose into focused components |40| **Chatty Interface** | Too many fine-grained relationships | Consolidate at appropriate abstraction |41| **Missing Relationship** | Implicit dependencies not modeled | Make relationships explicit |42| **Circular Dependencies** | Cyclic relationships | Restructure to eliminate cycles |4344## Common Modeling Errors45461. **Mixing abstraction levels**: Detailed processes alongside strategic capabilities472. **Using Association as default**: When specific relationship type applies483. **Over-modeling**: Every detail captured, creating maintenance burden494. **Wrong element type**: Using Process when Function is correct505. **Missing services layer**: Direct connections bypassing service abstraction516. **View-centric thinking**: Creating elements for single view, not reusing527. **Inconsistent naming**: Same concept with different names across views5354## Abstraction and Granularity5556### Abstraction Levels by Purpose5758| Purpose | Abstraction Level | Audience |59|---------|------------------|----------|60| **Informing** | High (Overview) | CxOs, broad stakeholders |61| **Deciding** | Medium (Coherence) | Managers, analysts |62| **Designing** | Low (Details) | Subject matter experts |6364### Granularity by Element Type6566| Element Type | Right Level | Over-Modeling Signs |67|--------------|-------------|---------------------|68| **Business Processes** | Level 2-3 decomposition | Every task modeled |69| **Applications** | Logical components | Individual modules as components |70| **Technology** | Platform/service level | Individual servers |71| **Capabilities** | 2-3 levels deep | Operational activities |7273### Key Principles7475- **80/20 Rule**: Only a subset of ArchiMate elements needed for most modeling76- **Match stakeholder needs**: Detail viewpoints = one layer/one aspect77- **Limit view complexity**: Target ~20 elements per view (40 max)7879## Viewpoint Selection8081### Stakeholder-to-Viewpoint Mapping8283| Stakeholder Type | Recommended Viewpoints |84|-----------------|----------------------|85| **CxOs, Business Managers** | Strategy, Capability Map, Motivation |86| **Enterprise Architects** | Layered, Application Cooperation, Implementation |87| **Process Architects** | Business Process Cooperation, Service Realization |88| **Application Architects** | Application Usage, Implementation and Deployment |89| **Infrastructure Architects** | Technology, Technology Usage, Physical |9091### Pattern-to-Viewpoint Mapping9293| Architecture Pattern | Primary Viewpoints |94|---------------------|-------------------|95| Microservices | Application Cooperation, Layered, Technology Usage |96| API/Integration | Application Cooperation, Service Realization |97| Cloud Infrastructure | Technology, Deployment, Layered |98| Data Architecture | Information Structure, Application Cooperation |99| Capability Mapping | Capability Map, Strategy, Resource Map |100101## Model Quality Checklist102103### Before Creating104- [ ] Define scope and purpose105- [ ] Identify stakeholders and concerns106- [ ] Select appropriate viewpoints107- [ ] Establish naming conventions108109### During Modeling110- [ ] Follow naming conventions consistently111- [ ] Use correct element types112- [ ] Model at appropriate abstraction level113- [ ] Reuse existing elements (don't duplicate)114- [ ] Add descriptions to elements115116### Model Review117- [ ] Elements correctly typed118- [ ] Names follow conventions119- [ ] No orphaned elements120- [ ] No strict layer violations121- [ ] Relationships directionally correct122- [ ] Views tell coherent stories123124## Model Organization125126### Folder Structure (By Layer)127```128Model129├── Strategy130├── Business131├── Application132├── Technology133├── Physical134├── Motivation135├── Implementation & Migration136├── Relations137└── Views138```139140### Folder Structure (By Domain)141```142Model143├── Customer Domain144│ ├── Business145│ ├── Application146│ └── Technology147├── Finance Domain148└── Shared Services149```150151## Additional Resources152153### Reference Files154155For detailed viewpoint guidance and framework integration:156- **`references/viewpoints.md`** - Complete ArchiMate viewpoints catalog157- **`references/framework-integration.md`** - TOGAF, BPMN, IT4IT integration patterns
thomasrohde