|
企业架构建模的视点机制及其示例（基于ArchiMate3.1） |
| 作者：俎涛 （火龙果软件工程） |
|
企业架构建模的视点机制及其示例（基于ArchiMate3.1） |
| 作者：俎涛 （火龙果软件工程） |
| |
| 1.
什么是视点 Viewpoint： |
| 人观察事物
，总是存在一个特定的起点和视角，这称之为视点（viewpoint）。从1个视点所确定的角度和形式对事物进行描述，就可以得到1个视图（view）。对于建模而言，有4个要素：
客体：要被建模的客观的事物，有人员、活动、系统、物品等。
观察者：对客观事物进行观察的人。
视点：建模者对建模的客体采用的观察的起点和观察的视角。
视图：基于视点的角度和形式所观察到的内容。
|
 |
| 企业架构建模语言ArchiMate中的视点 |
在进行企业架构建模的时候，架构师要描述许多不同类型的利益相关者及其关注。为了帮助企业架构师选择正确的建模内容，ArchiMate引入了一个视点定义和分类的框架：视点（Viewpoint）机制。
在企业架构语言ArchiMate中，视点机制用于定位利益相关者对架构的关注内容。理解了视点机制，有助于理解企业架构需要建立哪些模型。也有助于避免混淆一些基本概念：架构模型、架构视图、架构视点。如下是企业架构视点相关的元模型：
|
 |
|
说明如下： |
| 利益相关者（Stakeholder）关注架构；
架构的描述需要视点（Viewpoint ）和视图（View）；
架构视点（Viewpoint ）框定对架构关注的角度，视点约定可以包括语言、符号、模型种类、设计规则和建模方法、分析技术以及对视图的其他操作。一个架构可以有多个视点；
架构视点是专注于架构的特定方面和层次的一种方法。这些方面和层次取决于利益相关者的关注需求。因此，应该看到和不应该看到的东西完全取决于利益相关者关注了什么；
一个架构视点具有一个架构视图（注意是架构视点和架构视图是一对一的关系），架构视点控制架构视图的描述内容；
架构视点具有特定的模型图类型，架构视图具有多个模型图；
模型图类型决定了模型图的建模规范。 |
|
| ArchiMate的视点的分类 |
视点机制的框架基于两个维度：目的和内容。下图显示了如何使用视点机制来创建解决利益相关者关注点的视图。
|
 |
