保险公司案例研究
ArchiMate ArchiSurance Case Study : ArchiSurance
Archisurance 案例研究是一个虚构的例子,旨在说明 Archimate ® togaf 中的建模语言 ® 在框架中使用。 该案例研究涉及archisurance,一家由三个以前独立的公司合并而成的保险公司。 案例研究描述了公司的基线架构,然后是一些变更场景。
该案例研究需要用作认证的建筑师培训课程的示例。 但是,它不是 togaf 定义的一部分。 这项工作通过说明 togaf 和 archimate 标准的组合来支持开放团队的无限信息流愿景,以一致地表示跨不同组织、系统和计划的架构信息。
如何撰写令人印象深刻的案例研究 - Jenfi

介绍

这个虚构的案例研究说明了 archimate 企业建模语言在 togaf 框架中的实际使用。 该案例研究涉及保险公司archisurance,这是由三个以前独立的公司在不同大都市区合并的结果。
该案例研究在整个 Archimate 培训课程中用作示例,并作为 Archimate 认证考试的背景。 它从基线业务、应用程序、数据和技术架构开始,具有适当的架构或 togaf 视角。 该研究继续进行了两种变化情景。 第一个场景提供了一个说明 togaf 架构开发和实现周期的视图示例。 它显示了架构愿景、业务目标、原则和要求、目标业务、应用程序、数据和技术架构、基线和目标之间的差距分析结果,以及支持实施和迁移计划的视图。 在第二个场景中,使用第一个场景的目标状态作为新的基线,客户可以通过网络直接访问他们的保险组合。 没有适用于这种情况的模型。
Opengroup 期望案例研究随着时间的推移而发展,并鼓励其成员添加新的方面和视图或创建新的变更场景,只要它们与原始案例描述和模型一致。

TOGAF ® 和archimate ®

企业架构框架涵盖了支持企业架构师的不同方面。 除其他外,它们可能包含以下内容的任意组合:
  • 创建模式的过程(“它是如何工作的”)
  • 观点的集合或分类
  • 一种描述架构的语言(定义概念和关系,但也包括符号)
Opengroup 为企业架构维护两个开放标准:togaf [1] 和 archimate [2]。
togaf的核心是企业架构开发和实现的过程——架构开发方法(ADM)。 Togaf 还描述了观点、技术和参考模型,以及识别构成架构的构建块类型的内容框架。 但是,togaf 没有指定使用特定的建模语言来创建架构视图。
Archimate 是一种图形语言,它提供模型的统一表示以支持整个架构开发周期。 该标准的 2.0 版包括旨在描述实际架构(业务、信息系统和技术架构及其关系)的核心语言,以及对架构动机建模的扩展,以及架构实施和迁移规划。 图 1 描述了核心语言和扩展如何链接到 togaf Adm。 除了建模概念和关系之外,archimate 和 togaf 一样,定义了一组架构观点。
Toaf 和 archim 在使用他们的理念和想法来捕捉和传达单一基础设施模型的不同方面方面有着坚实的共同基础。 这些标准相辅相成,因为 togaf 专注于开发和实施架构的过程,而 archimate 专注于为架构工件建模的统一语言。
技术标准 [2] 中描述的 Archimate 语言是对 togaf [1] 的补充,因为它提供了一组独立于供应商的概念和关系,包括图形表示,这有助于创建一致的集成模型,可以在意见的形式。
图1:archimate和togaf的对应关系

背景

Archisurance [3,4] 是最近三个以前独立的保险公司合并的结果:
  • 专业从事房主保险和旅游保险_ 家在家里_
  • ,专业从事汽车保险_ 亲和力_
  • ,专营律师费保险_ 它合法地属于你_
