数字化转型架构:方法论与云原生实践
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

2.3 企业架构框架理论

企业架构经过几十年的发展,形成了许多架构框架理论,这里我们重点介绍其中比较典型的Zachman、TOGAF、FEAF、DoDAF、eTOM、ArchiMate、Gartner等。

2.3.1 Zachman

Zachman框架理论被John Zachman于1987年提出,在业界享有盛誉。Zachman框架是一种用于企业描述表示的二维分类方案,它由包含36个单元格的矩阵构成,每个单元格都关注企业的某个特定方面。

1)框架内容

表格中的每一行代表在信息系统构建过程中所涉及的不同干系人在描述信息系统时所采用的视角(见图2-2)。

图2-2 Zachman框架

• 范围/规划师(Planner):包括整个信息系统描述所处的环境上下文、内外部的各种约束,以及系统支持的业务范围,规划系统在功能和成本等方面的整体性要求。

• 业务模型/所有者(Owner):有关最终产品的概念视图,反映最终产品的使用特性,描述业务实体和各实体之间的关系。具有此视角的干系人包括最终产品的客户或用户。

• 系统模型/设计师(Designer):有关最终产品的逻辑视图,提供系统功能和数据模型,反映最终产品的本质规律及逻辑约束。具有此视角的干系人包括工程师、架构师、系统设计师等。

• 技术模型/建造者(Builder):反映在产品构建过程中现有技术的物理约束,包括系统开发的工具、技术方案和平台等。具有此视角的干系人包括软件工程师、系统实施所需的技术人员等。

• 详细表述/分包者(Sub-contractor):为了达到生产目的而对复杂对象进行分解的详细描述,定义具体的业务需求、系统模块等,可分配给开发者开展工作。

• 产品/运行中的企业(Functioning Enterprise):代表最终产品,是架构在客观现实中的实例体现,也就是运行中的企业本身。

表格中的每一列代表用于描述信息系统的某一个方面。

• 数据(What,什么内容):用于表示组成事物的模型,也包括数据模型。

• 功能(How,如何工作):用于表示功能和转换行为,如流程、功能模型等。

• 网络(Where,何处):用于表示各组成部件的位置及它们相互之间的关系,如物流、网络模型等。

• 人员(Who,何人负责):用于描述什么人应该做什么事,如人力模型、工作流模型等。

• 时间(When,什么时间):用于描述事物发生的时间及不同事物之间的相对时间关系,如生命周期和时序图等。对企业来说,这部分内容就是时间、动态模型等。

• 动机(Why,为什么做):用于表示最终结果和意义。对企业来说,这部分内容就是动机模型等。

(2)框架的含义

Zachman框架具有以下三种含义。

• 每个架构制品只能存在于一个表格单元中。每个架构制品的定义都必须是清晰的,不应该出现在两个或两个以上的表格单元中。

• 表中所有单元都应该填充完整。每个单元都是关键的,不应该缺失。

• 表中每一列的内容需要相互关联。例如,拥有者视图的语义模型必须在设计师视图的逻辑数据模型中得到映射。

Zachman框架从本质上来说是对企业架构描述的一种分类法,可以用来对复杂的系统进行分解,确保每个人的每个关注点都被照顾到,并确保业务需求可以被映射到技术实现上,同时技术实现可以回溯到业务需求上。这样就可以加强业务人员与信息技术人员的沟通和协同。

2.3.2 TOGAF

TOGAF(The Open Group Architecture Framework,开放组架构框架)是提供了一整套方法和工具的企业架构框架。TOGAF是一个跨行业、开放的框架,在全世界得到了广泛的使用。它基于一个迭代的过程模型,包含企业最佳实践和可重用的架构资产。它可以帮助企业设计、评估并建立机构的正确架构,为企业提供可落地的方法体系和参考。TOGAF在国际上已被验证,可以帮助构建企业IT架构,在提升业务灵活性的同时,提高信息系统应用水平。TOGAF得到了IBM、惠普、SAP、Oracle等厂商的积极推动及大部分福布斯排行榜50强企业的应用。