基于这个可复用的视点的基本结构，ArchiMate语言可帮助架构师选择与涉众关注的问题进行描述。
按照视点目的和内容对视点分类，可以得到如下视点类型： |
| 视点的维度 |
视点类型 |
| 目的维度 |
1. 设计： 从初始草图到详细设计的设计过程中，设计观点可为架构师和设计师提供支持。通常，设计视点由类似于UML中使用的图的图组成。
2. 决策：通过提供能够跨越多个架构关系的洞察能力，决策支持视点为管理者决策过程提供支持。通常的做法有预测和对依赖模型交集分析。具体的形式有交叉引用表、路线图、列表和报告。
3. 通知：通知视点 有助于向任何利益相关者告知企业架构，以达成了解，获得承诺并说服对手。典型的例子是插图、动画、卡通和宣传彩页等。 |
| 内容维度 |
1. 详细信息：详细级别的视图通常考虑ArchiMate
核心框架的一层和一个方面 。典型的利益相关者是负责设计和实现软件组件的软件工程师，或者是负责有效执行流程的流程所有者。
2. 一致性：在一致性抽象级别，跨多个层次或多个方。将视图扩展到一个以上的层或方面，使涉众可以将精力集中在架构关系上，例如过程使用系统（多层）或应用程序使用对象（多个方面）。典型的利益相关者是负责收集IT服务或业务流程的运营经理。
3. 概述：概述抽象级别同时涉及多个层次和多个方面。通常，此类概述面向企业架构师和决策者，例如CEO和CIO。
|
|
了解了存在哪些视点的类型，再看看如何根据涉众的关注内容使用视点。创建ArchiMate视点包括两个步骤：
1. 根据解决涉众所关注问题所需的信息，从ArchiMate元模型中选择相关元素和关系的子集。
2. 定义一种表示形式，以利益相关者理解的方式描述这些概念。这可以是使用ArchiMate标准或自定义表示法的图、元素目录、关系矩阵（显示两组元素之间的关系）。
将此观点应用于架构建模意味着选择了该视点的元素和关系（步骤1），并按照步骤2规定的方式进行描述。
借助于视点，架构师可以创建和设计视图。该视图包含ArchiMate元模型中的元素和关系（概念）。架构师可以为这些元素和关系设计并创建适当的表示形式。以下是常见涉众和他们的关注的示例，这些可以作为定义视点的基础。
|
| 利益相关者 |
关注什么 |
| 最终用户 |
对他们的工作和工作场所有什么后果？ |
| 架构师 |
在正确性，可预防性和适应性维护方面，对系统的可维护性有何影响？ |
| 高层管理者 |
如何确保在流程和系统的开发和运营中我们的政策被遵循？决策对人员，财务，ICT等有什么影响？ |
| 运营经理 |
关心使用和维护，例如，有什么新技术要准备？是否需要调整维护流程？更改现有应用程序会有什么影响？我的系统有多安全？ |
| 项目经理 |
关心新应用程序的开发，例如：这个项目涉及到哪些相关领域及其关系？业务流程对要构建的应用程序有什么依赖性？它们的预期表现如何？ |
| 开发人员 |
关心开发的内容，例如：在当前情况下需要做哪些修改？ |
|
在每个基本观点中，都可以使用业务，应用程序和技术三层中的概念。但是，并非所有这些组合都能给出有意义的结果。在某些情况下，建议使用不同层的单独视点。
不同的视点被分为几类，以指示关注哪个方向和哪些元素。视点常见的类别如下：
1. 构成类视点：在该视点中定义了元素 的内部构成和聚合关系。
2. 支持类视点：该视点里一些元素被其它一些元素支持，通常是下层元素支持上层元素。
3. 合作类视点：该视点通常包含在各个方面相互合作的对等元素，一般会跨越多个层面。
4. 实现类视点：该视点里的一些元素实现了另外一些元素，通常是下层元素实现上层元素。
如下是ArchiMate给出的基本视点，可以作为企业架构建模的参考。
|
| 视点类别 |
视点名称 |
视图形式 |
描述范围 |
| 组成 |
组织 |
按照角色、部门等组织形式描述企业结构 |
单层，单面 |
| 应用结构 |
按照组成部分的形式描述典型应用程序的结构。 |
单层，多方面 |
| 信息结构 |
描述企业中使用的信息的结构。 |
多层，单面 |
| 技术 |
按照网络、设备和系统软件的形式，描述企业信息系统基础的基础结构和平台。 |
单层，多方面 |
| 分层的 |
描述体系结构概览视图。 |
多层，多方面 |
| 物理 |
描述物理环境及其与IT基础架构的关系。 |
多层，多方面 |
| 支持 |
产品 |
描述产品的内容。 |
多层，多方面 |
| 应用用途 |
描述应用程序和这些应用程序在业务流程中的使用。 |
多层，多方面 |
| 技术运用 |
描述应用程序如何使用技术。 |
多层，多方面 |
| 合作 |
业务流程合作 |
描述各种业务流程之间的关系。 |
多层，多方面 |
| 应用合作 |
描述应用程序组件及其相互关系。 |
应用层，多方面 |
| 实现 |
服务实现 |
描述如何通过必要的行为实现服务。 |
多层，多方面 |
| 实施与部署 |
描述应用程序如何映射到基础技术。 |
多层，多方面 |
|
| 下面将列出ArchiMate的基本视点。这些基本观点是建模工作的起点。可以加快架构工作，支持组织标准，促进同行评审。但是，在实际的企业架构建模工作中不应该受限于这些基本视点。而是应该把基本视点作为参考，根据工作需要从中进行选择、修改或定义新观点来解决利益相关者的问题。 |
| 视点示例 |
| 说明：在一个企业架构过程中，动机视点
和需求实现视点是后续视点的基础，所以我把这2个视点也列入到视点示例。 |
| 动机视点 |
 |
| 视点概述 |
从利益相关者视角，对各种内部和外部的驱动因素进行评估，识别目标，然后把目标具体化为成果和相应的价值，而这些进一步推进到需求过程，需要进一步的进行目标细化、资源约束分析。 |
| 利益相关者 |
企业和ICT架构师，业务分析师，需求经理 |
| 关注内容 |
架构战略与策略，动机 |
| 建模目的 |
设计，决策，对外告知 |
| 建模范围 |
动机 |
| 相关的元素 |
1. Stakeholder
2. Driver
3. Assessment
4. Goal
5. Principle
6. Requirement
7. Constraint
8. Outcome
9. Value
10. Meaning |
|
| 如下是动机视点的元素说明 |
 |
 |
| 需求实现视点
|
 |