公司现由三个部门组成,其名称和总部与其独立的前身相同。
图2:保险:三家保险公司合并的结果
Archisurance 的成立是为了利用这三个组织之间的许多协同作用。 合并前的三家公司虽然销售的保险种类不同,但商业模式却大同小异。 这三种产品都通过互联网、电子邮件、电话和邮政渠道直接销售给消费者和小企业。 尽管总部位于不同的城市,但每个都完全位于大都市区的现代化办公楼中。 每家公司都拥有忠实的客户群以及在诚信、价值、服务和财务稳定性方面的良好声誉。 这三家公司均由机构投资者和个人投资者组成的连锁集团私人控股。
这三家公司的主要投资者在注意到低成本竞争对手正在进入他们的市场、高增长地区有新的机会、每家公司都需要大量新的 IT 投资以保持竞争力后,开始了合并谈判。 他们意识到,只有合并后的规模更大的公司才能同时控制成本、保持客户满意度、投资新技术并利用具有高增长潜力的新兴市场。 合并谈判和监管批准历时18个月,但文件是在两年前签署的,合并完成。
新公司提供三个合并前公司的所有保险产品,并打算经常调整其产品以适应不断变化的市场条件。 像它的三个前身一样,archisurance 通过印刷、互联网和直接营销直接向客户销售。
合并给新公司的业务流程和信息系统带来了许多集成和协调挑战。 这些挑战在架构基线业务、应用程序、数据和技术架构中很明显。 但首先,togaf ADM 的初始阶段为这些挑战创造了激励环境。

预备阶段

为了引导其业务和信息技术的未来变化,archisurance 决定开发基于 togaf 9.1 和 archimate 2.0 的企业架构,并进行最少的剪裁。
作为初始阶段的一部分,确定架构参与中的关键利益相关者及其关注点(在archimate中建模为内部驱动因素)。 Togaf 定义了一个利益相关者映射矩阵来表示这一点。 在archimate中,这可以使用利益相关者的观点来表达:
利益相关者视角允许分析师对利益相关者、他们的关注点和他们的评估(在优势、劣势、机会和威胁方面)进行建模。 此外,可以描述与解决这些问题和评估的初始(高级)目标的联系。
图 3 显示了此类图表的一部分,该图表识别和建模了两个利益相关者(架构师董事会及其当前和潜在客户)及其作为驱动因素的关注点。 客户满意度是两个利益相关者共同关心的问题。 利益相关者的满意度可以细化为更详细的关注点; e. 例如,利润。
图 3:利益相关者视图片段
驱动因素推动特定业务目标的发展,如下所示,以产生利润。 降低成本等目标可分为降低维护成本和降低人员成本。
Archimate 将原则定义为给定上下文中所有系统的规范属性,或它们的实现方式。 请注意,这里的“系统”包括组织和组织单位,而不仅仅是系统。 因此,原则有助于实现业务目标。 Togaf 将原则定义为架构应满足的定性意图陈述。 一个原则必须有一个支持的理由和一个重要的措施。
Archimate 原则视图(图 5 中显示的示例)以图形方式描述了原则、它们的依赖关系以及它们实现的目标:
“原则”视角允许分析师或设计师对与手头的设计问题相关的原则进行建模,包括激励他们的目标。 此外,可以对原则与其目标之间的关系进行建模。 例如,原则可能对彼此产生积极或消极的影响。
Togaf 定义了一个原则目录,以提供这些原则的概述。
图 4:与推动利润相关的业务目标
图5:原理图

阶段 B:基线业务架构

合并后,archisurance 建立了一个共享前台,作为销售和客户服务的多渠道联络中心。主要联络中心位于合并前的 home & away 总部。 目前,三个原始公司的保险产品仍有三个独立的后台处理。 在合并前的盈利总部设立了共享服务中心 (SSC),用于文件处理。 该中心管理中央文档存储库和所有自动化文档工作流程。 此外,当具有法律约束力的文档进入或离开归档时,它会执行所有扫描、打印和归档操作。 为了确保业务连续性和处理高峰活动,SSC配备了训练有素的人员和设备来执行前台的职能,这也做好了充分的准备。
图 6:档案的全球组织
在togafadm的阶段B(业务架构),archimate可以表达和关联archisurance组织结构、产品、服务、功能、流程和信息。 业务架构为数据、应用程序和技术架构提供上下文。

