ArchiSurance 案例研究是一个虚构示例，旨在说明 ArchiMate® 建模语言在 TOGAF® 框架内的应用。该案例研究涉及由三家此前独立公司合并而成的保险公司 ArchiSurance。案例研究描述了该公司的基线架构，随后是多个变更场景。

该案例研究是认证 ArchiMate 培训课程中的必选示例。然而，它并非官方 TOGAF 定义的一部分。该工作通过展示 TOGAF 与 ArchiMate 标准的联合使用，支持开放组关于无边界信息流的愿景，从而实现不同组织、系统和项目之间架构信息的一致性表达。

引言

该虚构案例研究展示了 ArchiMate 企业建模语言在 TOGAF 框架内的实际应用。该案例研究涉及保险公司 ArchiSurance，它是三家此前独立运营于不同大都市区的公司合并而成的结果。

该案例研究在认证 ArchiMate 培训课程中作为示例使用，并作为 ArchiMate 认证考试的背景材料。它从使用适当的 ArchiMate 或 TOGAF 视角的基线业务、应用、数据和技术架构开始。研究随后进入两个变更场景。第一个场景提供了展示 TOGAF 架构开发与实施周期的视图示例。它展示了架构愿景、业务目标、原则与需求、目标业务、应用、数据和技术架构、基线与目标之间的差距分析结果，以及支持实施与迁移规划的视图。在第二个场景中，第一个场景的目标状态被作为新的基线，客户可直接通过网络访问其保险组合。目前尚无该场景的模型可用。

开放组期望该案例研究随时间不断发展，并鼓励其成员添加新的方面和视图，或创建新的变更场景，只要它们与原始案例描述和模型保持一致即可。

TOGAF® 与 ArchiMate®

企业架构框架涵盖支持企业架构师的不同方面。此外，它们可能包含以下任何组合的要素：

• 创建架构的过程（“工作方式”）
• 视点的集合或分类
• 用于描述架构的语言（定义概念与关系，同时也包括符号表示）

开放组维护两项企业架构的开放标准：TOGAF [1] 和 ArchiMate [2]。

TOGAF 的核心是开发与实施企业架构的过程——架构开发方法（ADM）。TOGAF 还描述了视点、技术、参考模型以及用于识别构成架构的各类构建块的框架。然而，TOGAF 并未规定创建架构视图时必须使用特定的建模语言。

ArchiMate 是一种图形化语言，为模型提供统一的表示方式，以支持整个架构开发周期。该标准的 2.0 版本包含一个核心语言，用于描述实际架构（业务、信息系统和技术架构及其相互关系），以及用于建模架构动机、实施与迁移规划的扩展。图 1 描述了核心语言与扩展如何与 TOGAF ADM 相关联。除了定义建模概念与关系外，ArchiMate 与 TOGAF 一样，也定义了一组架构视点。

图 1：ArchiMate 与 TOGAF 的对应关系

TOGAF 与 ArchiMate 在哲学理念以及利用视点捕捉和传达单一底层架构模型的不同方面方面具有坚实共同基础。这两个标准相辅相成，因为 TOGAF 侧重于架构的开发与实施过程，而 ArchiMate 则侧重于使用统一语言来建模架构成果。

根据技术标准 [2] 所述，ArchiMate 语言通过提供一组与供应商无关的概念与关系，包括图形符号，来补充 TOGAF [1]，以帮助创建一致且集成的模型，并以视图形式呈现。

背景

ArchiSurance [3,4] 是最近三家此前独立的保险公司合并的结果：

• Home & Away，专注于房屋和旅行保险
• PRO-FIT，专注于汽车保险
• Legally Yours，专注于法律费用保险

该公司目前由三个部门组成，其名称和总部与各自的独立前身相同。

图 2：ArchiSurance：三家保险公司合并的结果

