ArchiSurance Case Study v3.1 读书笔记

概述

本笔记的目的是通过一个虚拟案例了解TOGAF做企业架构的简明过程。我读的是英文版PDF，从这里下载。

文中的💡后的文字是我的注释。

直到笔记写完，我才发现：

• 此Case Study的最新版本为v3.2
• 而且还提供中文版

不过以上都没有影响，翻译是次要的，重要的是阅读过程中的理解，以及学会查阅文档以解决问题。如了解原始定义，图标含义，扩展阅读等。

Executive Summary

ArchiSurance 案例研究是一个虚构示例，旨在演示在 TOGAF® 框架体系下 ArchiMate® 建模语言的使用方法。该案例以保险公司 ArchiSurance 为对象，这家公司由三家原本相互独立的企业合并组建而成。案例描述了该企业的基线架构，继而介绍了若干变更场景。

Introduction

本虚构案例研究展示了 ArchiMate 企业建模语言在 TOGAF 框架下的实际应用。案例主体为保险公司 ArchiSurance，该公司由三家原先独立、总部位于不同大都市圈的企业合并而成。

本案例研究借助对应的 ArchiMate 或 TOGAF 视图，展示基线与目标业务架构、应用架构、数据架构和技术架构。案例包含两个变更场景：架构合理化（Rationalization）与数字化转型（Digital Transformation）。

💡 架构合理化包括精简、整合、去冗余，合并系统与业务流程。

The ArchiMate and TOGAF Standards

企业架构框架涵盖架构实践的不同方面。它们可能包含以下元素的任意组合：

• 创建架构的方法
• 观点的集合或分类
• 描述架构的语言，包括语言元素定义和符号

开放组（The Open Group）维护两项企业架构开放标准：TOGAF 框架 与 ArchiMate 建模语言。TOGAF 框架的核心是一套企业架构开发与实施方法，即架构开发方法（ADM）。TOGAF 框架同时描述了视图、技术、参考模型，以及内容框架；该内容框架定义了构成架构的各类构建块。但 TOGAF 框架并不规定必须使用某一种特定建模语言来绘制架构视图。

ArchiMate 语言是一套图形化标记符号，为模型提供统一表达形式，可支撑完整的架构开发周期。《ArchiMate 规范》包含核心语言，用于描述业务架构、信息系统架构、IT 架构与物理技术架构，以及它们之间的相互关系。该规范还提供相应元素，用于对业务与技术战略、驱动架构开发的动因，以及架构实施和迁移计划进行建模。

💡 TOGAF 是方法论与流程框架，本身不绑定绘图语言；ArchiMate 是图形化建模符号，用来给 TOGAF 产出的架构做标准化绘图建模。

图 1 简要展示了核心语言与扩展元素如何支撑 TOGAF 架构开发方法（ADM）。此外，ArchiMate 语言包含用于对企业物理要素建模的元素，例如设施与设备，而这部分内容在 TOGAF 框架中并未涉及。本案例研究将物理要素视作 ArchiSurance 技术架构的组成部分，并选用取自 ArchiMate 语言与 TOGAF 框架二者的视图来开展建模。

ArchiMate 与 TOGAF 两项标准在核心理念以及利用视图捕获、传递同一底层架构模型不同维度信息方面，具备坚实的共同基础。两项标准互为补充：TOGAF 标准侧重架构开发与落地实施的方法论，而 ArchiMate 语言侧重用于架构建模的统一标记符号。

ArchiMate 语言 是 TOGAF 框架 的补充：它提供一套与厂商无关的概念与关系集合，其中包含图形化表达，便于构建一致且一体化的模型，并可通过视图形式呈现。ArchiMate 语言自身定义了示例视图，作为各类视图的模板；同时该语言也可用于绘制 TOGAF 架构内容框架中所规定的各类图。

图1：ArchiMate 语言与 TOGAF ADM 的大致对应关系

Background

ArchiSurance 是由三家原本独立的保险公司合并而成的：

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

现在公司由三大部门组成，名称和总部沿用了它们各自独立时的名字和位置。

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

ArchiSurance 公司成立的目的，是充分利用这三家机构之间大量的协同效应。合并前，这三家企业销售不同类型的保险产品，但商业模式相近。三家公司均通过网络、电子邮件、电话和邮寄渠道，直接面向个人消费者与企业客户开展销售。尽管总部位于不同城市，但每家企业都坐落于大都市的现代化综合办公园区内。三家企业都拥有忠实的客户群体，并在诚信、性价比、服务品质与财务稳健方面享有良好口碑。这三家公司均由相互关联的机构投资者与个人投资者组成的集团私有控股。