组织的结构

为了描述组织结构,archimate定义了一个组织视点
专注于公司、部门、网络或其他组织实体的(内部)组织。 在此视图中,模型可以表示为嵌套框图,但可以使用更传统的方式,例如组织结构图。 组织视角对于确定组织中的能力、权限和责任非常有用。
对应的 togaf 是组织分解图。
组织结构通常用树表示,如图 7 所示,虽然 archimate 和 togaf 使用的组织分解方法比简单的树组织图有更多的选择。 此视图显示了档案馆的高级组织结构,以及它的主要位置和部门。 或者,嵌套图可以将组织细分为位置和部门。
图 7:组织视图

业务功能

根据一组选定的标准(通常是所需的业务资源和/或能力)对业务功能组行为进行归档。
归档的主要业务功能如下:
  • 营销、研究、计划、推广和管理产品和细分市场,并与精算师合作设计产品
  • 精算,确定产品价格和储备水平,配合市场部设计新产品,分析企业风险
  • 客户关系,包括档案馆与其客户之间的互动; 它处理客户问题,捕获收到的索赔,并进行直接营销活动
  • 承保,为单一保单设定价格,并生成保险计划和保单
  • 针对每项索赔提出索赔、制定和执行archisurance的回应
  • 财务,包括根据合同制定的客户保单定期收取保费,处理保险理赔的支付
  • 文件处理,支持文件扫描、打印、归档等功能
  • 投资管理,管理金融和房地产资产,以在公司和监管流动性和风险限制内最大化回报
其中一些业务功能在档案管理三个部门的后台复制。
为了对业务功能及其关系进行建模,archimate 定义了业务功能视点
业务功能视图显示了组织的主要业务功能及其在信息流、价值流或商品流方面的关系。
此视图的 togaf 对应物是功能分解图。
图 8 显示了归档的主要业务功能,以及功能与外部角色之间最重要的信息流。 它还展示了不同部门后台业务功能的复制。
图 8:业务功能视图

操作流程

归档业务流程根据活动的顺序对行为进行分组。 它生产一组已定义的产品或服务。 流程架构展示了最重要的业务流程及其关系,也可能展示了每个流程中的主要步骤。 它通常不会显示流程的所有细节,这是业务流程设计语言的目的。 Archimate 定义了一个业务流程观点:
业务流程视图用于显示一个或多个业务流程的高级结构和组合。
此视图的 togaf 对应物是流程图。
图 9 显示了 archisurance 的两个核心业务流程及其高级子流程:关闭合同(在销售新保险产品时执行)和处理索赔(当收到损坏索赔时)。 尽管这些流程的细节对于不同类型的保险产品可能有所不同,但主要步骤是相同的​​。
图 9:业务流程视图

阶段 C:基线信息系统架构(应用程序)

自合并以来,三个部门采用了共同门户、联络中心软件套件和文档管理系统。 此外,该公司还选择了战略性 CRM 解决方案,并针对家庭和外出以及盈利情况实施了该解决方案。 然而,核心业务应用程序的合理化尚未开始,因为管理层的重点是最大限度地降低整合风险,同时不断提高每个部门的日常绩效。 既然 Archisurance 已经达到了合并的性能预期,投资者希望通过采用一套通用的产品和以客户为中心的应用程序,他们可以显着节省成本。 因此,仍然存在一些挑战。 Home & away 仍然使用其合并前的政策管理和财务应用程序包,而盈利和合法的您仍然使用他们自己的合并前自定义应用程序。
图 10:应用环境

应用合作

Archimate 定义了一个应用程序协作视图来显示应用程序环境和应用程序之间的依赖关系的概述:
“应用程序协作”视角描述了应用程序组件之间的关系,即它们之间的信息流,或者它们提供和使用的服务。 这种观点通常用于创建组织应用环境的概览。 此视图还用于表示共同支持业务流程执行的服务(内部)协作或编排。
此视图的 togaf 对应物是应用程序通信图。
图 11 显示了归档的主要应用程序和它们之间的主要数据流。
图 11:应用程序协作视图