ArchiSurance 的成立旨在利用三家组织之间的多种协同效应。尽管三家合并前的公司销售不同类型的保险，但其商业模式相似。所有三种产品均通过网络、电子邮件、电话和邮政渠道直接面向消费者和中小企业销售。尽管总部位于不同城市，但每家公司均坐落于大都市区的现代化办公大楼内。每家公司都拥有忠实的客户群体，并以诚信、价值、服务和财务稳定而享有良好声誉。这三家公司均由机构投资者和个体投资者组成的集团私人持有。

三家公司的主要投资者在注意到低成本竞争对手进入其市场、高增长地区出现新机遇，以及每家公司为保持竞争力需要大量新的 IT 投资后，启动了合并谈判。他们意识到，只有规模更大的合并公司才能同时控制成本、维持客户满意度、投资新技术，并开拓具有高增长潜力的新兴市场。合并谈判和监管审批历时 18 个月，但文件已于两年前签署，合并已顺利完成。

新公司提供三家合并前公司的全部保险产品，并计划根据市场条件的变化频繁调整其产品组合。与它的三个前身一样，ArchiSurance 通过印刷品、网络和直接营销方式直接向客户销售。

合并给新公司的业务流程和信息系统带来了诸多整合与协调挑战。这些挑战在 ArchiSurance 的基线业务、应用、数据和技术架构中显而易见。但首先，TOGAF ADM 初期阶段确立了这些挑战的动机背景。

初期阶段

为了指导其未来的业务和IT变革，ArchiSurance决定基于TOGAF 9.1和ArchiMate 2.0开发企业架构，仅进行最少的定制。

作为初步阶段的一部分，识别了架构参与中的主要利益相关者及其关注点（在ArchiMate中建模为内部驱动力）。TOGAF定义了利益相关者映射矩阵来表示这一点。在ArchiMate中，这可以通过利益相关者视图来表达：

利益相关者视图使分析师能够建模利益相关者、他们的关注点以及对这些关注点的评估（从优势、劣势、机会和威胁的角度）。此外，可以将这些关注点和评估与初始（高层次）目标关联起来以解决它们。

图3展示了一个此类图表的片段，识别了两个利益相关者（架构委员会及其现有和潜在客户）及其关注点，并将其建模为驱动力。客户满意度是两个利益相关者共同关注的问题。利益相关者满意度可以进一步细化为更详细的关注点，例如利润。

图3：利益相关者视图片段

驱动力导致特定业务目标的形成，如下所示以实现利润。诸如降低成本的目标可以分解为降低维护成本和降低人员成本。

图4：驱动利润的业务目标

ArchiMate将原则定义为特定上下文中所有系统的规范性属性，或其实现方式。请注意，这里的“系统”不仅包括IT系统，还包括组织和组织单位。因此，原则有助于实现业务目标。TOGAF将原则定义为架构必须满足的意图性定性陈述。一个原则必须有支持性的理由和重要的影响。

ArchiMate原则视图（图5中展示了一个示例）以图形方式描述了原则、它们之间的依赖关系以及它们所实现的目标：

原则视图使分析师或设计师能够建模与当前设计问题相关的原则，包括驱动这些原则的目标。此外，可以对原则与目标之间的关系进行建模。例如，原则可能相互产生积极或消极的影响。

图5：原则视图

TOGAF定义了原则目录，以提供对原则的概览。

阶段B：基线业务架构

合并后，ArchiSurance建立了一个共享的前端办公室，作为销售和客户服务的多渠道联络中心，主联络中心位于原Home & Away总部。三个独立的后端办公室仍负责处理三家原始公司的保险产品。在原盈利总部设立了文档处理共享服务中心（SSC）。该中心管理中央文档库和所有自动化文档工作流程。此外，当具有法律效力的文件进入或离开ArchiSurance时，该中心还负责所有扫描、打印和归档操作。为确保业务连续性并应对高峰期活动，SSC还配备了经过培训的人员和设备，以执行前端职能，前端办公室也做了相应的准备。

图6：ArchiSurance的全球组织结构