三家公司的主要投资方发现低成本竞争者正涌入市场、高增长地区出现新机会，并且每家公司都需要大量新增 IT 投入才能保持竞争力后，便启动了并购谈判。他们认识到，只有合并组建规模更大的公司，才能同时管控成本、维持客户满意度、投入新技术，并把握住高增长潜力的新兴市场。并购谈判与监管审批耗时 18 个月，两年前各方签署相关文件，并购正式落地。

新公司保留合并前三家企业的全部保险产品，并计划根据市场环境变化，动态调整产品供给。和三家前身公司一样，ArchiSurance（阿基保险）通过网站、电子邮件、电话、邮政邮件渠道直接向客户销售，同时也通过中介机构开展间接销售。

Rationalization

ArchiSurance 的应用架构缺乏灵活性，难以适应业务环境的变化。部分由于本次并购，应用系统格局变得零散，造成数据冗余、功能重复，并且采用多种数据格式与实现方式进行点对点应用集成。上述问题引发系统内部不稳定、应用维护成本上升，企业内部以及和外部合作伙伴之间的信息共享困难。由此，IT 部门积压了大量待处理工作需求。ArchiSurance 高层管理者对此积压问题高度关注，尤其是一项尚未满足的需求：需要和业务量大的签约销售合作伙伴、有影响力的保险顾问实现信息自动共享。

💡 注意以上架构常见问题和后果。

ArchiSurance 的主要投资方与首席执行官支持上述各项举措，但前提是：所有改造对 ArchiSurance 的客户与合作伙伴透明无感知。保险公司的产品和服务不得受到任何影响，客户及合作伙伴的全部业务交互必须持续开展，不能中断、不能变更。

作为这项工作的一部分，技术基础设施也将进行简化。相互独立的后台服务器将由部署在 Home & Away 总部数据中心的共享服务器集群替代。同时，为保障业务连续性，在 PRO-FIT 总部的数据中心还将部署一套备份服务器集群。

Digital Transformation

除并购后整合这类短期目标之外，ArchiSurance 同时将技术的快速迭代视作挑战，也视为机遇。公司计划启动数字化转型，并制定了全新的数字化客户亲和战略，该战略结合大数据与物联网（IoT）技术落地。ArchiSurance 旨在获取更细粒度的客户数据，以此优化客户交互、提升客户满意度，并依据风险水平调整保险保费。

💡 此处数字化客户亲和原文为Digital Customer Intimacy。

为此，面向个人消费者的保险产品，ArchiSurance 计划采集智能联网设备的数据，例如运动手环、车辆追踪系统或家庭自动化网关。在各类 B2B 市场中，ArchiSurance 将采用车队管理系统、能源网络、店内 RFID 设备、智能楼宇传感器等数据源。最终有望推出实时保险产品：客户可以直接获知自身行为带来的财务影响，并获得行为调整建议，从而降低保费。

💡 此处的车队管理系统原文为Fleet Management System。

Fleet Management System (FMS)：一套软硬件一体化系统，企业用来对自有营运车辆资产进行集中管控，包含车辆定位、行驶轨迹、驾驶行为监测、里程油耗、维保计划、事故数据采集等功能，采集车辆运行数据。

💡 此处车队是指客户的车队，很多公司拥有营运车队（物流货车、企业商务车、网约车车队等），需要车队团体车险，一次性给全部车辆投保。车队管理系统会采集：车辆位置、行驶里程、车速、急刹、超速、驾驶行为、发动机故障等数据。保险公司拿到这些数据，可以评估驾驶风险、动态定价和提供出险辅助。

后续章节将介绍 ArchiSurance 如何应对架构合理化与数字化转型两类变革场景。

Phase A: Architecture Vision

为指导业务与信息技术后续变革，ArchiSurance 决定基于 ArchiMate 3.1 与 TOGAF 9.2 标准搭建企业架构。

作为架构开发方法 A 阶段的一项工作，需要识别本次架构项目中的主要干系人及其关注点（在 ArchiMate 语言中建模为内部驱动因素）。TOGAF 标准定义了干系人映射矩阵用于呈现该内容；在 ArchiMate 建模语言中，则可通过干系人视图来表达。

💡干系人原文为stakeholder，也可译为利益相关者。

干系人视图支持架构分析人员对干系人、干系人关注点，以及针对这些关注点开展的评估（即优势、劣势、机会与威胁 SWOT 评估）进行建模。同时，还可以描述与初步高层目标之间的关联关系，这些高层目标用于应对上述关注点与评估结论。