TOGAF由The Open Group于1995年发布,历经演化,2018年发布最新版——TOGAF 9.2。The Open Group是一个非营利性标准化组织,是一个技术中立的机构,致力于提出各种技术框架和理论结构。TOGAF还有官方The Open Group的认证体系,架构师可以通过考试获得TOGAF企业架构师资格国际认证。TOGAF的关键是架构开发方法(Architecture Development Method,ADM),对开发企业架构所需要执行的各个步骤及它们之间的关系进行详细的定义,以发展能够满足客户需求的企业架构。

2010年3月18日,全球著名的市场咨询和顾问机构IDC公司发布了《架构企业未来——2010企业架构中国管理者调查报告》。报告显示,中国逾七成大型企业已开始构建企业架构,TOGAF是认知度与接受度最高的架构框架。超过一半的企业了解TOGAF的框架开发方法,37.5%的企业选择TOGAF作为其企业架构设计方法。企业在考虑框架开发方法时,最关心的几个重要因素包括:架构的技术基础是否为业务导向、是否是开放的架构、是否可以落地实施、是否有成功案例、是否有对SOA的支持能力。TOGAF的优势和价值恰恰在此。

1)主要组成部分

TOGAF主要包含以下内容。

• TOGAF简介:介绍TOGAF及其核心概念、版本变化。

• ADM:TOGAF的核心,介绍TOGAF具体的架构开发方法。

• ADM指引和技术:介绍使用ADM的相关指南和技巧。

• 架构内容框架:介绍TOGAF的内容框架,包括元模型、可重用企业构建块、典型交付物等。

• 企业连续系列:介绍分类方法和工具,对架构活动经过进行分类和存储。

• TOGAF参考模型:提供两个架构参考模型,即技术参考模型(Technical Reference Model,TRM)和集成信息基础设施参考模型(Integrated Information Infrastructure Reference Model,III-RM)。

• 架构能力框架:介绍企业架构的组织、流程、技术、角色、责任等。

TOGAF各组成部分之间的关系如图2-3所示。图2-3左面的业务愿景和驱动力是输入部分,右面的业务能力是输出部分,TOGAF将二者有效地关联起来,使得企业的业务愿景和驱动力可以结合企业架构框架和方法促进业务能力的提升,同时通过业务运营,反向给予企业反馈和新的驱动力。

图2-3 TOGAF各组成部分之间的关系

图2-3的中间部分是TOGAF的核心,这部分又分为架构能力框架、ADM、企业连续系列三大部分。首先通过架构能力框架来定义架构能力,然后通过ADM指引和技术进行支持,最后将产生的产出物存储到存储库中,并根据企业连续系列进行分类,同时有参考模型作为参考。

架构能力框架:为了在一个企业中最大化地发挥企业架构的效能,一系列适当的组织结构、流程、技能、角色和责任等需被定义并结合起来,而架构能力框架正为组织好这些元素提供了指南。

架构能力框架主要包括以下内容。

• 架构能力建设指导:在组织内部建立一套架构能力的指导原则。

• 架构委员会指导:对建立和运作企业架构委员会的指导。

• 架构合规和契约:确保项目符合架构、契约定义和使用的指导原则。

• 架构治理的指导原则:对架构治理的框架指导原则。

• 架构成熟度模型:评估和量化企业架构成熟度的模型。

• 架构技能框架指导:对承担企业架构工作的人员进行角色、技能和规范的指导。

ADM是TOGAF中最为核心的部分,提供架构开发方法,它将企业架构的建设过程划分为几个步骤,并对每个步骤的输入、输出及过程都进行了详尽的说明(见图2-4)。ADM可以帮助企业了解和改善现有架构,在此过程中可以进行裁剪,可以多轮迭代,也可以多个项目并行在ADM的不同阶段。ADM各个阶段的内容如下所示。

图2-4 ADM

预备阶段:架构设计的准备过程,也是迭代的起始过程,目的是做好企业架构项目的准备,包括定义特定的架构框架、支持策略、原则等。

A. 架构愿景:关注企业愿景、范围、业务驱动力等准备情况。企业需要在这个阶段定义架构项目的规模、风险承担者及架构视图,这个不是一次就能做完的,需要通过持续演进和沟通慢慢实现。