| 视点概述 |
需求实现观点 允许设计人员通过核心要素（例如业务参与者，业务服务，业务流程，应用程序服务，应用程序组件等）对需求的实现进行建模。通常，
采用聚合关系对需求 进行细化。 |
| 利益相关者 |
企业和ICT架构师，业务分析师，需求经理 |
| 关注内容 |
架构战略与策略，动机 |
| 建模目的 |
设计，决策，对外告知 |
| 建模范围 |
动机 |
| 相关的元素 |
1. Goal
2. Principle
3. Requirement/constraint
4. Outcome
5. Value
6. Meaning
7. Core element
8. Course of action
9. Resource
10. Capability
11. Value stream |
|
| 组织视点
|
| 视点概述 |
组织视点关注企业的内部组织。组织结构可以建模为嵌套关系图，也可以采用传统的组织结构图。组织视点对于确定组织中的能力，权限和责任非常有用。 |
| 利益相关者 |
企业架构师，流程架构师和领域架构师，经理，员工，股东 |
| 关注内容 |
识别能力，权限和责任 |
| 建模目的 |
设计，决策，告知 |
| 建模范围 |
单个层次/单个方面 |
| 相关的元素 |
1. Business
actor
2. Business role
3. Business collaboration
4. Location
5. Business interface |
|
| 如下是图例：
|
 |
| 组织视点常用元素如下： |
 |
| 业务流程合作视点 |
| 视点概述 |
用于显示一个或多个业务流程彼此之间或和其环境之间的关系。它既可以用来在其上下文中创建业务流程的高级设计，又可以让运营经理了解多个业务流程的依赖关系。主要描述的内容有：
企业主要业务流程之间的因果关系
将业务流程映射到业务功能
通过业务流程实现服务
使用共享数据
这些中的每一个都可以视为业务流程合作观点的“子视点”。
|
| 利益相关者 |
流程架构师和领域架构师，运营经理 |
| 关注内容 |
业务流程之间的依赖关系，一致性和完整性，职责 |
| 建模目的 |
设计、决策。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Business
actor
2. Business role
3. Business collaboration
4. Location
5. Business interface
6. Business process/function/interaction
7. Business event
8. Business service
9. Business object
10. Representation
11. Application component/collaboration
12. Application interface
13. Application process/function/interaction
14. Application event
15. Application service
16. Data object |
|
| 如下是图例： |
 |
| 产品视点 |
| 视点概述 |
产品视点描述了这些产品向客户或所涉及的其他外部方提供的价值。产品视点还描述了一种或多种产品的组成，这种构成包括业务、应用或技术服务以及相关的合同或协议。它也可以用来描述提供此产品的接口（或者渠道）以及与该产品相关的事件。产品视点通常用于产品开发，通过组合现有服务或确定需要创建哪些新服务来设计产品，目的是为客户提供期望的价值。产品视点可以作为业务流程设计师和其他需要设计流程和ICT实现这些产品的人员的输入。 |
| 利益相关者 |
产品开发人员，产品经理，流程架构师和领域架构师 |
| 关注内容 |
产品开发，企业产品提供的价值 |
| 建模目的 |
设计、决策。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Business
actor
2. Business role
3. Business collaboration
4. Business interface
5. Business process/function/interaction
6. Business event
7. Business service
8. Business object
9. Product
10. Contract
11. Application component/collaboration
12. Application interface
13. Application process/function/interaction
14. Application event
15. Application service
16. Data object
17. Technology service
18. Artifact
19. Material
20. Value |
|
| 如下是图例： |
 |
| 应用合作视点 |
| 视点概述 |
应用合作视点根据应用组件之间的信息流或它们提供和使用的服务来描述它们之间的关系。该视点通常用于创建一个组织的应用整体概览况。此视点还用于表示共同支持业务流程执行的服务的内部合作或编排。 |
| 利益相关者 |
企业架构师、流程架构师，应用架构师和领域架构师 |
| 关注内容 |
应用之间的关系和依赖性，服务的组合/编排，一致性和完整性，复杂性的降低。 |
| 建模目的 |
设计。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Location
2. Application component/collaboration
3. Application interface
4. Application process/function/interaction
5. Application event
6. Application service
7. Data object |
|
| 如下是图例： |
 |
| 应用使用视点 |
| 视点概述 |
应用使用视点 描述了如何使用应用来支持一个或多个业务流程以及其他应用如何使用它们。它可以用于设计一个应用（通过识别业务流程和其他应用所需的服务）,也可以被用于设计业务流程（通过描述可用的服务）。此外，由于它标识了业务流程对应用的依赖关系，所以对于负责这些流程的运营经理可能很有用。 |
| 利益相关者 |
企业架构师、流程架构师，应用架构师，运营经理 |
| 关注内容 |
一致性和完整性，复杂性的降低。 |
| 建模目的 |
设计，决策。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Business
actor
2. Business role
3. Business collaboration
4. Business process/function/interaction
5. Business event
6. Business object
7. Application component/collaboration
8. Application interface
9. Application process/function/interaction
10. Application event
11. Application service
12. Data object |
|
| 如下是图例： |
 |