图 3 展示了该图的一部分，识别出两名干系人（ArchiSurance 董事会，以及现有和潜在客户），并将他们的关注点建模为驱动因素。客户满意度是这两类干系人共同关注的要点。干系人满意度可进一步拆解为更细化的关注点，例如盈利性。

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

驱动因素催生具体业务目标，图 4 以盈利性为例展示该关系。两项评估显示，ArchiSurance 的盈利能力正受到影响，因为客户正在流向数字体验更好或保费更低的竞争对手。ArchiSurance 计划在下一财年将利润率提升 5%。成本降低这类目标会对该成果产生正向影响。而成本降低目标又可以进一步拆分为维护成本降低与人力成本降低两个子目标。

图 4：与驱动因素【盈利性】相关的业务目标、评估项及预期成果

💡 在这里的Table 4. Motivation Elements可部分以找到以上各类图标的定义。其中：

• 方向盘表示驱动力（driver)
• 横放的圆柱表示干系人（stakeholder）
• 放大镜表示评估项（assessment）
• 箭靶表示目标（goal）
• 箭靶带一支箭表示最终结果/产出（outcome）

💡 goal是主观意图，outcome已达成的或期望达成的结果。

ArchiSurance 基于业务目标制定一组原则，用于指导架构开发。ArchiMate 语言将**原则（Principle）**定义为：架构必须满足的、已落地的定性意图陈述。请注意，此处所指的系统包含组织、组织单元等对象，并不仅仅是 IT 系统。因此，原则助力实现业务目标。

TOGAF 标准同样把原则定义为架构应当满足的定性意图陈述。TOGAF 原则至少需要配套支撑理由与重要程度评估。

图 5 为 ArchiMate原则视图示例，该视图用于描述各项原则、原则之间的依赖关系，以及这些原则所支撑实现的目标。

原则视图可供架构分析人员或设计人员，对当前设计问题相关的各项原则进行建模，其中包含驱动这些原则产生的目标。此外，还可对原则之间、原则与目标之间的关系建模。例如，原则相互之间可能存在正向或负向影响。

TOGAF 标准定义了原则目录，用于提供原则的总览视图。

图5：原则视图（片段）

💡 很显然，方框中的感叹号表示原则（principle）
💡 在这里可以找到 principle catalog。值得好好过一遍。

这里提供一个很好的关于principle的总结。

目标与原则是具体需求的基础，如目标细化视点（Goal Refinement viewpoint）所示。

目标细化视点支持架构设计人员对目标的分解过程建模：将高层目标细化为更具体的目标，再将具体目标细化为需求或约束；这些需求与约束描述了实现目标所需具备的各项特性。
目标分解为子目标，使用聚合关系建模；目标推导为需求，则使用实现关系建模。

图 6 展示了合理化变更场景对应的该类视图示例。

图 6：合理化策略目标细化视图

💡 平行四边形表示需求（requirement），平行四边形内加一条和左侧边平行的线表示约束（constraint）。

Longer-Term Vision

除短期架构精简整合需求外，ArchiSurance 还制定了长期的数字化客户亲战略，该战略融合大数据与物联网技术。ArchiSurance 计划利用更精细的客户数据，改善客户交互体验、提升客户满意度，并基于客户行为洞察定制保险保费。公司将通过智能联网设备采集此类数据，例如个人运动手环、车载黑匣子、家庭自动化网关、车队管理系统、门店 RFID 设备或智能楼宇传感器。

战略视点可供业务架构师对企业已选定或正在考量的行动方案、支撑方案的能力与资源、预期成果，以及上述内容如何支撑组织目标与内外部驱动因素进行概览建模。

图 7：数字化客户亲密战略视图

💡 黄色方框里的两个图标属于战略层面的元素，其中类似积木的是能力（capability），箭头加箭靶表示行动方案（course of action）。

当然，这项新战略最终也应当服务于组织的核心驱动因素，部分驱动因素如图 3 所示。战略、能力、预期成果以及相关方驱动因素之间的关系如图 7 呈现。数字化客户亲密战略要求 ArchiSurance 建设多项全新能力与资源，包括数字化客户管理、数据采集以及数据分析。

Solution Concept

架构愿景的一项核心内容，是对目标架构进行高层描述，阐明该架构如何满足企业需求，向相关干系人说明架构工作带来的附加价值。为此，可以采用 ArchiMate 语言绘制 TOGAF 解决方案概念图。
图 8 展示了目标架构的核心要点，呈现由业务合理化战略与数字化客户亲密度战略共同导出的各项需求与成果：