B. 业务架构:创建业务架构,独立于技术,关注业务能力、流程,并进行与业务相关的架构视角分析。

C. 信息系统架构:顺接业务转向IT的重要架构,内部再分为应用架构和数据架构,两个阶段可以串行或者并行进行。

D. 技术架构:关注基础设施、中间件、数据库及一些支撑管控平台,如高可用、容灾、合规等相关技术体系。

E. 机会及解决方案:聚焦实施阶段,包含对交付物的描述、对解决方案的组合和集成、对内外部供应商的确认等。

F. 迁移规划:聚焦迁移规划,从基线架构过渡到目标架构,确保详细规划与架构愿景保持一致,和项目实现团队一同创建可行的实施和迁移规划。

G. 实施治理:关注实施的架构性监管,定义约束及架构契约,需监控每个项目和解决方案是否遵循架构规划,在合规性上不能妥协,追求长期愿景。

H. 架构变更管理:关注架构的变更管理,架构变更管理的目标是确保架构能够实现其原有的业务愿景。

另外,需求管理是ADM中的一个特殊阶段:管理架构需求的流程,适用于ADM周期的所有阶段。需求管理过程是一个动态的过程,需要关注企业需求的识别、存储,并与企业ADM其他阶段的输出与输入产生互动,是ADM过程的核心驱动。

ADM为开发企业架构的每个阶段提供了详细的定义和说明,包括每个阶段的目标、活动、输入、步骤、输出、技巧和交付物等。其中,业务架构、信息系统架构、技术架构是ADM的核心阶段,这三个阶段决定企业架构是否成功。

企业连续系列是企业架构资源库的一种视图,它为企业中的各种架构和解决方案制品提供了一种分类和组织的方法。企业连续系列提供了结构化模型,可以存储架构资产和相应的解决方案,如模型、模式、架构描述等。企业架构资源库为企业提供了可重用的参考资料,内容可以来自企业内部或行业外部,在企业架构建设过程中所产生的交付物也会持续地在企业架构资源库中更新。这部分主要包括以下能力。

• 对企业连续系列及其目的的解释。

• 使用企业连续系列来开发企业架构。

• 对架构进行分类和分割的特征的概览。

• 通过架构存储库提供一个结构化框架的概览。

2)核心架构制品

ADM过程各阶段涉及的核心产出物,在TOGAF中叫作架构制品,主要包括以下内容。

• 预备阶段:原则目录。

• 架构愿景:干系人映射矩阵、价值链图、解决方案概念图。

• 业务架构:组织/人员目录、角色目录、业务服务/功能目录、业务交互矩阵、人员/角色矩阵、业务足迹图、业务服务/信息图、功能分解图、产品生命周期图等。

• 信息系统架构(数据):数据实体/数据组件目录、数据实体/业务功能矩阵、系统/数据矩阵、类图、数据传播图等。

• 信息系统架构(应用):应用组合目录、接口目录、系统/组织矩阵、角色/系统矩阵、系统/功能矩阵、应用交互矩阵、应用通信图、应用和用户位置图、系统用例图等。

• 技术架构:技术标准目录、技术组合目录、系统/技术矩阵、环境和位置图、平台分解图等。

• 机会及解决方案:项目背景图、效益图。

• 需求管理:需求目录。

2.3.3 FEAF

FEAF(Federal Enterprise Architecture Framework)是美国联邦政府CIO委员会在1999年提出的“联邦企业架构框架”,是自Clinger-Cohen法案后第一个面向联邦企业架构的框架理论。FEAF是一个以架构建设过程为重点的企业架构框架理论,同时提出的片段架构(Segement Architecture)的概念对于以后的FEA具有很大影响。

FEA是一个商业驱动框架,可提供更加以公民为中心、注重成果和以市场为基础的服务。FEA应用FEAF理论,用以简化联邦企业流程、降低成本,加强跨机构和业务线信息共享。FEA并不是一个严格意义上的企业架构框架,而是一种企业架构的具体实例。架构内容的定义和架构过程的描述是FEA的核心内容,除此之外还包括企业架构评估框架(EAAF)及联邦过渡框架(FTF)。