在TOGAF ADM的阶段B（业务架构）中，ArchiMate可以表达并关联ArchiSurance的组织结构、产品、服务、职能、流程和信息。业务架构为数据、应用和技术架构提供了上下文。

组织结构

为了描述组织结构，ArchiMate定义了组织视图：

组织视图关注公司、部门、业务网络或其他组织实体的（内部）组织结构。在此视图中，模型可以表示为嵌套的框图，也可以使用更传统的表示方式，如组织结构图。组织视图对于识别组织内的能力、权限和责任非常有用。

TOGAF中与此视图相对应的是组织分解图。

组织结构通常以树状图表示，如图7所示，尽管ArchiMate和TOGAF中使用的组织分解方法比简单的树状组织图提供了更多选项。此视图展示了ArchiSurance的高层组织结构，以及其主要地点和部门。或者，也可以使用嵌套图按地点和部门对组织进行细分。

图7：组织视图

业务职能

ArchiMate业务职能根据选定的一组标准（通常是所需业务资源和/或能力）对行为进行分组。

ArchiSurance区分的主要业务职能包括：

• 市场营销——产品和细分市场的研究、规划、推广与管理，以及与精算师合作设计产品
• 精算——确定产品价格和准备金水平，与市场营销合作设计新产品，并分析企业风险
• 客户关系——ArchiSurance与其客户之间的互动；处理客户问题，记录收到的索赔，并开展直接营销活动
• 承保——为单个保单设定价格，并生成保险提案和保单
• 理赔——制定并执行ArchiSurance对每项针对其保单提出的索赔的回应
• 财务——根据合同定期从客户处收取保费，并处理保险理赔付款
• 文档处理——通过文档扫描、打印和归档来支持其他职能
• 投资管理——在企业及监管的流动性与风险约束下，管理金融和房地产资产以实现最大回报

这些业务职能中的一些在ArchiSurance三个部门的后台部门中被复制

为了对业务职能及其关系进行建模，ArchiMate定义了业务职能视图：

业务职能视图展示了组织的主要业务职能及其在信息流、价值流或物流方面的相互关系

该视图在TOGAF中的对应物是功能分解图

图8展示了ArchiSurance的主要业务职能，以及职能与外部角色之间的最重要信息流。它还展示了各分部后台部门中业务职能的复制情况

图8：业务职能视图

业务流程

ArchiMate中的业务流程根据活动的顺序对行为进行分组，产生一组明确的产品或服务。流程架构展示了最重要的业务流程及其关系，可能还包括每个流程的主要步骤。通常不会展示流程的所有细节——这正是业务流程建模语言的目的。ArchiMate定义了业务流程视图：

业务流程视图用于展示一个或多个业务流程（或其部分）的高层结构和组成

该视图在TOGAF中的对应物是流程图

图9展示了ArchiSurance的两个核心业务流程及其高层子流程：签订合同（在销售新保险产品时执行）和处理理赔（在收到损害理赔时执行）。尽管这些流程的细节可能因不同类型的保险产品而异，但主要步骤是相同的

图9：业务流程视图

阶段C：基准信息系统架构（应用）

自合并以来，三个部门已采用统一的门户、客户中心软件套件和文档管理系统。此外，公司选定了一项战略性CRM解决方案，并在Home & Away和PRO-FIT中实施。然而，由于管理层专注于在持续提升各分部日常绩效的同时最小化合并后的风险，核心业务应用的整合尚未开始。如今ArchiSurance已达到合并后的绩效预期，投资者期望通过采用统一的产品集和以客户为中心的应用程序实现显著的IT成本节约。挑战依然存在：Home & Away仍使用合并前的保单管理与财务应用套件，而PRO-FIT和Legally Yours仍使用其各自的合并前定制应用

图10：应用环境

应用协作

ArchiMate定义了应用协作视图，以提供应用环境及应用间依赖关系的概览：

应用协作视图描述了应用组件之间的关系，即它们之间的信息流，或所提供的服务与所使用的服务。该视图通常用于创建组织应用环境的概览。该视图也用于表达（内部）服务之间的协作或编排，这些服务共同支持业务流程的执行