| 实现和部署视点 |
| 视点概述 |
实施和部署视点
描述了如何在基础设施上实现一个或多个应用。这包括将应用和组件映射到工件上，以及将这些应用和组件使用的信息映射到基础存储设施上。 |
| 利益相关者 |
应用架构师和领域架构师 |
| 关注内容 |
应用平台的结构以及它们与支持技术的关系 |
| 建模目的 |
设计，决策。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Application
component/collaboration
2. Application interface
3. Application process/function/interaction
4. Application event
5. Application service
6. Data object
7. System software
8. Technology interface
9. Path
10. Technology process/function/interaction
11. Technology service
12. Artifact |
|
| 如下是图例： |
 |
| 技术视点 |
| 视点概述 |
技术视点 包含支持应用程序层的软件和硬件技术元素，例如物理设备、网络或系统软件（例如，操作系统、数据库和中间件）。 |
| 利益相关者 |
基础设施设计师，运营经理 |
| 关注内容 |
基础设施的稳定性、安全性、依赖性和成本 |
| 建模目的 |
设计。 |
| 建模范围 |
一个层次/多个方面 |
| 相关的元素 |
1. Location
2. Node
3. Technology collaboration
4. Device
5. System software
6. Technology interface
7. Communication network
8. Path
9. Technology process/function/interaction
10. Technology service
11. Technology event
12. Artifact |
|
| 如下是图例： |
 |
| 技术使用视点 |
| 视点概述 |
技术使用视点描述了软件和硬件技术如何支持应用：技术服务由设备提供，系统软件和网络被提供给应用。这个视点在性能和可伸缩性分析中起着重要作用，因为它可以将物理基础设施与应用的逻辑世界联系起来。在基于各种应用的需求确定基础设施的性能和质量需求方面，它也非常有用。 |
| 利益相关者 |
应用架构师，基础设施架构师，运营经理 |
| 关注内容 |
依赖关系，性能，可扩展性 |
| 建模目的 |
设计。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Application
component/collaboration
2. Application process/function/interaction
3. Application event
4. Data object
5. Node
6. Device
7. Technology collaboration
8. System software
9. Technology interface
10. Communication network
11. Path
12. Technology process/function/interaction
13. Technology service
14. Technology event
15. Artifact |
|
| 如下是图例： |
 |
| 信息结构视点 |
| 视点概述 |
信息结构的视点
基本等同于任何信息系统开发中创建的传统信息模型。它以数据类型或（面向对象的）类的结构的形式描述了企业、特定业务流程或应用中使用的信息的结构。此外，它可以描述业务层的信息在应用层以数据结构的方式如何表示，以及如何将它们映射到基础技术设施上；例如，通过数据库的模式。 |
| 利益相关者 |
领域架构师，信息架构师 |
| 关注内容 |
所用数据和信息的结构，这些数据结构的依赖性、一致性和完整性 |
| 建模目的 |
设计。 |
| 建模范围 |
多个层次/一个方面 |
| 相关的元素 |
1. Business
object
2. Representation
3. Data object
4. Artifact
5. Meaning |
|
| 如下是图例： |
 |
| 服务实现视点 |
| 视点概述 |
服务实现视点 用于描述下层的流程（也可能是应用组件）如何实现一个或多个业务服务。因此，它形成了业务产品视点和业务流程视图之间的桥梁。它提供了一个或多个业务流程的“外部视图”。 |
| 利益相关者 |
流程架构师、领域架构师、产品经理和运营经理 |
| 关注内容 |
业务流程的附加值，一致性、完整性和职责。 |
| 建模目的 |
设计，决策。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Business
actor
2. Business role
3. Business collaboration
4. Business interface
5. Business process/function/interaction
6. Business event
7. Business service
8. Business object
9. Representation
10. Application component/collaboration
11. Application interface
12. Application process/function/interaction
13. Application event
14. Application service
15. Data object |
|
| 如下是图例： |
 |
| 物理视点 |
| 视点概述 |
物理视点 包含可以创建、使用、存储、移动或运输物料的设备（一台或多台物理机器、工具或仪器），这些设备如何通过分布式网络连接，然后将活动元素分配给这些设备。 |
| 利益相关者 |
基础设施架构师，运营经理 |
| 关注内容 |
物理环境之间的关系和依赖性，以及它们与IT基础设施的关系。 |
| 建模目的 |
设计。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
1. Location
2. Node
3. Device
4. Equipment
5. Facility
6. Path
7. Communication network
8. Distribution network
9. Material |
|
| 如下是图例： |
 |