1)企业生命周期

2001年,CIO委员会发布了《联邦企业架构实施指南》,用于为各个企业提供构建企业架构的指导,并且该指南介绍了将企业架构融入各个企业生命周期的方法。

在这里,企业架构过程是一个独立运行的迭代过程,而除此之外一个企业的良性发展还需要企业工程和项目管理、资金规划和投资控制过程,如图2-5所示。在这三个核心过程中,企业架构过程作为企业架构的构建、维护和使用的指导;资金规划和投资控制过程为企业投资的选择、控制和评估提供工具;企业工程和项目管理对企业各个实施项目进行管理。

图2-5 企业生命周期

CIO委员会对企业架构过程的描述与TOGAF中的ADM有着相似之处,二者都采用了循环迭代的方式,并且大部分步骤都有着相似的意义和内容。CIO委员会将企业架构过程分为九个步骤,这些步骤列举如下。

• 取得上层主管的认同和支持。

• 建立企业架构管理组织。

• 定义架构过程和方法。

• 开发基线企业架构。

• 开发目标企业架构。

• 开发序列计划。

• 使用企业架构。

• 维护企业架构。

• 控制与监督。

2)FEA参考模型

FEA包含一系列便于在联邦各机构中进行跨部门分析的参考模型,这些参考模型有助于在整个联邦企业范围内或在某个部门中寻找重复投资、识别差距和合作机会。FEA参考模型形成了一套框架,通过业务和性能驱动方法,这样各部门可以用统一的方式来描述联邦企业架构的重要组成元素。FEA参考模型序列包含以下五层参考模型(见图2-6),各部门需要通过五层参考模型描述当前架构和目标架构,找出之间的差别,并细化到各个项目中,进而对这些项目实施管理,促进企业架构的演进。

图2-6 FEA五层参考模型

• 性能参考模型(Performance Reference Model,PRM):输入、输出及最终结果;定制的性能指标。

• 业务参考模型(Business Reference Model,BRM):业务线;机构、客户与合作伙伴。

• 服务组件参考模型(Service Component Reference Model,SRM):服务领域、服务类型;业务与服务组件。

• 数据参考模型(Data Reference Model,DRM):主题域、超类、信息交换;数据对象、数据性质、数据展现。

• 技术参考模型(Technical Reference Model,TRM):服务组件接口、互操作性;技术、建议。

3)FEA实施指南

OMB于2007年年底发表了《FEA实施指南》,用以指导如何开发和利用联邦企业架构,从而改善联邦企业效能。

效能改善生命周期是一个迭代循环的过程,各部门通过结合各个实践领域,逐步实现其战略目标。这个过程分为架构阶段、投资阶段和实施阶段三个阶段,每个阶段都包含一些彼此相关的流程,整体驱动各种需求的实现,而这些需求主要来自两个方面。

• 自上而下的需求,即部门为了改善效能而主动制定的战略目标。

• 自下而上的需求,即在实际运行中产生的需求,如系统改进目标。

这其中的演进过程本身也是企业架构逐步细化的过程。企业架构一开始以部门级的信息整合体的形态出现,经过细化转变各个具体领域的片段架构,并最终体现为解决方案架构。企业架构、片段架构和解决方案架构采用不同的详细度,为各个层面的干系人提供整体视图,它们之间的关系如图2-7所示。片段架构更关注部门的核心任务领域、业务服务和相关企业服务;片段架构继承了企业架构所使用的框架方法,重用各种架构资产和规范标准,并根据业务领域进行扩展。解决方案架构一般限制在一个项目范围内,面向的干系人一般是系统用户及开发人员;解决方案架构受企业架构标准的约束。此外,FEA提供了企业架构价值评测过程,针对企业架构的开发过程进行跟踪,监督企业架构中IT投资决策、重用度、标准达成、干系人满意度等方面的指标完成情况。

图2-7 不同级别架构对比示意

2.3.4 DoDAF

DoDAF(Department of Defense Architecture Framework)是由美国国防部制定的架构框架理论,DoD是美国国防部的简称。在企业架构领域,DoDAF并没有TOGAF的知名度高,它主要在军队系统内应用。