该视图在TOGAF中的对应物是应用通信图

图11展示了ArchiSurance的主要应用及其之间的主要数据流

图11：应用协作视图

业务-应用对齐

TOGAF并未为业务-应用对齐定义图表。然而，它确实指定了基于矩阵的视图来展示业务与应用架构之间的关联；例如，应用/组织矩阵和应用/职能矩阵

应用组件之间的关系也可以通过图形方式进行建模。ArchiMate定义了应用使用视图：

应用使用视图描述了应用如何用于支持一个或多个业务流程，以及它们如何被其他应用使用。它可用于通过识别业务流程和其他应用所需的服务来设计应用，或通过描述可用服务来设计业务流程。此外，由于它明确了业务流程对应用的依赖关系，因此对负责这些流程的运营管理人员非常有用

应用服务概念在此视图中起着核心作用。图12展示了ArchiSurance Home & Away部门所使用应用提供的部分服务，以及理赔处理流程中的哪些子流程使用了这些服务

图12：应用使用视图

阶段C：基线信息系统架构（数据）

ArchiSurance的数据架构描述了其概念性业务对象与逻辑数据对象之间的主要关系。ArchiMate为此定义了信息结构视图：

信息结构视图与几乎任何信息系统开发过程中创建的传统信息模型类似。它以数据类型或（面向对象）类结构的形式展示企业、特定业务流程或应用程序中所使用信息的结构。

TOGAF定义的数据视图之一是逻辑数据图。

图13展示了ArchiSurance定义的部分业务对象。客户信息的一部分是保险档案，包括保险申请、保险保单和事故索赔。为ArchiSurance销售的每种保险类型都定义了保险保单对象的多个特化版本。

图13：信息结构视图

TOGAF定义的另一个数据视图是数据分发图：

数据分发图的目的是展示数据实体、业务服务和应用组件之间的关系。该图展示了应用组件如何物理实现逻辑实体。这有助于有效规划和优化IT基础设施规模。此外，通过为数据分配业务价值，可以判断应用组件的业务关键性。

图14展示了ArchiSurance某个应用的数据分发图。

图14：数据分发图

阶段D：基线技术架构

图15概述了ArchiSurance的技术基础设施布局。在位于Home & Away总部的前台，有一台通用服务器和一台专门用于网页托管的服务器。位于PRO-FIT总部的共享服务中心（SSC）拥有自己的文件管理系统服务器。三个后台办公室中的每一个都有一台用于其应用的服务器。

局域网（LAN）连接了ArchiSurance三个地点的服务器和个人计算机，这些地点又通过企业广域网（WAN）相互连接。

图15：基础设施布局

为了全面了解基础设施布局，ArchiMate定义了基础设施视图：

基础设施视图包括支持应用层的软硬件基础设施元素，如物理设备、网络或系统软件（例如操作系统、数据库和中间件）。

TOGAF中与此视图相对应的是环境与位置图。

图16展示了ArchiSurance的主要基础设施组件按位置和部门分组的情况。该视图还展示了连接不同设备的网络以及部署在设备上的（应用）构件。

图16：基础设施视图

变更情景

情景1：应用组合合理化

ArchiSurance应用架构的僵化使其难以适应不断变化的业务环境。部分原因在于并购，应用环境变得支离破碎，导致数据冗余和功能重叠，以及使用多种数据格式和方法进行点对点的应用集成。这些问题导致内部不稳定、应用维护成本上升，并阻碍公司内部及与合作伙伴之间的信息共享。结果，IT部门积压了大量工作请求。ArchiSurance高层管理人员对此积压问题非常担忧，尤其是无法自动与大量签约销售合作伙伴及有影响力的保险顾问共享信息。

本情景通过以下方式对ArchiSurance的应用组合进行合理化：

