企业架构本质上是复杂的。它涉及业务流程、应用服务、技术基础设施和数据对象等多个层次。当这些元素在一个单一模型中相互作用时，生成的图表可能会令人难以承受。利益相关者常常难以在纷繁的信息中抓住重点。这正是“”ArchiMate视点”这一概念变得至关重要。
视点不仅仅是一种绘图风格；它是一种用于构建视图的正式规范。它定义了视图的目的、受众以及在特定上下文中相关的架构具体方面。如果没有对选择和定义这些视点采取严谨的方法，架构文档将失去其价值。本指南探讨了选择正确视点的机制，以确保清晰性和一致性。
🧩 理解ArchiMate建模环境
在选择视点之前，必须理解其背后的语言。ArchiMate提供了一套标准化的符号，用于描述、分析和可视化企业架构。它基于一个元模型，定义了概念之间的关系。
架构并非一个简单的项目列表。它被组织成多个层次和领域。这些结构使架构师能够从水平和垂直两个方向来分解复杂性。然而，单一的图表很少能满足所有目的。目标是隔离特定的关注点，使信息对目标读者来说易于理解。
-
层次：战略、业务、应用、技术和物理层次提供了水平分割。
-
领域：业务、应用、技术和数据领域提供了垂直分割。
-
方面：动机、实施与迁移以及外部方面为模型增添了深度。
当你观察整个模型时，你看到的是架构。当你观察由视点定义的特定切片时，你看到的是一个视图。视点决定了该切片的切割方式。
🔍 视图与视点：定义两者之间的区别
视图与视点之间的混淆很常见。区分它们是有效建模的第一步。
|
概念 |
定义 |
类比 |
|---|---|---|
|
视图 |
从相关利益相关者的视角对系统进行的表示。它是实际的成果或图表。 |
建筑物的照片。 |
|
视点 |
用于构建视图的规范，包括惯例、规则和模板。它定义了展示什么内容以及如何展示。 |
拍摄照片所使用的相机设置和镜头。 |
如果你在没有明确视角的情况下创建图表，可能会包含无关的细节，或遗漏关键信息。视角相当于架构师与利益相关者之间的契约。它回答了这样一个问题：“你需要看到哪些信息才能做出决策？”
🎯 识别利益相关者关切
选择视角的主要驱动因素是利益相关者。不同角色需要不同层次的抽象和不同的数据点。通用模型很少能满足所有人。你必须将具体关切映射到具体的视角。
考虑以下角色及其典型需求：
-
高管层： 关注战略、价值实现以及高层次的能力映射。他们需要看到业务目标与IT能力之间的关联。
-
业务经理： 关注流程、组织结构以及工作流。他们需要能够突出瓶颈或冗余的流程视图。
-
应用架构师： 关注软件服务、接口和数据结构。他们需要看到系统之间的依赖关系，以管理技术债务。
-
基础设施工程师： 关注服务器、网络和物理位置。他们需要能够将服务映射到硬件的技术视图。
-
合规官： 需要能够突出安全控制、数据隐私和合规性要求的视图。
为了选择正确的视角，请提出以下问题：
-
主要受众是谁？
-
他们试图做出什么决策？
-
支持该决策需要多高的细节程度？
-
这个受众熟悉哪些术语？
📊 为你的目标选择合适的视角
在识别出利益相关者后，选择过程将转向视图的技术定义。视图的目标决定了视角的选择。常见的目标包括差距分析、迁移规划、影响分析或能力映射。
1. 差距分析视角
这些视角将当前状态（现状）与未来状态（目标）进行比较。它们突出显示缺失的能力或技术。该视角必须支持对两个不同模型或层级之间差异的可视化。
2. 迁移视角
在规划迁移时，该视角必须展示时间线和依赖关系。它需要说明哪些元素将被弃用，哪些将被添加，以及实施的顺序。
3. 影响分析视角
当发生变更时（例如新法规或软件升级），该视角会展示其连锁反应。它聚焦于依赖关系和分配关系等，以追踪影响范围。
4. 能力映射视角
这些是高层次的战略视图。它们将业务能力映射到支撑它们的应用程序和技术。这有助于确定投资优先级。
🛠️ 核心ArchiMate层及其含义
ArchiMate 定义了特定的层级。选择一个视图通常涉及选择包含哪些层级。包含过多层级可能导致认知过载。包含过少层级则可能掩盖上下文。
业务层
关注业务结构、流程、角色和互动。此处的视图对于将业务战略与执行对齐至关重要。它们回答“谁在做什么以及如何做？”
应用层
关注支持业务的软件应用。此处的视图展示应用组合、接口和服务。它们回答“什么软件在运行业务？”
技术层
关注硬件和基础设施。此处的视图展示服务器、网络和设备。它们回答“软件在哪里运行？”
物理层
关注技术的物理位置。这通常是技术层的一个子集，但对于灾难恢复和地理分布规划至关重要。
在定义视图时，应明确哪些层级处于激活状态。业务视图应排除应用和技术细节，除非它们直接用于上下文参考。技术视图应排除业务细节，除非它们与基础设施需求相关。
📋 常见视图类别详解
尽管自定义视图很常见，但 ArhchiMate 社区中存在标准类别。理解这些有助于采用最佳实践。
|
类别 |
主要关注点 |
典型受众 |
|---|---|---|
|
业务流程视图 |
活动、流程和流程。 |
流程负责人、业务分析师 |
|
应用交互视图 |
应用之间的接口和通信。 |
应用架构师 |
|
技术部署视图 |
将软件映射到硬件。 |
基础设施架构师 |
|
价值流视图 |
从客户到提供者的价值创造步骤。 |
战略规划者 |
|
实施与迁移视图 |
分阶段和过渡。 |
项目经理 |
采用标准类别时，请确保其定义符合您的组织需求。如果您的组织需要在这些流程中特别关注合规性，那么一个通用的“业务流程视角”可能不够。
⚠️ 视角定义中的常见陷阱
创建视角是一项专业工作。存在一些常见错误，会降低架构的有效性。
-
过度定义： 定义过于僵化的视角。它应在不破坏标准的前提下，允许必要的变化。
-
定义不足： 定义视角过于宽泛。这会导致不一致的图表，使读者困惑。
-
忽略元数据： 视角必须包含元数据，例如目的、受众和相关层级。缺少这些信息，视角将缺乏上下文。
-
忽略语言约束： ArchiMate 对关系有特定规则。视角必须强制执行这些规则，以保持模型的完整性。
-
静态定义： 视角应持续演进。随着组织的变化，利益相关者的需求也在变化。五年前有效的视角，今天可能需要调整。
另一个常见错误是创建“一刀切”的模型。执行摘要图不应与技术设计图看起来一样。视角定义必须明确说明抽象层次。
🔁 长期保持视角的一致性
一旦选定并定义了某个视角，就必须持续维护。这包括治理和版本管理。
1. 命名规范
为视角使用清晰且一致的命名。名称中应包含领域和层级。例如，“业务层 – 流程流转视角”比“流程视角”更清晰。
2. 模板管理
如果您使用建模工具，请根据视角定义模板。这可确保每位架构师都从相同的图标、颜色和布局规则开始。
3. 审查周期
安排对视角库的定期审查。是否存在重复？是否有某些视角从未被使用？是否有新的利益相关者群体出现，需要新的视角？
4. 文档化
为每个视角保留文档。解释其存在的原因、展示的内容以及如何解读。这可以减轻新成员的培训负担。
🧭 选择的实用步骤
为了将这一知识付诸实践，当出现新的建模需求时，请遵循以下工作流程。
-
识别需求： 需要回答的具体问题是什么？
-
识别利益相关者： 谁需要这个答案？
-
检查现有视角： 是否已存在一个符合此需求的标准视角？
-
定义自定义视角： 如果没有标准视角适用，则定义一个新的视角。明确需要包含的层级、概念和关系。
-
验证： 将草稿视角展示给一个代表性利益相关者。它是否回答了他们的问题？
-
发布： 将该视角添加到中央存储库或库中。
此流程确保每个图表都有其用途。它防止了未使用模型的积累，避免了架构存储库的混乱。
🔗 关系与约束
ArchiMate 高度依赖关系。一个视角必须明确哪些关系是可见的。在模型中显示所有关系会形成一张无法阅读的蛛网。
常见的需要包含或排除的关系：
-
访问： 对理解数据流通常至关重要，但可能使高层视图变得杂乱。
-
分配： 对展示谁对什么负责至关重要，但在基础设施视图中无关紧要。
-
服务： 对应用到业务的关系至关重要。
-
实现： 对理解设计元素如何实现目标非常重要。
视角定义应明确列出允许的关系类型。这一约束简化了可视化，并强化了架构意图。
🎨 视觉风格与呈现
尽管视角的逻辑至关重要，但视觉风格同样重要。视角应定义视觉编码方式。
-
颜色编码： 定义哪些颜色代表特定领域或状态。
-
图标设计： 为不同概念类型统一形状。
-
布局： 定义首选布局，例如流程采用自上而下，流程图采用从左到右。
视觉风格的一致性降低了读者的认知负担。他们无需为每张新图表重新学习图例。视角充当了可视化的风格指南。
📈 衡量视角有效性的方法
你怎么知道一个视角是否有效？你可以通过反馈和使用数据来衡量其有效性。
-
反馈循环：询问利益相关者该视角是否帮助他们做出了决策。
-
使用频率：追踪哪些视角被使用得最多。使用率低可能表明该视角过于复杂或不相关。
-
查询响应时间：如果该视角用于报告，它能否快速生成数据？性能是选择时需要考虑的因素。
有效的视角是那些能够缩短理解时间的视角。它们将复杂的数据转化为清晰的信息。
🚀 展望未来
企业架构的格局持续演变，新技术和新方法不断涌现。视角必须保持灵活性以适应这些变化。核心原则始终不变：视需求而定。
通过严格遵循上述选择标准，可以确保您的架构模型始终保持有价值的资产。它们将变成沟通工具，而不仅仅是文档工作。这种严谨性有助于组织内做出更好的决策。