DoDAF借鉴美国国防部总体架构的基本原则,定义整个与国防有关的信息系统总体架构,目的是确保各个指挥组织、服务提供和各个部门的系统架构描述一致。DoDAF提供解决人员、流程和技术融为一体且结构化的架构方法集,各种架构相互融合,具体应用时需要针对场景来设计具有自身特点的架构标准方法。

1)框架范围

DoDAF的框架范围如图2-8所示。

图2-8 DoDAF的框架范围

• 使命驱动:提供顶层架构的概念、开发指引、最佳实践和方法集合,支持指挥、管理和能力域的决策流程。

• 聚焦数据:可确保架构师通过视图和模型为决策者提供可视的数据支持,基于类似通用语言,为团队架构开发和信息交互提供指引。

• 方法和技术:适用于开发、维护、使用、分析、评估整个过程,以及相关的拼接和连接。

2)八大视图

DoDAF框架大体上可由八大视图组成,为了保持各个视图间的一致性和整体性,DoDAF V2.0定义了52个制品来展示从需求到实施的整个架构。但不是所有制品都是必需的,可以按需使用。DoDAF V2.0八大视图如图2-9所示。

图2-9 DoDAF V2.0八大视图

• 全景视图(All Viewpoint,AV):提供对整个架构描述的整体信息,如架构描述的范围与背景。

• 数据和信息视图(Data and Information Viewpoint,DIV):体系化地描述业务需求和业务流程规则,如属性、特征和相互关系。

• 标准视图(Standards Viewpoint,StdV):各部分或元素间组合、交互和互依赖性的最小集合,确保系统满足特定需求,包括技术标准、执行惯例、规则和标准。

• 能力视图(Capability Viewpoint,CV):描述能力,用于实现符合企业愿景的企业目标。

• 作战视图(Operational Viewpoint,OV):描述组织、任务或活动,以及之间交换的信息。

• 服务视图(Services Viewpoint,SvcV):涉及与作战活动相关的支持系统、服务和互连功能。

• 系统视图(Systems Viewpoint,SV):包括自动化系统、连通性和系统功能方面的信息。

• 项目视图(Project Viewpoint,PV):描述项目计划、投资组合计划,每个项目交付相应的系统或功能。

3)实施方法

DoDAF的实施方法包括六个步骤。

(1)确定架构用途。定义架构的用途及预期用途,确定架构开发中使用的方法、所需的数据类别,以及通过客户满意度等指标来衡量过程。

(2)确定架构的范围。确定架构的范围,范围定义了边界,这些边界建立了架构描述的深度和广度,建立了架构的问题集,助力定义架构的上下文,并定义架构所需的细节信息。

(3)确定数据需求。选择数据实体与属性,保持架构的一致性。数据类型包括业务行为规则、需要完成的活动、指挥关系、任务列表等。

(4)进行架构设计。对所有数据进行组织分类,并关联到架构存储库中,输入和编辑现有体系结构模型,以备后续分析和重用。

(5)对架构进行分析。对架构进行静态和动态分析,包括试验及进行相关的测试,以确定架构数据的有效性。

(6)生成架构成果文件。生成基于基本数据查询的体系架构产品描述,其描述应当与既定模型保持一致,具有可重用性且能被共享,并进行最终架构成果文件归档。

2.3.5 eTOM

eTOM(enhanced Telecom Operations Map,增强的电信运营图)是TOM(Telecom Operation Map)的计算机化、企业战略化提升,主要包含对电信运营企业架构的规范描述。

目前,TOM已经成为服务供应商运营管理的工业标准,但其只包含运营管理过程,而没有覆盖整个企业的业务流程。eTOM是基于TOM发展而来的,把TOM扩展到企业构架层面,包含业务运营、企业管理流程、市场营销流程、客户保留流程等,帮助企业理解与客户服务管理相关联的端到端处理过程。

eTOM是一种业务流程模型或框架,其作为电信运营业务流程向导的蓝图,从业务视图来描述需求,对业务流程进行分析,进而经过系统分析与设计,形成解决方案,最终通过一致性测试,然后投入实际运行。eTOM模型图把战略流程管理从运营流程中分离出来,形成两个部分:一部分为战略、基础设施和产品功能流程组,另一部分为运营功能流程组。