• 在前台部署企业级客户关系管理（CRM）自动化体系，取代各独立 CRM 系统；
• 一体化后台办公自动化系统，替换各业务线相互独立的后台应用；
• “客户行为深度洞察” 这一业务成果，将通过从外部数据源采集客户行为数据来支撑；数据送入自动化数据分析方案，再由该方案向新建后台系统输出客户画像。
  依托上述体系获得的商业智能，将作为理赔管理能力的一部分，用于为客户单独厘定保险费率，并支撑新保险产品的研发。这同时还要求企业构建数据分析方面的组织能力。
• 各类社交媒体应用，结合企业所需具备的社交媒体能力，将实现预期的优质线上客户交互。

图8：解决方案概念视图

💡 电池图标表示资源（resource)

Phase B: Business Architecture

合并完成后，ArchiSurance 搭建了共享前台，作为支持销售与客户服务的多渠道联络中心，主联络中心设在合并前 Home & Away 公司的总部。但仍保留三套独立后台，分别处理原三家公司的保险产品业务。
在 PRO-FIT 公司（就是卖汽车保险那家）合并前的总部设立了共享服务中心（SSC），负责文档处理。该中心管理中央文档库以及全部自动化文档工作流。此外，所有具有法律效力的文档在流入、流出 ArchiSurance 时，均由该中心完成扫描、打印与归档工作。为保障业务连续性并应对业务高峰期，共享服务中心配备了受过培训的人员与设备，可承接前台的业务职能；前台同样做好准备，可反向支援共享服务中心。

在 TOGAF 架构开发方法（ADM）的 B 阶段（业务架构），可使用 ArchiMate 语言描述 ArchiSurance 的组织结构、产品、服务、职能、流程与信息，并建立它们之间的关联关系。业务架构为数据架构、应用架构和技术架构提供业务上下文。

Organization Structure

为描述组织结构，ArchiMate 语言定义了组织视图。

组织视图聚焦于企业、部门、企业联盟网络或其他组织实体的组织架构。该视图下的模型既可以采用嵌套框图展示，也可使用组织结构图这类更为传统的形式。组织视图非常适用于识别组织内的能力、权限与职责。

在 TOGAF 中与之对应的是组织分解图。

组织结构通常以树形结构呈现（如图 9 所示），不过 ArchiMate 与 TOGAF 标准所采用的组织分解方法，可选表达形式远不止简单的树形组织结构图。该视图展示了 ArchiSurance 的高层组织结构，包含其主要办公地点与部门。此外，也可以使用嵌套框图来描述组织内各部门的细分结构（见图 10）。

图9：组织视图

图10：组织分解（嵌套）

💡 小人图标表示业务参与者（business actor）。业务参与者既可以是特定个人或组织（例如 “约翰・史密斯” 或 “ABC 公司”），也可以是泛指的角色（例如 “客户” 或 “供应商”）。

Value Stream

为从战略层面描述 ArchiSurance 如何为客户创造价值，该企业使用价值流进行表达。图 11 展示了获取保险产品这条核心高层价值流（采用价值流专用图标符号），呈现价值生成的各个阶段、每个阶段的价值贡献，以及最终交付给客户的成果。

价值流视图可供业务架构师构建价值流的结构化总览，涵盖价值流各阶段所依托的能力、所创造的价值以及相关干系人。

图11：价值流

Capabilities

ArchiSurance 需要对多项能力进行优化或调整，以落地其设想的战略与运营变革。为此，该企业参考保险业 Panorama360 参考模型，搭建了能力地图，从而清晰掌握自身现有能力，如图 12 所示。

💡 Panorama360 参考模型的原始网页已失效，替代网页见这里。然后其中提到了一个画架构的收费工具Sparx EA。免费的工具可以使用Archi。

图12：能力地图视图（基线）

能力地图视图可供业务架构师构建企业各项能力的结构化总览。能力地图通常展示覆盖整个企业的两级或三级能力。例如，可通过着色生成热力图，识别需要投入资源的领域。

图 11 中价值流的各个阶段由多项能力支撑，该对应关系如图 13 的交叉映射所示。能力通过组织的业务行为得以实现，例如由图 14 所示的业务职能落地。这些能力同时还需要配套合适的资源作为支撑。

图 13：价值流 — 能力交叉映射

💡 图中的Policy and Claim Management是保单与理赔管理。Sales And Distribution是销售与分销。

Business Functions

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

ArchiSurance 划分的主要业务职能如下：