业务应用对齐

Togaf 没有为业务应用程序对齐定义图表。 但是,它确实指定了一个基于矩阵的视点来显示业务和应用程序架构之间的联系; e. 例如,应用/组织矩阵和应用/功能矩阵。
应用程序组件之间的关系也可以以图形方式建模。 Archimate 定义了应用程序使用的观点:
应用程序使用角度描述了应用程序如何用于支持一个或多个业务流程,以及其他应用程序如何使用它们。 它可以通过识别业务流程和其他应用程序所需的服务或描述可用服务来设计应用程序。 此外,因为它标识了业务流程对应用程序的依赖关系,所以它对负责这些流程的运营经理很有用。
应用服务的概念在这个观点中起着核心作用。 图 12 显示了由档案家庭和外出部门使用的应用程序提供的服务的子集,以及索赔处理流程的哪个子流程使用这些服务中的哪一个。
图 12:应用程序使用视图

阶段 C:基线信息系统架构(数据)

Archisurance 数据架构描述了其概念业务对象和逻辑数据对象之间的主要关系。 Archimate定义了信息结构的观点
信息结构的观点几乎可以与信息系统开发过程中创建的任何传统信息模型相媲美。 它以数据类型或(面向对象的)类结构的形式显示企业或特定业务流程或应用程序中使用的信息结构。
togaf 定义的数据视点之一是逻辑数据图。
图 13 显示了由架构定义的业务对象的一个​​子集。 部分客户信息是保险单据,包括保险索赔、保险单和损坏索赔。 定义了许多保单对象的专业化,一种针对通过archisurance销售的每种保险类型。
图 13:信息结构视图
togaf定义的另一个数据视点是数据传播图
数据发布图的目的是显示数据实体、业务服务和应用程序组件之间的关系。 该图显示了应用程序组件如何物理实现逻辑实体。 这允许有效地调整和优化它的足迹。 此外,通过为数据分配业务价值,可以获得应用程序组件的业务关键性的指示。
图 14 显示了一个归档应用程序的数据发布图。
图 14:数据发布图

阶段 D:基线技术架构

图 15 概述了 Archisurance 的技术基础设施格局。 它在前厅,在
Home & away 总部有一个公共服务器和一个用于网络托管的专用服务器。 pro fit 总部的共享服务中心 (SSC) 拥有自己的文件管理系统服务器。 三个后台办公室中的每一个都有一个用于其应用程序的服务器。
局域网 (LAN) 连接三个存档位置中的服务器和个人计算机,而这三个存档位置又通过公司广域网 (WAN) 连接。
图 15:基础设施格局
对于基础设施景观的概述,archimate 定义了基础设施视点
基础架构视点包含支持应用层的软件和硬件基础架构元素,例如物理设备、网络或系统软件(例如操作系统、数据库和中间件)。
这个视图对应的togaf是环境和位置图。
图 16 显示了归档的主要基础架构组件,按位置和部门分组。 此视图还显示了连接不同设备的网络以及部署在设备上的(应用程序)工件。
图 16:基础架构视图

改变场景

场景一:应用组成合理化

归档应用程序架构的不灵活性使其难以适应业务条件的变化。 部分由于整合,应用环境变得碎片化,导致数据冗余和功能重叠,以及使用各种数据格式和方法的点对点应用集成。 这些问题会导致内部不稳定,增加应用程序维护成本,并阻碍公司内部和与合作伙伴的信息共享。 因此,IT 部门积压了大量工作请求。 Archisurance 高级管理层非常关注积压,尤其是无法满足与大量签约销售合作伙伴和有影响力的保险顾问自动共享信息的需求。
此方案通过以下方式使归档应用程序组合合理化:
  • 迁移到用于策略管理和金融交易的集成后台办公套件。 该套件将包括:
○。生成建议和政策的自动承保系统_ 汽车u_
○。与自动核保系统集成的一揽子保单管理系统,用于发布、修改和更新保单; 该系统还处理客户记帐和计费_ P-管理员_
○。带有屏幕和工作流程的打包索赔系统,可配置为支持归档的三个业务线_ VERSA-CLAIM_
O 是一个产品配置管理器,它定义了所有的保险产品,并通过 web 服务将它们暴露给 auto-u、p-admin 和versa-claim_ P-CONFIG_
O 业务规则管理系统(BRMS),由规则存储库、处理引擎、规则开发环境和规则管理用户界面编写工具组成。 业务规则引擎通过 Web 服务向 auto-u、padmin、versa-claim 和 p-config 公开规则执行功能。 边缘,
  • 完成向战略 CRM 系统的迁移
Archisurance 的首席投资者和首席执行官支持这些举措,前提是 Archisurance 的客户和合作伙伴没有看到所有的变化。 保险公司的产品和服务不得受到影响,所有客户和合作伙伴的互动必须持续进行。
图 17:应用程序组合合理化
作为这项工作的一部分,技术基础设施也将得到简化。 独立的后台服务器将被位于总部数据中心的共享服务器集群所取代。 但是,为了确保业务连续性,Pro-FIT 总部的数据中心还将配备一组备份服务器。

A 阶段:架构愿景

togafadm 的 a 阶段通过设置范围、约束和目标来建立架构工作并启动架构开发周期的迭代。 此阶段还验证业务上下文并开发架构工作说明。
业务上下文由基于关键业务目标和架构原则的关键业务需求组成。 图 18 显示了当前场景的一些相关业务目标和原则。
图 18:业务目标和原则
目标和原则是具体要求的基础,如archimate关于目标细化的观点所示
目标细化视角允许设计人员将(高级)目标细化建模为更具体的目标,并将具体目标细化为描述实现目标所需属性的需求或约束。 使用聚合关系将目标细化为子目标。 将目标细化为需求是使用实现关系建模的。
图 19 显示了当前更改场景的此视图示例。
图 19:目标优化视图
架构愿景的一个重要元素是基线和目标架构的高级表示,以向利益相关者解释架构工作的附加价值。 Archimate 定义了一个介绍性的观点
介绍性视图使用简化的符号来形成完整档案语言的子集。 它通常用于设计轨迹的开始,当不需要详细解释所有内容或向非建筑师解释建筑模型的性质时,他们需要更简单和更直观的符号。 这种基本的、不太正式的视图的另一个用途是,它试图避免建筑设计已经固定的印象,当使用更正式、高度结构化或详细的可视化时,很容易出现这种想法。
此视图的 togaf 对应物是解决方案概念图。
以下示例突出显示了当前更改场景中所需的最重要更改:
  • 在前台,独立的律师费CRM系统将消失。
  • 在后台,一个单独的后台应用程序被一个单独的后台套件取代。 三台独立的通用后台服务器将被一个共享服务器集群和一个备份服务器集群所取代。
图 20:介绍性视图

B阶段:目标业务架构和差距分析

在这种情况下,业务架构保持不变。 但是,在业务架构中,我们也展示了目标架构如何实现关键业务需求。 为此,togaf 指定了一个业务图。 在archimate中,这可以用需求实现来表达,定义如下:
需求实现视点允许设计人员通过核心元素(如业务参与者、业务服务、业务流程、应用程序服务、应用程序组件等)对需求的实现进行建模。 通常,需求是从目标细化的角度产生的。
下面的例子展示了如何通过架构中的元素来实现架构愿景阶段建立的业务需求。
图 21:需求实现视图

阶段 C:目标应用架构和差距分析

下面的应用程序通信图显示了应用程序环境的建议目标。
图 22:目标应用架构:应用协作视图
应用架构的全局差距分析结果如下图所示。 基线架构中存在的几个应用程序组件不再存在于目标架构中:独立的后端应用程序和单独的法律费用保险 CRM 系统。 法律费用保险客户的CRM功能由通用CRM系统接管; 因此,这不需要新的组件(尽管现有的通用 CRM 系统可能需要调整或重新配置,这在差距分析中并未显示)。 此外,还引入了一套新的后台应用程序。
图 23:应用架构:差距分析