eTOM业务流程模型分为多个视图层次,图2-10所示为其Level 1视图,Level 1视图主要包括以下三个部分。

图2-10 eTOM业务流程模型(Level 1视图)

• 战略、基础设施和产品过程:指导运营过程,包括战略开发、基础设施生命周期管理、产品生命周期管理。

• 运营过程:eTOM的核心,包括运营支持和条件准备、业务实现、业务保障、业务计费,以及相应的准备过程和销售管理过程。

• 企业管理过程:强调企业层面的过程目标,包括所必需的基本业务过程,与企业中的其他过程形成交互。

除了这三个主要的部分,eTOM又被分为四个层次。

• 市场、产品和客户关系管理:包括销售和渠道管理、营销管理、产品和定价管理、客户关系管理、问题处理、SLA(服务等级协议)管理、计费等。

• 服务管理:包括业务的开发和配置、业务问题管理和质量分析、业务使用量的计费等。

• 资源管理:企业基础设施的开发和管理,无论这些设施是为产品提供支持还是为企业本身提供支持。

• 供应商和合作伙伴关系管理:包括支持产品和基础设施的供应链管理,以及其他供应商和合作伙伴之间日常运营的管理。

eTOM的目的是通用性,因此它通常独立于组织和业务,强调业务驱动、以客户为中心。eTOM支持两种不同的视图来细化和分组业务过程。

• 垂直的过程分组:描述端到端的业务过程,如整个计费流程所涉及的过程。

• 水平的过程分组:描述面向功能的过程,如管理供应链所涉及的过程。

2.3.6 ArchiMate

ArchiMate是一种整合多种架构的可视化业务分析模型,属于企业架构描述语言。ArchiMate从业务、应用和技术三个层次,物件、行为和主体三个方面,以及产品、组织、流程、资讯、资料、应用、技术等多个领域来进行描述。ArchiMate是The Open Group发布的企业级标准,可以作为TOGAF的图形建模工具。

1)与TOGAF的关系

ArchiMate起源于荷兰,一开始聚焦于领域建模角度,在建设过程中得到了荷兰政府及各工业院校的支持。2008年,ArchiMate的主导权被转移到The Open Group的手中,目前已发展到ArchiMate 3.1版本。相对于ArchiMate 1.0版本,ArchiMate 3.1版本不仅在多个方面对原来的内容进行了修订,并将ArchiMate与其手中的TOGAF标准进行了很好的整合,使ArchiMate可以在企业业务、信息系统和技术层面进行描述,并提供了一定的对迁移与实现的扩展性。图2-11所示为TOGAF与ArchiMate之间的结合关系。

图2-11 TOGAF与ArchiMate之间的结合关系

2)架构概念与分层

ArchiMate的基础是IEEE 1471标准,该标准定义了用于描述系统架构的基本概念及其之间的关系,为系统的定义、分析和描述提供了理论基础。图2-12所示为ArchiMate的基本概念及其之间的关系。

图2-12 ArchiMate的基本概念及其之间的关系

为了做好不同层次概念的平衡,ArchiMate也对概念进行了分层,分为通用概念、企业架构概念、领域或企业特有概念。层次从上到下概念越来越专业,层次从下到上概念越来越通用,方便沉淀和复用。

2.3.7 Gartner

Gartner在企业架构建设领域中积累了大量实践经验,它以此为基础对外提供关于企业架构方面的各种最佳实践。严格来讲,Gartner不算企业架构框架理论,因为它不提供企业架构的内容和建设方法。因此,如果企业要借助Gartner的力量来建设企业架构,一般需要购买咨询服务,或者参考Gartner提供的实例自行建设企业架构。

虽然没有高度抽象且规范化的通用方法论,但是Gartner关于企业架构有着自己的理念。Gartner将企业架构看作动态的过程,并且认为企业架构建设的起点应该是企业的发展目标,而不仅是当前现状。一个成功的企业架构应该能将业务和技术联系起来,提供统一的针对企业发展方向的愿景规划。