概述本笔记的目的是通过一个虚拟案例了解TOGAF做企业架构的简明过程。我读的是英文版PDF从这里下载。文中的后的文字是我的注释。直到笔记写完我才发现此Case Study的最新版本为v3.2而且还提供中文版不过以上都没有影响翻译是次要的重要的是阅读过程中的理解以及学会查阅文档以解决问题。如了解原始定义图标含义扩展阅读等。Executive SummaryArchiSurance 案例研究是一个虚构示例旨在演示在 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 架构内容框架中所规定的各类图。图1ArchiMate 语言与 TOGAF ADM 的大致对应关系BackgroundArchiSurance 是由三家原本独立的保险公司合并而成的Home Away专注于房主保险和旅游保险PRO-FIT专注于汽车保险Legally Yours专注于法律费用险现在公司由三大部门组成名称和总部沿用了它们各自独立时的名字和位置。图 2ArchiSurance三家保险公司合并的结果ArchiSurance 公司成立的目的是充分利用这三家机构之间大量的协同效应。合并前这三家企业销售不同类型的保险产品但商业模式相近。三家公司均通过网络、电子邮件、电话和邮寄渠道直接面向个人消费者与企业客户开展销售。尽管总部位于不同城市但每家企业都坐落于大都市的现代化综合办公园区内。三家企业都拥有忠实的客户群体并在诚信、性价比、服务品质与财务稳健方面享有良好口碑。这三家公司均由相互关联的机构投资者与个人投资者组成的集团私有控股。三家公司的主要投资方发现低成本竞争者正涌入市场、高增长地区出现新机会并且每家公司都需要大量新增 IT 投入才能保持竞争力后便启动了并购谈判。他们认识到只有合并组建规模更大的公司才能同时管控成本、维持客户满意度、投入新技术并把握住高增长潜力的新兴市场。并购谈判与监管审批耗时 18 个月两年前各方签署相关文件并购正式落地。新公司保留合并前三家企业的全部保险产品并计划根据市场环境变化动态调整产品供给。和三家前身公司一样ArchiSurance阿基保险通过网站、电子邮件、电话、邮政邮件渠道直接向客户销售同时也通过中介机构开展间接销售。RationalizationArchiSurance 的应用架构缺乏灵活性难以适应业务环境的变化。部分由于本次并购应用系统格局变得零散造成数据冗余、功能重复并且采用多种数据格式与实现方式进行点对点应用集成。上述问题引发系统内部不稳定、应用维护成本上升企业内部以及和外部合作伙伴之间的信息共享困难。由此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价值流CapabilitiesArchiSurance 需要对多项能力进行优化或调整以落地其设想的战略与运营变革。为此该企业参考保险业 Panorama360 参考模型搭建了能力地图从而清晰掌握自身现有能力如图 12 所示。 Panorama360 参考模型的原始网页已失效替代网页见这里。然后其中提到了一个画架构的收费工具Sparx EA。免费的工具可以使用Archi。图12能力地图视图基线能力地图视图可供业务架构师构建企业各项能力的结构化总览。能力地图通常展示覆盖整个企业的两级或三级能力。例如可通过着色生成热力图识别需要投入资源的领域。图 11 中价值流的各个阶段由多项能力支撑该对应关系如图 13 的交叉映射所示。能力通过组织的业务行为得以实现例如由图 14 所示的业务职能落地。这些能力同时还需要配套合适的资源作为支撑。图 13价值流 — 能力交叉映射 图中的Policy and Claim Management是保单与理赔管理。Sales And Distribution是销售与分销。Business FunctionsArchiMate 的业务职能依据选定的一组标准通常是所需业务资源和 / 或胜任力对业务行为进行分组。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 ProcessesArchiMate 的业务流程按照活动的先后顺序对业务行为进行分组用于产出一组确定的产品或服务。流程架构展示最重要的业务流程及其相互关系也可展示各流程内部的主要步骤。它通常不展示流程流转的全部细节这类细节描述是业务流程设计语言的用途。我们可以定义业务流程视图并借助 ArchiMate 语言定义的视图机制来规定该视图的内容业务流程视图用于展示一个或多个业务流程的高层结构与组成。图16业务流程视图基线 图中向右的箭头表示业务流程business processArchiSurance 的各项业务流程实现其价值流图 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 AnalysisArchiSurance 的**数字化深度客户经营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 CooperationArchiMate 语言定义了应用协作视图用于展示应用全景以及各应用之间的依赖关系应用协作视图通过应用组件之间的信息流或者通过它们所提供与调用的服务来描述应用组件间的关系。该视图通常用于绘制组织应用全景概览也用于描述服务之间内部的协作或编排这些服务共同支撑业务流程的执行。在 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 AlignmentTOGAF 标准并未专门定义用于业务 - 应用对齐的图。但它规定了可展示业务架构与应用架构之间关联关系的矩阵制品例如应用 / 组织矩阵以及应用 / 功能矩阵。应用组件之间的关系同样可以采用图形化方式建模。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项目上下文图展示作为整体转型路线图一部分、待实施工作包的范围。项目上下文图将工作包与受该项目新增、移除或影响的组织、功能、服务、流程、应用、数据及技术建立关联。图35TOGAF项目上下文图用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 Instituut2004 年。[4] van den Berg, H.、Moelaert, F.《PRO-FIT 车险开放案例测试平台》测试平台交付件 WP3/N004/V001TRC荷兰恩斯赫德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 LayerArchiMate Notation: Part 2 – Application LayerArchiMate Notation: Part 3 – Technology LayerArchiMate Notation: Part 4 – Physical LayerArchiMate Notation: Part 5 – Strategy LayerArchiMate Notation: Part 6 – Motivation ExtensionArchiMate Notation: Part 7 – Implementation Migration ExtensionArchiMate Notation: Part 8 – Relationships