关于 ArchiMate Model Quality
ArchiMate Model Quality 是用于创建和维护清晰 ArchiMate 模型的指导技能。内容涵盖命名、模型粒度、视点、组织方式，以及常见结构和关系问题的检查。
主要功能
- 01遵循元素命名约定
- 02选择合适的抽象层次与粒度
- 03按利益相关者匹配视点
- 04按层或领域组织模型
- 05检查关系和模型异味
适用场景
- 01在创建 ArchiMate 模型前制定规范
- 02根据利益相关者关注点选择视图
- 03检查模型中的孤立或类型错误元素
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/archimate-model-quality确认已加载。
附带文件references/framework-integration.mdreferences/viewpoints.md
详细介绍
ArchiMate 模型质量
本技能提供创建高质量、易于维护的 ArchiMate 模型的指导。
命名规范
按类型命名元素
| 元素类别 | 规范 | 示例 |
|---|---|---|
| 结构元素 | 单数名词短语 | Customer Portal、Data Warehouse |
| 行为元素 | 动词短语 | Manage Applications、Process Payments |
| 流程 | 现在时动词 + 名词 | Handle Claim、Submit Order |
| 服务 | 名词或动名词短语 | Customer Information Service、Payment Processing |
| 能力 | 复合名词 / 动名词 | Risk Management、Customer Onboarding |
| 价值流 | 动词-名词主动形式 | Acquire Insurance Product |
通用指南
- 元素名称使用标题式大小写
- 使用复合术语以提高清晰度（使用“Student Information System”，而不是“System”）
- 除非缩写是领域标准，否则避免使用缩写
- 如果工具会以可视方式显示元素类型，则不要将元素类型包含在名称中
- 对于大型模型，使用命名空间前缀：
[Business Systems][Customer System] - 使用状态作为视图前缀：
ASIS_ApplicationLandscape、TOBE_Integration
EA 异味（质量问题）
| EA 异味 | 描述 | 修正方法 |
|---|---|---|
| 孤立组件 | 没有关系的元素 | 为孤立元素建立连接或将其删除 |
| 严格分层违规 | 业务直接连接到技术 | 添加应用层作为中介 |
| 无效元素 | 不属于任何视图的元素 | 检查是否应删除或纳入视图 |
| 上帝组件 | 一个元素承担过多职责 | 将其拆分为职责明确的组件 |
| 过度交互的接口 | 过多细粒度关系 | 在适当的抽象层次进行合并 |
| 缺少关系 | 未建模的隐式依赖 | 明确建模这些关系 |
| 循环依赖 | 循环关系 | 重构以消除循环 |
常见建模错误
- 混合抽象层次：将详细流程与战略能力放在一起
- 默认使用关联关系：适用特定关系类型时仍使用关联关系
- 过度建模：捕获每个细节，增加维护负担
- 元素类型错误：应使用 Function 时却使用 Process
- 缺少服务层：绕过服务抽象进行直接连接
- 以视图为中心思考：为单个视图创建元素，而不重复利用
- 命名不一致：同一概念在不同视图中使用不同名称
抽象与粒度
按用途划分的抽象层次
| 用途 | 抽象层次 | 受众 |
|---|---|---|
| 告知 | 高（概览） | CxO、高层利益相关者 |
| 决策 | 中（连贯性） | 管理者、分析师 |
| 设计 | 低（细节） | 领域专家 |
按元素类型划分的粒度
| 元素类型 | 合适层次 | 过度建模的迹象 |
|---|---|---|
| 业务流程 | 第 2 至 3 级分解 | 对每项任务都建模 |
| 应用 | 逻辑组件 | 将单个模块作为组件 |
| 技术 | 平台 / 服务层次 | 单个服务器 |
| 能力 | 深入 2 至 3 层 | 运营活动 |
核心原则
- 80/20 法则：大多数建模只需要 ArchiMate 元素的一个子集
- 匹配利益相关者的需求：详细视点 = 一个层次 / 一个方面
- 限制视图复杂度：每个视图目标约 20 个元素（最多 40 个）
视点选择
利益相关方类型与视角映射
| 利益相关方类型 | 推荐视角 |
|---|---|
| CxO、业务经理 | 战略、能力地图、动机 |
| 企业架构师 | 分层、应用协作、实施 |
| 流程架构师 | 业务流程协作、服务实现 |
| 应用架构师 | 应用使用、实施与部署 |
| 基础设施架构师 | 技术、技术使用、物理 |
模式与视角映射
| 架构模式 | 主要视角 |
|---|---|
| 微服务 | 应用协作、分层、技术使用 |
| API/集成 | 应用协作、服务实现 |
| 云基础设施 | 技术、部署、分层 |
| 数据架构 | 信息结构、应用协作 |
| 能力映射 | 能力地图、战略、资源地图 |
模型质量检查清单
创建前
- 明确范围和目的
- 确定利益相关方及其关注点
- 选择适当的视角
- 制定命名约定
建模期间
- 始终遵循命名约定
- 使用正确的元素类型
- 选择适当的抽象级别进行建模
- 重用现有元素（不要重复创建）
- 为元素添加描述
模型审查
- 元素类型正确
- 名称遵循约定
- 没有孤立元素
- 没有严格的层级违规
- 关系方向正确
- 视图能够讲述连贯的故事
模型组织
文件夹结构（按层）
Model
├── Strategy
├── Business
├── Application
├── Technology
├── Physical
├── Motivation
├── Implementation & Migration
├── Relations
└── Views
文件夹结构（按领域）
Model
├── Customer Domain
│ ├── Business
│ ├── Application
│ └── Technology
├── Finance Domain
└── Shared Services
其他资源
参考文件
有关视角指导和框架集成的详细信息：
references/viewpoints.md- 完整的 ArchiMate 视角目录references/framework-integration.md- TOGAF、BPMN、IT4IT 集成模式
评论
支持 Markdown