• 迁移到一个集成的后台套件，该套件可执行保单管理、财务交易等功能。该套件将包括：
  • 一个自动生成提案和保单的自动化承保系统——AUTO-U
  • 一个与自动化承保系统集成的成套保单管理系，用于签发、修改和续保；该系统还负责客户账务和计费——P-ADMIN
  • 一个成套理赔系统，其界面和工作流可配置以支持ArchiSurance的三大业务线——VERSA-CLAIM
  • 一个产品配置管理器，用于定义所有保险产品，并通过Web服务将这些定义暴露给AUTO-U、P-ADMIN和VERSA-CLAIM——P-CONFIG
  • 一个业务规则管理系统（BRMS），包括规则仓库、处理引擎、规则开发环境以及规则管理用户界面的编写工具。业务规则引擎通过Web服务向AUTO-U、P-ADMIN、VERSA-CLAIM和P-CONFIG暴露规则执行功能——EDGE
• 完成向战略型客户关系管理系统（CRM）的迁移

ArchiSurance的主要投资者和首席执行官支持这些计划，前提是ArchiSurance的客户和合作伙伴不会看到任何变化。保险公司产品和服务不得受到影响，所有客户和合作伙伴的互动必须不间断地进行。

图17：应用组合优化

作为此项工作的组成部分，技术基础设施也将得到简化。位于Home & Away总部数据中心的共享服务器集群将取代独立的后台服务器。然而，为确保业务连续性，PRO-FIT总部数据中心也将安装一个备用服务器集群。

阶段A：架构愿景

TOGAF ADM的阶段A通过设定范围、约束和目标来确立架构工作，并启动架构开发周期的迭代。本阶段还验证业务背景，并制定架构工作说明。

业务背景由基于主要业务目标和架构原则的关键业务需求组成。图18展示了当前情景下的一些相关业务目标和原则。

图18：业务目标与原则

目标和原则构成了具体需求的基础，如ArchiMate目标细化视图所示：

目标细化视图允许设计者将（高层次）目标细化为更具体的目标，并将具体目标进一步细化为描述实现目标所需属性的需求或约束。聚合关系用于将目标细化为子目标；实现关系用于将目标细化为需求。

图19展示了当前变更情景下该视图的一个示例。

图19：目标细化视图

架构愿景的一个重要组成部分是基线架构和目标架构的高层次表示，以向利益相关者解释架构工作的附加价值。为此，ArchiMate定义了入门视图：

入门视图使用一种简化的符号体系，是完整ArchiMate语言的一个子集。它通常用于设计轨迹的初期阶段，当尚不需要详细说明时，或用于向非架构师解释架构模型的本质，以提供更简单、更直观的符号。该基础且非正式视图的另一个用途是避免给人留下架构设计已经确定的印象——当使用更正式、高度结构化或详细的可视化时，这种印象很容易产生。

TOGAF中与此视图相对应的是解决方案概念图。

下面的示例突出了当前变更情景中所需进行的最重要变更：

• 在前台，独立的法律费用CRM系统将被取消。
• 在后台，独立的后台应用程序将被一个统一的后台套件取代。三个独立的通用后台服务器将被一个共享服务器集群和一个备用服务器集群取代。

图20：入门视图

阶段B：目标业务架构与差距分析

在此情景中，业务架构保持不变。然而，在业务架构中，我们还展示了目标架构如何实现关键业务需求。为此，TOGAF规定了业务足迹图。在ArchiMate中，这可以通过需求实现视图来表达，定义如下：

需求实现视图允许设计者通过核心元素（如业务参与者、业务服务、业务流程、应用服务、应用组件等）来建模需求的实现。通常，需求源自目标细化视图。

下面的示例展示了在架构愿景阶段确立的业务需求如何通过架构中的元素得以实现。

图21：需求实现视图

阶段C：目标应用架构与差距分析

下面的应用通信图展示了应用架构的预期目标状态。

图22：目标应用架构：应用协作视图