| 分层视点 |
| 视点概述 |
分层的视点 在一张图中描绘了企业架构的几个层次和方面。层有两类，即专用层
和服务层。这些层是使用“分组”关系对属于模型的整个对象和关系集进行自然划分的结果。技术、应用，过程和主角/角色层属于第一类。完全分层的视点背后的结构性原理是：每个专用层都通过“实现”关系公开一层服务，这些服务将进一步“服务”下一个专用层。因此，我们可以轻松地将专用层的内部结构和组织与其表示为专用层实现的服务层的外部可观察到的行为分开。这些图层的顺序、数量或性质不固定，但一般来说，ArchiMate模型的(或多或少)完整和自然的分层应该包含表26中给出的示例中所描述的层序列。然而，这个例子并不是绝对的。分层视角的主要目标是在一个图中提供整体概览。此外，这个视点可以用来支持变更分析和性能分析或者扩展服务组合。 |
| 利益相关者 |
企业架构师、流程架构师、应用架构师、基础设施架构师和领域架构师 |
| 关注内容 |
一致性、复杂性的降低、变更的影响和灵活性 |
| 建模目的 |
设计，决策，告知。 |
| 建模范围 |
多个层次/多个方面 |
| 相关的元素 |
所有核心元素和所有关系都是允许的。 |
|
| 如下是图例： |
 |
| 为了让大家理解方便，下面提供文中列出的视点的模型框架。 |
| 如下是模型框架的目录结构： |
 |
|
这个企业架构的基本视点模型框架有什么呢？ |
 |
| 各个视点包的内容说明如下： |
| 视点包 |
内容 |
| Motivation
Viewpoint |
动机视点 |
| Requirement
Realization Viewpoint |
需求实现视点 |
| Organization
Viewpoint |
组织结构视点 |
| Business
Process Cooperation Viewpoint |
业务过程合作视点 |
| Product
Viewpoint |
产品视点 |
| Application
Cooperation Viewpoint |
应用合作视点 |
| Application
Usage |
应用使用视点 |
| Implementation
and Deployment Viewpoint |
实现和部署视点 |
| Technology
Viewpoint |
技术视点 |
| Technology
Usage Viewpoint |
技术使用视点 |
| nformation
Structure Viewpoint |
信息结构视点 |
| Service
Realization Viewpoint |
服务实现视点 |
| Physical
Viewpoint |
物理视点 |
| Layered
Viewpoint |
分层视点 |
|
| 浏览：《模型框架：企业架构建模ArchiMate的视点》 模型库 |
| 如果希望进一步学习企业架构、TOGAF、ArchiMate，可以参考如下的课程或者工具。 |
| 如下是
课程：企业架构师认证课（业务、应用、技术）
课程：企业架构建模（archimate）
工具：企业架构建模工具EA
|
| 作者简介： |
|
俎涛，火龙果软件工程创始人，2001年创立了火龙果软件工程，2004年创立了IBM Rational用户组。1998年，曾作为骨干参与国家重点研究课题《面向特定领域基于组件的软件复用》，有幸比较深入的学习和使用的UML进行领域建模、提炼可复用组件和架构。在后来的研发项目中，一直采用模型进行分析设计，积累了一些心得和经验。20年来一直专注于MBSE，熟悉
UML、Sys ML、ArchiMate、BPMN、UPDM、DataModel等建模语言和规范，在以往的经历中，最大的感触是汇聚了很多精英人才的软件工程和系统工程领域居然几十年都是一种凌乱迷蒙的状态，从自己的经历所得，觉得清晰的模型，才是拨开工程迷雾的关键所在，所以不断研究和应用各种建模技术，并从自己的工程实践中提炼经验，形成对于自己可持续的方法论，例如《MBSE
从方法到实践指南》 《基于模型的三维研发管理》 《基于模型的需求管理》 《模型驱动的架构设计》
《基于模型的质量管理》 《基于模型的人员能力管理》 《iProcess过程改进方法》，目前正在作为产品经理和架构师，进行MBSE（基于模型的系统工程）平台的研发，希望建立要给基于模型的工程解决方案，后续会不断写些文章，希望能给同行一些借鉴。 |
|
如果您希望了解更多信息：
欢迎访问建模者频道 http://modeler.org.cn/
也欢迎直接联系我们 zhgx@uml.net.cn ，010-62670969
|
|
|
6034 次浏览  25 次
|