• 市场营销（Marketing）：开展市场研究、规划、推广，并管理产品与细分市场；同时与精算部门协作进行产品设计。
• 精算（Actuarial）：厘定产品价格与准备金水平，配合市场营销部门开发新产品，并开展企业风险分析。
• 客户关系（Customer Relations）：涵盖 ArchiSurance 与客户之间的各类交互；负责解答客户咨询、受理报案，以及开展直销活动。
• 核保（Underwriting）：为单笔保单定价，生成保险建议书与保单文本
• 理赔（Claims）：针对每一笔 ArchiSurance 保单项下的索赔，制定并执行理赔处置方案
• 销售（Sales）：管理商机漏斗，并与客户完成合同签约
• 财务（Finance）：负责常规保费收取以及保险赔款支付
• 文档处理（Document Processing）：通过文档扫描、打印与归档，为其他业务职能提供支撑
• 投资管理（Investment Management）：在企业内部及监管要求的流动性与风险约束范围内，管理金融及不动产资产，实现收益最大化

ArchiSurance 三家分部的后台办公室中，部分业务职能存在重复设置。

为对业务职能及其之间的关系建模，我们可以定义业务职能视图，并借助 ArchiMate 语言内置的视图机制来规定该视图的内容。

业务职能视图用于展示组织的主要业务职能，以及职能之间基于信息流、价值流或物资流形成的相互关系。

在 TOGAF 中与之对应的是功能分解图。

图 14 展示了 ArchiSurance 的主要业务职能，以及各职能与外部参与方之间最重要的信息流转。

图14：业务功能视图（基线）

💡 图中向上的V形箭头图标是业务职能（business function）。
💡 这里还需强调一点，相同的图标以不同颜色表示其所在层级，例如黄色表示业务层，青色表示应用层，绿色表示技术层。因此青色的向上V型箭头表示应用职能，以此类推。

Capabilities versus Business Functions

请注意：业务职能（business function）与业务能力（capability）并不相同。业务能力代表组织当前具备或期望达成的能力，依靠人员、流程、信息与技术落地实现。业务能力聚焦特定业务成果，用于战略规划，正如 A 阶段：架构愿景（第 10 页）所述。与之相对，业务职能描述组织实际开展哪些工作；业务职能是被显性管理的单元，和组织结构的贴合度更高。多个业务职能（配合其他元素）可以共同支撑一项业务能力的落地。

举个例子：ArchiSurance 计划打造**数字化客户管理（Digital Customer Management）**这项新业务能力，作为其数字化深度客户经营战略的组成部分（见图 12）。该能力一部分将由客户关系业务职能实现，同时还依赖一项待落地的业务职能 —— 商业智能，以及各类资源，例如数据分析师、风险经理、数据采集与分析应用、客户行为数据。

当然，在绘制组织现有能力地图时，组织当前的各项业务职能通常会占据显著位置 —— 因为一家组织所开展的业务，必然是它有能力完成的事情。因此在描述基线业务架构时，能力地图的价值主要体现在两方面：一方面用于分析现有能力与目标能力水平之间的差距；另一方面用于挖掘组织已经具备、但尚未作为业务职能进行识别或管理的潜在能力。

图 15 展示了图 12 所列 ArchiSurance 主要业务能力，与本节提及的部分业务职能之间的若干关联关系。请注意，图中并未列出全部能力，因为本节介绍的业务职能聚焦于 ArchiSurance 的核心运营业务，而不包含管理类职能等内容。图 15 同时标注了代表概念所属分层的字母标记（S代表战略层，B代表业务层）。

图15：能力实现（基线，部分）

Business Processes

ArchiMate 的业务流程按照活动的先后顺序对业务行为进行分组，用于产出一组确定的产品或服务。流程架构展示最重要的业务流程及其相互关系，也可展示各流程内部的主要步骤。它通常不展示流程流转的全部细节，这类细节描述是业务流程设计语言的用途。我们可以定义业务流程视图，并借助 ArchiMate 语言定义的视图机制来规定该视图的内容：

业务流程视图用于展示一个或多个业务流程的高层结构与组成。

图16：业务流程视图（基线）

💡 图中向右的箭头表示业务流程（business process）

ArchiSurance 的各项业务流程实现其价值流（图 11）中的各个阶段，图 17 展示了其中一例。

图17：价值流是通过业务流程实现的

💡 图中向右的V形箭头的图标是价值流（value stream）。

Requirements Realization

在业务架构中，我们同样需要展示目标架构如何实现关键业务需求。为此，TOGAF 标准规定了业务足迹图（Business Footprint diagram）。在 ArchiMate 语言中，可通过**需求实现视图（Requirements Realization viewpoint）**来表达，该视图定义如下：

需求实现视图支持架构设计人员建模核心元素对需求的实现关系，这些核心元素包括业务参与者、业务服务、业务流程、应用服务、应用组件等。这类需求通常源自目标实现视图（Goal Realization viewpoint）。