应用架构的全局差距分析结果如下所示。基线架构中存在的多个应用组件在目标架构中不再存在：独立的后台应用程序以及独立的法律费用保险CRM系统。法律费用保险客户的CRM功能将由通用CRM系统接管，因此无需新增组件（尽管现有的通用CRM系统可能需要调整或重新配置，但这些内容未在差距分析中体现）。此外，还将引入一个全新的后台应用套件。

图23：应用架构：差距分析

阶段D：目标技术架构与差距分析

下面的基础设施视图展示了技术基础设施领域的预期目标状态。

图24：目标技术架构：基础设施视图

图25展示了技术架构的全局差距分析结果。独立的通用后台服务器将被移除。Home & Away原有的服务器集群将转变为中央ArchiSurance后台服务集群，并在PRO-FIT总部的SSC增设一个额外的备份服务器集群。Home & Away后台还配备有一台备份文档管理服务器。新的后台套件和文档管理系统将在各自的主服务器和备份服务器上进行复制。

图25：技术架构：差距分析

实施与迁移规划

TOGAF 9为E阶段和F阶段引入了过渡架构，用以表示基线架构与目标架构之间的可能中间状态（“平台”）。

在ArchiMate中，基线架构、目标架构和过渡架构及其相互关系通过迁移视图来展示：

迁移视图包含可用于描述从现有架构过渡到期望架构的模型和概念。

图26展示了当前场景的一个示例。ArchiSurance IT部门资源不足，无法并行执行后台系统集成和CRM系统集成。因此，一种过渡架构将两个CRM系统替换为一个，但保留独立的后台系统；另一种则采用后台套件，但保留两个CRM应用。

图26：迁移视图

过渡架构支持实施项目（如CRM集成和后台应用集成）的规划。这些项目的顺序取决于所选择的过渡架构。这可以在TOGAF项目上下文图（图27）中展示：

项目上下文图展示了作为更广泛转型路线图一部分的待实现工作包的范围。项目上下文关系图将工作包与将被添加、移除或受影响的组织、职能、服务、流程、应用、数据和技术联系起来。

图27：在ArchiMate中表示的TOGAF项目上下文图

场景2：在线投资组合管理

在此场景中，假设场景1的目标状态作为新的基线，客户可通过网络直接访问其保险投资组合。通过使客户能够：

• 根据ArchiSurance在业务运营中使用的规则，安全地在线购买、续保或修改房屋、旅行、汽车或法律费用保险
• 通过以下方式获取在线交易帮助：
  • 在知识库中搜索答案
  • 启动与客户服务中心代表（CSR）的聊天会话
  • 使用网页表单撰写并提交电子邮件，由CSR回复
  • 使用网页表单请求CSR来电
• 从ArchiSurance合作伙伴获取信息和特别优惠，以满足其需求，例如银行与财务规划服务、投资、信用卡及其他类型的保险

目前此场景尚无可用模型。The Open Group鼓励其成员为本案例研究的未来版本做出贡献。贡献者可以扩展或补充此处介绍的两个场景，或创建新场景。然而，为确保工作成果的一致性，新变更场景的基线架构应为此处介绍的变更场景的基线或目标。

参考文献

1. TOGAF® 版本 9.1，The Open Group，由The Open Group出版，2011年。
2. ArchiMate® 2.0 规范，The Open Group，2012年1月。
3. Doest, H., Iacob, M.-E., Lankhorst, M.M.（主编），van Leeuwen, D.：视图功能与示例，ArchiMate交付物 D3.4.1a v2，TI/RS/2003/091，Telematica Instituut，荷兰恩斯赫德，2004年。
4. van den Berg, H., Moelaert, F.：PRO-FIT汽车事故开放测试平台，测试平台交付物 WP3/N004/V001，TRC，荷兰恩斯赫德，1997年。
5. 什么是ArchiMate？
6. 完整的ArchiMate视角指南
7. ArchiMate 3 更新
8. ArchiMate 3 的新功能
9. 使用ArchiMate工具与TOGAF ADM
10. 如何在ArchiMate 3.1中使用价值流？
11. ArchiMate 3.1 的新功能