D阶段:目标技术架构和差距分析

下面的基础架构视图显示了技术基础架构领域的拟议目标。
图 24:目标技术架构:基础架构视图
图 25 显示了技术架构的全局差距分析结果。 将删除一个单独的通用后台服务器。 home&away的原服务器集群将成为中央归档后台服务集群,其他备份服务器集群将放置在Pro-FIT总部的SSC中。 在家和外出的后台办公室中还有一个备份文档管理服务器。 新的后台办公套件和文档管理系统将被复制到各自的主服务器和备份服务器。
图 25:技术架构:差距分析

实施和迁移规划

Togaf 9 为阶段 E 和 F 引入了过渡架构,表示基线架构和目标架构之间可能的中间状态(“平台”)。
在 archimate 中,基线、目标和转换架构以及它们的关系是使用迁移视点显示的:
迁移视点包含可用于指定从现有架构到所需架构的转换的模型和概念。
图 26 显示了当前场景的一个示例。 档案管理的 IT 部门没有足够的资源来并行执行后台系统集成和 CRM 系统集成。 因此,过渡架构用一个替换两个 CRM 系统,但有一个单独的后端系统。 另一个有一个后端套件,但有两个 CRM 应用程序。
图 26:迁移视图
过渡架构支持实施项目的规划,例如CRM集成和后台应用集成。 这些项目的顺序取决于选择的过渡架构。 这可以在 togaf 项目上下文图中显示(图 27)
项目上下文图显示了将作为更广泛的转型路线图的一部分实施的工作包的范围。 项目上下文图将工作包链接到将被项目添加、删除或影响的组织、功能、服务、流程、应用程序、数据和技术。
图 27:togaf 项目上下文图,archimate 表示

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

在这个场景中,假设场景 1 的目标状态是一个新的基线,客户可以通过网络直接访问他们的保险组合。 通过使客户能够:
  • 根据 Archisurance 开展业务时使用的规则,在线安全地购买、续订或修改其房主、旅行、汽车或法律费用保险
  • 通过以下方式获得在线交易帮助:
O 在知识库中搜索答案 o 与客户服务代表 (CSR) 开始聊天会话 O 使用 Web 表单编写并提交电子邮件,CSR 将回复它 o 使用 Web 表单请求 CSR 电话
  • 从档案合作伙伴处获取信息和特别优惠以满足他们的需求,例如银行和财务规划服务、投资、信用卡和其他类型的保险
没有适用于这种情况的模型。 开放组鼓励其成员为本案例研究的未来版本做出贡献。 贡献者可以扩展或添加此处描述的两个场景的详细信息,或者创建新的场景。 然而,为了促进一个连贯的工作主体,新变更场景的基线架构应该是这里描述的变更场景的基线或目标。

参考

  1. 1.
    TOGAF ® 9.1 版 , 开放组,由开放组出版,2011 年。
  2. 2.
    ArchiMate ® 二 标准,开放组,2012 年 1 月到期。
  3. 3.
    Dost, H.、iacob, M. - e.、lankhorst, MM(已编辑)和 van Leeuwen, D.:视点函数和示例,archimate 可交付成果 D3 4.1a V2,Ti / RS / 2003 / 091,远程信息处理研究所,荷兰恩斯赫德,2004。
  4. 4.
    Van den Berg, H., moelaert, F.: pro fit autoscade open test stand, test bench deliverable WP3 / N004 / V001, TRC, Enschede, Netherlands, 1997。
Last modified 6mo ago
Copy link
Outline
介绍
TOGAF ® 和archimate ®
背景
预备阶段
阶段 B:基线业务架构
组织的结构
业务功能
操作流程
阶段 C:基线信息系统架构(应用程序)
应用合作
业务应用对齐
阶段 C:基线信息系统架构(数据)
阶段 D:基线技术架构
改变场景
场景一:应用组成合理化
场景 2:在线投资组合管理
参考