图 18 的示例展示了架构愿景阶段确定的业务需求，是如何由各类架构元素实现的。

图18：(部分)需求实现视图

💡 图中矩形左侧带两小矩形的图标表示应用组件（application component）。最下层绿色长得像显示器一样的表示设备（device），而右侧带折角的绿色矩形表示制品（artifact）。

💡 artifact是计算机里实实在在的文件 / 数据载体。例如上图中的back office suite implementation, CRM system implementation，其中的implementation是交付出来的整套软件部署介质 / 实施成果：包含安装包、配置文件、数据库脚本、程序二进制文件、部署文档等一堆子制品，打包作为一个大 artifact。

Gap Analysis

ArchiSurance 的**数字化深度客户经营（Digital Customer Intimacy）**战略，同样要求对业务架构进行调整。首先，如前文所述，企业需要新增多项业务能力。图 19 在原有 “客户管理” 与 “保单及理赔管理” 能力的背景下展示了这些新增能力。

图19：能力差距分析

Capability Realization

这些业务能力需要具备数字化时代相应知识与技能的人员、用于数据采集的智能设备，以及客户数据本身。

资源地图视图可供业务架构师构建企业各类资源的结构化总览。资源地图也可展示资源与其所支撑的业务能力之间的关联关系。

在图 20 左侧，可看到和合理化战略相关的业务能力与资源；右侧则是与数字化深度客户经营战略关联的业务能力和资源。

图20：资源地图视图（目标）

这些资源本身，由业务架构、信息系统架构与技术架构的其余部分实现，而这三类架构正是 TOGAF ADM 中 B、C、D 阶段的工作对象。图 21 展示了由此产生的一小部分成果。请注意，该图并未描绘实现这些资源所需的全部元素，仅选取了代表性样例；图中依旧在左侧展示合理化战略的落地内容，右侧展示数字化深度客户经营战略的落地内容。在实际工作中，通常会单独创建视图，用以展示各项业务能力与资源的实现方式。

图21：资源实现视图（目标）

💡 图中齿轮图标表示设备（equipment ）。

Phase C: Information Systems Architectures (Application)

自并购完成以来，三家分部已共用一套统一的 Web 门户、呼叫中心软件套件以及文档管理系统。同时，公司选定了一套战略性客户关系管理（CRM）解决方案，并已在 Home & Away 与 PRO-FIT 两家分部落地实施。但管理层的重心在于将并购后的风险降至最低，同时持续保障各分部的日常业务运行效能，因此核心业务应用的整合精简工作尚未启动。

如今 ArchiSurance 已经达成并购后的业绩预期，投资者期望通过部署一套统一的、以产品和客户为核心的应用系统，实现大幅 IT 成本节约。因此当前仍存在多项挑战：Home & Away 仍沿用并购前的保单管理与财务套装软件，而 PRO-FIT 和 Legally Yours 则依旧使用各自并购前自研的单体应用系统。

Application Cooperation

ArchiMate 语言定义了应用协作视图，用于展示应用全景以及各应用之间的依赖关系：

应用协作视图通过应用组件之间的信息流，或者通过它们所提供与调用的服务，来描述应用组件间的关系。该视图通常用于绘制组织应用全景概览，也用于描述服务之间（内部的）协作或编排，这些服务共同支撑业务流程的执行。

在 TOGAF 中，和该视图对应的是应用通信图。

图 22 展示了 ArchiSurance 的主要应用系统以及系统之间的主要数据流。

图22：应用协作视图（基线）

图 23 中的应用协作视图展示了应用全景拟定的目标状态。

图23：应用协作视图（目标）

本视图包含以下应用组件，这些组件共同实现合理化场景：

• 一套集成后台套件，承载保单管理、财务交易等功能；该套件由以下子系统组成：
  • AUTO-U：自动核保系统，用于生成投保建议书与保单
  • P-ADMIN：商用套装保单管理系统，与自动核保系统集成，实现保单签发、变更与续保；该系统同时负责全业务线的客户账务与账单管理，替换原 Home & Away、车险及法律费用险遗留系统中的保单管理功能
  • VERSA-CLAIM：商用套装理赔系统，自带可配置界面与工作流，可支撑 ArchiSurance 三大业务线，替换原 Home & Away、车险及法律费用险遗留系统中的理赔处理功能
  • P-CONFIG：产品配置管理系统，用于定义全部保险产品，并通过 Web 服务将产品定义对外提供给 AUTO-U、P-ADMIN 与 VERSA-CLAIM。
  • BRIMS：业务规则管理系统（BRMS），包含规则库、处理引擎、规则开发环境以及用于规则管理用户界面的编写工具；业务规则引擎通过 Web 服务，向 AUTO-U、P-ADMIN、VERSA-CLAIM 和 P-CONFIG 提供规则执行能力。
• 一套通用 CRM 系统，供全公司统一使用。

Business-Application Alignment

TOGAF 标准并未专门定义用于业务 - 应用对齐的图。但它规定了可展示业务架构与应用架构之间关联关系的矩阵制品；例如应用 / 组织矩阵以及应用 / 功能矩阵。

应用组件之间的关系同样可以采用图形化方式建模。ArchiMate 语言定义了应用使用视图（Application Usage viewpoint）：

应用使用视图描述应用如何支撑一个或多个业务流程，以及应用之间如何相互调用。该视图可用于应用设计阶段，识别业务流程与其他应用所需要的服务；也可用于业务流程设计阶段，描述当前可用的服务。此外，由于该视图能够识别业务流程对应用的依赖关系，对于负责这些流程的运营管理人员也具备参考价值。

应用服务这一概念在该视图中处于核心地位。图 24 展示了 ArchiSurance 旗下 Home & Away 分部所使用应用提供的部分服务子集，以及理赔处理流程里的各个子流程分别调用了其中哪些服务。

图24：应用使用视图（基线）

Application Behavior

图 25 展示了数据仓库方案的运行行为：一方面涉及数据采集，另一方面关联业务流程与业务功能。单个客户的保险保费，部分基于从各类设备采集得到的数据。这些数据经过处理，生成客户专属画像，作为保费计算的输入依据。在聚合层面，该数据还可用于研发新型保险产品，并评估、调整公司的整体风险敞口。

图25：应用行为视图（目标）

Gap Analysis

应用架构的全局差距分析结果如图 26 所示。基线架构中存在的若干应用组件，在目标架构中将不再保留：独立的后台应用以及单独的法律费用险 CRM 系统。法律费用险客户所需的 CRM 功能，将由统一通用 CRM 系统承接；因此这部分无需新增组件（尽管可能需要对现有通用 CRM 系统进行适配或重新配置，但差距分析图中并未体现该点）。除此之外，方案还引入一套全新的后台应用套件以及新的数据仓库方案。

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

💡 上图图例中的plateau表示稳态平台。ArchiMate中的定义为：

稳态平台（Plateau）是架构在一段限定周期内保持相对稳定的架构状态。TOGAF 采用多个过渡稳态平台，分阶段完成从基线架构向目标架构的迁移，避免一次性大改造带来的高风险。

Phase C: Information Systems Architectures (Data)

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

信息结构视图类似于开发绝大多数信息系统时所创建的传统信息模型。该视图以数据类型或者（面向对象的）类结构的形式，展示企业内部、或特定业务流程 / 应用所使用信息的结构。

TOGAF 标准定义的数据类视图之一为逻辑数据图。

图 27 展示了 ArchiSurance 所定义业务对象的一个子集。客户信息包含保险档案，保险档案由投保申请、保险单以及理赔报案构成。系统定义了保险单对象的多个特化类型，ArchiSurance 销售的每一类保险，都对应一个保险单特化对象。

图27：信息结构视图显示主要业务对象

TOGAF 标准定义的另一类数据视图是数据分发图：

数据传播图的用途是展示数据实体、业务服务与应用组件之间的关系。该图展示逻辑实体如何由应用组件做物理落地实现。借此可以开展有效的容量评估，并优化 IT 资源占用规模。此外，通过为数据赋予业务价值，能够判断各应用组件的业务关键程度。

图28显示了一个ArchiSurance应用的数据分发图。

图28：数据传播示意图

💡 上图中，黄色信封表示业务对象，青色信封表示数据对象。

Phase D: Technology Architecture

在位于 Home & Away 总部的 ArchiSurance 前台办公区，部署了一台通用服务器和一台专门用于网页托管的服务器。位于 PRO-FIT 总部的共享服务中心（SSC）拥有独立服务器，供文档管理系统使用。三个后台办公区各自配备一台服务器，承载其应用系统。

局域网（LAN）将 ArchiSurance 三个办公地点内的服务器与个人计算机相连；这三处办公地点再通过企业广域网（WAN）互通。

如需概览基础设施全景，ArchiMate 语言定义了基础设施视图：

基础设施视图包含支撑应用层的软硬件基础设施元素，例如物理装置、网络，或是操作系统、数据库、中间件这类系统软件。

TOGAF 中与该视图对应的制品是环境与位置图。

Infrastructure

图 29 展示了 ArchiSurance 的主要基础设施组件，按地点和部门进行分组。该视图同时展示用于连接各类装置的网络，以及部署在这些装置之上的（应用）制品。

图29：基础设施视图（基线）

图30中的基础设施视图展示了技术基础设施的目标规划情况。

图30：技术架构：基础设施视图（目标）

ArchiSurance 在一组独立视图中，将基于物联网的数据采集内容可视化呈现于图 31，这部分内容在其全新的数字化客户深度经营（Digital Customer Intimacy）战略中已有概述。为支撑该战略，ArchiSurance 搭建数据采集网关，可连接各类能够生成相关数据的智能设备。这类设备在模型中被建模为装备（equipment）。而装备可部署在一处设施内；在图 31 中，我们能看到 “家庭报警系统” 与 “智能恒温器” 部署在一个 “智能家居” 设施之中。最后，智能恒温器本身连接至 “能源网络”，在 ArchiMate 语言中，该网络建模为分发网络（distribution network）。

图31：来自物联网服务的数据获取（目标）

ArchiSurance 的数据采集功能采用微服务架构实现。物联网设备可通过 REST API 在网关完成注册，同时调用 API 上的服务，向网关上报采集到的数据。针对每一台已注册设备，都会在容器中运行一份数据采集功能实例。网关依托平台即服务（PaaS）运行，PaaS 提供部署、集成、服务生命周期管理、计量、安全、负载均衡、存储、虚拟化等多项能力，详见图 32。

图32：物联网设备服务（目标）

Gap Analysis

图 33 可视化展示了技术架构全局差距分析的结果。独立的通用后台服务器计划下线。原 Home & Away 服务器集群将改造为 ArchiSurance 的核心后台服务集群，并在 PRO-FIT 总部的共享服务中心（SSC）增设一套备用服务器集群。同时，在 Home & Away 后台区域部署一台文档管理备用服务器。新后台套件与文档管理系统将分别在对应的主服务器和备用服务器上进行副本部署。

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

Phases E & F: Opportunities & Solutions and Migration Planning

针对 E 阶段与 F 阶段，TOGAF 9.2 标准引入了过渡架构，它代表基线架构与目标架构之间一种可行的中间状态或稳态平台（plateau）。

在 ArchiMate 语言中，可以使用迁移视图来展示基线架构、目标架构、过渡架构以及它们之间的关系：

迁移视图包含一系列模型与概念，用于定义从现有架构向期望架构演进的迁移过程。

图 34 为本场景的示例。ArchiSurance 的 IT 部门没有足够资源并行完成后台系统标准化以及 CRM 系统整合工作。因此其中一套过渡架构先将两套 CRM 系统合并为一套，但后台系统仍然保持独立。另一套过渡架构则实现统一后台套件，但保留两套 CRM 应用。在完成上述阶段后，再实施数据仓库与物联网方案。

Figure 34: Migration View

过渡架构支持对 CRM 整合、后台应用整合等实施项目进行规划。这些项目的实施顺序取决于所选的过渡架构方案。该内容可以通过 TOGAF项目上下文图展示（见图 35）：

项目上下文图展示作为整体转型路线图一部分、待实施工作包的范围。项目上下文图将工作包与受该项目新增、移除或影响的组织、功能、服务、流程、应用、数据及技术建立关联。

图35：TOGAF项目上下文图，用ArchiMate语言表达

参考文献

本案例研究引用了下列文档：
[1] 《TOGAF® 标准 9.2 版》，开放群组（The Open Group）标准（C182），开放群组 2018 年 4 月发布；参见网址：www.opengroup.org/togaf。
[2] 《ArchiMate®3.1 规范》，开放群组标准（C197），开放群组 2019 年 11 月发布；参见网址：www.opengroup.org/library/c197。
[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] 《ArchiSurance 案例研究》（Y121），开放群组 2012 年 1 月发布；参见网址：www.opengroup.org/library/y121；以及《ArchiSurance 案例研究 第 2 版》（Y163），开放群组 2017 年 9 月发布；参见网址：www.opengroup.org/library/y163。

参考

• ArchiMate® 3.2 Specification文档
• ArchiMate Notation: Part 1 – Business Layer
• ArchiMate Notation: Part 2 – Application Layer
• ArchiMate Notation: Part 3 – Technology Layer
• ArchiMate Notation: Part 4 – Physical Layer
• ArchiMate Notation: Part 5 – Strategy Layer
• ArchiMate Notation: Part 6 – Motivation Extension
• ArchiMate Notation: Part 7 – Implementation & Migration Extension
• ArchiMate Notation: Part 8 – Relationships