2018, Vol. 27
2. 中汇信息技术(上海)有限公司, 上海 201203
2. CFETS Information Technology (Shanghai) Co. Ltd., Shanghai 201203, China
根据ANSI/IEEE-1471-2000[1]标准中的定义, 架构(Architecture)是系统的基本组织, 包括其组成部分、相互关系和环境, 以及指导其设计和演化的原则; 企业架构(Enterprise Architecture)是一种架构, 涉及的系统是整个企业, 特别是企业的业务流程、技术和信息系统; 架构框架(Architectural Framework)是一套基本结构, 定义了推荐的架构工件, 描述这些工件之间的关联关系, 并提供了这些架构工件的通用定义.
为了能够更好的设计企业架构, 针对企业中具有普遍性的问题提供统一化、标准化的解决方案, 以便更有效率的建立企业的信息系统, 该领域产生了许多企业架构方法, 主流的有Zachman企业架构框架[2]、FEA联邦企业架构[3]和TOGAF开放群组架构框架[4]等. 这些企业架构方法各有特色, 对企业业务流程标准化程度有一定要求, 企业需要结合自身的发展情况来选择不同的方法. Roger Sessions对主流企业架构框架做了权威的比较和分析[5], 为该领域后续的研究提供了重要参考. 文献[6]研究分析了三种主流的企业架构框架, 对企业架构组件进行了分类. 文献[7]定义了在组织中采用企业建模方法的含义, 描述了将其作为支持企业持续改进和发展策略的制度化过程, 总结了经验和方法. 由于现如今的企业在高度复杂和动态的环境中运作, 需要软件供应链、外包及协作开发的情形也越来越多, 文献[8]评估了6种企业建模标准的可用性与整合性, 提出了适应于敏捷企业架构建模的混合企业架构建模方法. 目前, 国内企业已认识到了企业架构方法的重要性并开始进行实施[9], 但从对企业架构方法的认识和应用来说, 还有很大发展空间, 迫切需要结合业务实际, 采用敏捷的、具有定制和扩展能力的企业架构方法, 适应企业不断发展和平稳运行的要求.
1 企业架构方法的发展与现状 1.1 Zachman企业架构框架Zachman是由Zachman J于1987年提出的一套企业架构理论, 同时, 它也是世界上第一个企业架构理论, 为今后该领域的研究提供了理论基础. Zachman实际上是一套抽象规则的集合, 由行和列组成的一个二维矩阵来表示, 该矩阵的列代表不同的看待企业业务的视角, 分别是数据(What)、功能(How)、网络(Where)、角色(Who)、时间(When)、动机(Why), 矩阵的行代表不同的企业领域, 分别是范围(Scope)、业务(Business)、系统(System)、技术(Technology)、组件(Component)、操作(Operations).
Zachman架构方法以视角为切入点, 通过列出企业在各个视角下的需求, 全方位、多角度的探索了企业发展中会遇到的问题, 以此为侧重点进行企业架构开发. Zachman是典型的以视角为中心的架构方法, 这种方法会在开发时能将大多数情况有条理地进行分类.
1.2 FEA联邦企业架构美国联邦企业架构(Federal Enterprise Architecture, FEA), 是2002年许多专家、厂商共同提出的架构理论, 提出之后便应用在美国联邦政府的电子政务系统设计中. FEA是一套较为成熟和完整的方法论体系, 适合政府各层机关和大型企业信息系统的顶层设计.
OMB(美国白宫的管理与预算办公室)的 《Enterprise Architecture Assessment Framework v3.0》将FEA所涵盖的内容分为如下三个部分:
(1) FEA参考模型: 为各个机构提供了一套公共的企业架构描述方法, 使他们可以使用相同的语言交流;
(2) 联邦过渡框架: 定义一些能够进行跨部门使用的各种信息技术资源的描述方式;
(3) 企业架构评估框架: 定义了一系列评估标准来衡量各机构对于联邦企业架构项目的执行情况.
以上三个部分中, FEA参考模型是整个企业架构的核心, 它为各个机构提供了一套公共的企业架构描述方法, 从而使采用不同企业架构框架的机构可以使用相同的语言进行交流.
FEA架构方法是一套较为成熟的企业开发框架, 它通过定义企业发展中的各种标准实践、参考模型以及公共服务, 为后续的架构开发提供了强大的理论和实践支持. 通常, 这种架构方法被称为以标准化为中心的方法, FEA就是其中的典型代表. 这类方法在描述企业架构时较为全面, 各方面都会涉及和考虑, 其标准化的思想通常被国家或企业等大型单位所认可.
1.3 TOGAF开放群组架构框架开放群组架构框架(The Open Group Architecture Framework, TOGAF), 是由国际标准权威组织The Open Group于1993年发表的架构框架. TOGAF从四个架构领域进行设计:
(1) 业务架构: 定义了业务战略、策略、组织和关键业务流程;
(2) 数据架构: 描述了组织的逻辑和物理数据集的结构和数据管理资源;
(3) 应用架构: 为一个独立的应用提供了蓝图, 描述了它与组织核心业务流程之间的交互;
(4) 技术架构: 描述了软件和硬件, 来支持业务、数据和应用服务, 其中包括了IT基础设施、中间件、网络、通讯、流程、标准等等.
架构开发是一个持续的、循环的过程, 所以需要迭代地修正架构, 此时架构设计理念的完整性便显得尤为重要. TOGAF企业架构设计框架在以往架构设计的丰富经验之上, 总结、积累出的一套最佳实践模型, 提供了一整套完整的架构开发和管理的框架, 称为ADM(Architecture Development Method), 这也是TOGAF架构设计理论的优势之处.
ADM是在大量参与者持续贡献企业开发经验的基础上促成的, 它为开发和管理企业的生命周期提供了一种新的可能性, 是TOGAF理论的核心. 如图1所示, ADM以需求为核心驱动力, 一个完整的架构开发周期在此驱动力之下依次经过架构愿景、业务架构、信息系统架构、技术架构、机遇和解决方案、迁移规划、实施治理、架构变更管理各个阶段, 逐步完善新需求下的企业架构升级.
|
图 1 TOGAF的架构开发方法 |
一般认为, 良好的企业架构依赖于良好的过程, 因此, TOGAF架构方法将实践经验汇聚在一起, 定义了这个过程. TOGAF架构方法是一套较为完整、实用性较高的企业设计框架, 属于典型的以过程为中心的架构方法, 最近几年被普遍的运用在各大企业之中, 具有较高的知名度.
1.4 企业架构方法的比较和分析各种企业架构方法的性质和范围不同, 在不同应用环境下的适应性也不同, 需要在具体实践之前挑选出最适合企业的架构方法, 本节对以上三种主流的企业架构方法进行比较和分析.
在著名的Roger Sessions对企业架构的研究中, 选用了12个评价标准来比较和评估架构方法, 使用者可以挑选其中需要的部分作为评判的起点. 这12个评价标准分别是:
(1) 分类完整性(Taxonomy completeness): 指的是用户使用该方法能多好地对各种框架工件进行分类.
(2) 流程完整性(Process completeness): 指的是该方法能多充分地指导用户通过循序渐进的过程来创建企业架构. TOGAF提出的ADM的主要关注点便在这上面, 同时, FEA架构方法也开始强调这一领域的重要性.
(3) 参考模型指导(Reference model guidance): 指的是该方法能多好地帮助用户建立一套相关的参考模型. 该指标的内容几乎是FEA的所有关注点, 同时, TOGAF也提供这方面的支持.
(4) 实践指导(Practice guidance): 指的是该方法能多大程度上帮助用户将企业架构的思维方式融入到用户的组织中, 并培养出符合公司气质的文化氛围.
(5) 成熟度模型(Maturity model): 指的是该方法在评估企业中不同组织的有效性和成熟度方面能给出多少指导.
(6) 业务关注度(Business focus): 指的是该方法是否侧重于使用技术来驱动业务价值, 这里, 业务价值被明确定义为减少支出或增加收入.
(7) 治理指导(Governance guidance): 指的是该方法在为企业创建有效的治理模型方面能提供多少帮助.
(8) 分区治理(Partitioning guidance): 指的是该方法能多有效地指导企业实现分区自治, 这是管理企业架构复杂性的一种重要方法.
(9) 规范目录(Prescriptive catalog): 指的是该方法能多有效地指导用户建立一个可以重用的企业架构资产目录.
(10) 供应商中立性(Vendor neutrality): 指的是在采用该方法时, 用户会有多依赖于特定的咨询组织, 得分高意味着依赖性低. 在这个指标中, TOGAF脱颖而出, 因为它是许多厂商支持的开放标准.
(11) 信息可用性(Information availability): 指的是该方法相关的免费或低价资料的数量和质量. 资料越丰富, 说明该方法的社区越活跃, 该方法的生命力越强.
(12) 时间价值性(Time to value): 指的是使用方法来构建解决方案、产生商业价值之前, 用户可能会花费的时间长度.
Roger Sessions使用以上12个评价标准, 对三种架构方法进行对比和评估, 得到以下的评估得分, 本文对每种方法的指标得分计算了平均值和方差, 如表1所示.
由表1可见, Zachman方法的综合评分不高, 但是在分类完整性上的优势较为明显; FEA架构方法各方面能力适中, 表现较为稳定; TOGAF架构方法的总体得分和FEA并列第一, 但相比之下得分分布得更为均衡, 同时, TOGAF方法对供应商依赖小, 有良好的社区, 其相关资料也更加容易获得, 对使用者十分友好. 一般认为, Zachman框架提供了企业架构的本体, FEA方法更适合政府机构使用, 而TOGAF偏向于实践, 提供了确实可行的企业架构方法, 重用性和扩展性也较好.
|
表 1 三种架构方法的评估得分及平均值和方差 |
2 企业架构建模规范 2.1 ArchiMate企业架构描述语言
ArchiMate[10]是TOGAF理论配套的企业架构建模规范, 它是一种企业架构描述语言, 也是一种可视化的业务分析模型语言.
ArchiMate的诞生最早可以追溯到本世纪初, 是由荷兰该领域的相关研究组织制定的, 制定过程中受到了政府、工业界和学术界的广泛支持. 后来, The Open Group对其进行修订, 使其可以与TOGAF理论紧密结合.
如图2所示, ArchiMate中的业务层、应用层、技术层分别对应TOGAF的核心概念——ADM中的业务架构、信息系统架构、技术架构三个领域; 最新发布的ArchiMate添加了策略&动机层、实现&迁移层, 它们覆盖了ADM中的其他领域. 策略&动机层可以描述ADM中的预备阶段、架构愿景、架构变更管理以及需求管理四个领域, 而实现&迁移层可以描述ADM中的实施治理、迁移规划以及机会及解决方案三个领域. 对每个层次, ArchiMate提供了描述对应领域元素的图例, 实现了可视化, 用户可以使用ArchiMate对TOGAF理论进行完整的实践.
图3是ArchiMate中经典的3×3×3模型, 展示了图例及关系的层次和属性. 横向来看, ArchiMate中的基本元素可以分为三个层次: 业务层、应用层和技术层, 它们分别描述了企业架构开发中的不同抽象层次. 纵向来看, 元素可以根据它们的属性分为三大类: 对象、行为和主体, 其中对象代表架构中的被动元素, 主体代表架构中的主动元素. 此外, 元素和元素之间的关系也可以划分为三大类: 结构化关系、动态关系和其它关系, 它们分别用来连接架构中的不同元素.
|
图 2 ADM和ArchiMate架构描述语言 |
|
图 3 ArchiMate的3×3×3模型 |
2.2 Archimate与UML
Unified Modeling Language (UML)[11], 即统一建模语言, 创建于1994年10月, 可以用图形化的方式对软件系统进行面向对象的描述和建模. UML2.0版本是被广泛使用的版本, 目前UML的最新版本是2.5.
ArchiMate和UML有很多相似之处, 它们都是可视化的, 都可以用来描述系统, 且都提供了丰富的元素和关系, 但它们的差别也是明显的. 首先, 以ArchiMate提供的元素间关系为基准, 对比UML中的元素关系, 如表2所示.
可以看出, ArchiMate提供了丰富的关系, 其中部分关系的含义可以和UML中完全匹配, 小部分关系的含义不同, 还有一些关系是ArchiMate所特有的.
|
|
表 2 ArchiMate和UML的关系对比 |
然后, 以业务层、应用层和技术层为基线, 评估ArchiMate和UML提供的基础元素映射到这三个层面的情况, 如表3所示. 可以看出, ArchiMate在业务层、应用层和技术层提供了全面充分的元素, 可为企业架构提供形式化的描述(除去这三层的元素, ArchiMate在策略&动机层、实现&迁移层也提供有大量元素). UML也有一些元素可以用来描述业务层、应用层和技术层, 但是它更倾向于对应用程序的细节进行建模.
总体来看, ArchiMate是高层次的关注架构设计的描述语言, 描述对象的层次更加抽象和概念化, 而UML则用来描述系统的细节部分. ArchiMate适用于在高层次去标识应用程序元素、接口和用法, 然而对于单个应用的详细的内部结构、交互和行为, 这些部分在设计意图上超出了ArchiMate的范围, 应使用UML等其他建模语言描述.
3 基于ArchiMate的企业架构设计案例ArchiMate是一种实用企业架构描述语言, 通过配合TOGAF方法论的架构设计方法可以设计出清晰的架构图. 同时, ArchiMate也是一个开放、自由的企业架构描述语言, 它允许企业根据自身的需要对语言本身进行定制, 这也是Archimate的优点之一. 经过前期调研分析, 中汇信息技术(上海)有限公司(下文简称“中汇”)目前正在推广TOGAF方法论来完成架构分析与设计, 并选择采用Archimate语言来描述项目架构. 本节通过项目组的一个真实案例, 展现使用ArchiMate设计企业架构的基本方法, 同时, 案例中利用了ArchiMate开放性的特点, 根据公司和项目的需要进行了规范定制.
|
|
表 3 ArchiMate和UML的元素映射 |
3.1 项目背景
为积极配合人民币国际化与二十四小时无中断服务的发展方向, 进一步提升本外币用户的服务体验, 在原有电话、传真等传统服务模式的基础上, 基于互联网的在线客户服务模式, 推出中心场务微信服务号.
3.2 项目主要功能公众号关注用户可以进行交易员(本币/外汇)实名绑定认证、及查看交易中心介绍与交易中心其他订阅号链接等信息. 已实名绑定认证用户可以享受专有的微信服务功能, 如: 申请应急撤单、应急交易、应急修改交易要素、应急报价、应急暂停报价、应急申请交易后确认、用户解锁、用户重置密码等应急服务; 预约场务人员回电服务; 主动联系场务人员并向场务人员发送多媒体信息(微客服); 解除实名绑定的服务等.
3.3 项目架构图图4所示的架构图是使用ArchiMate架构描述语言绘制的, 在遵循基础的语言规范之外, 根据项目需要和特点灵活地进行了定制.
|
图 4 使用ArchiMate绘制的微信系统架构图 |
根据项目的架构表述需要, 对架构图层次进行了删减, 省略掉了业务层的描述, 主要展示应用层和技术层部分. 因此, 该架构图主要包括两部分: 应用层和技术层. 具体地, 应用层按照应用服务层、组件和接口层以及外围系统三大层进行绘制; 技术层按照基础设施服务层、基础设施层和可复用构件层进行绘制, 使架构层次更加清晰. 其中, 可复用构件层为定制部分, 包含中汇公司长期开发实践过程中积累下的一些可复用的构件, 它可以被应用层中的组件所引用.
下面依次介绍每个层次的基本作用和定制细节:
(1) 应用服务层: 限定只包含原应用层中应用服务(Application service), 即该系统应用层中对终端用户、外部系统以及内部其它服务提供接口的服务, 比如微信接入服务、后台管理服务等.
(2) 组件和接口层: 限定只包含原应用层中的内部具体实现, 即应用组件(Application component)和应用接口(Application interface)元素, 同时, 定义了组件之间通讯的描述方式.
(3) 外围系统层: 是对原应用层的扩展, 它作为本系统的关联系统, 为系统提供数据和功能, 或使用本系统的数据和功能, 包含的元素限定为应用组件(Application component)和应用接口(Application interface), 其中应用接口向外提供调用的方法, 被本系统直接调用.
(4) 基础设施服务层: 限定只包含原技术层中的技术层服务(Technology service), 它对底层基础设施所提供的基本服务进行进一步抽象分类, 比如Web容器、文件存取等.
(5) 基础设施层: 限定只包含原技术层中的节点(Node)和系统软件(System software), 节点通常用来表示服务器, 系统软件可以表示操作系统、数据库等. 基础设施层可以体现真实的底层部署情况, 比如系统部署了几台服务器, 每台服务器上包含哪些系统软件, 某台服务器具体实现了哪些技术服务等. 其中, 中汇编写《开源商用系统软件版本选型》并定制了系统软件列表, 为不同的软件类型定制不同的图标, 并在绘制架构图时自动选择推荐版本的软件.
(6) 可复用构件层: 是根据项目需要对原技术层进行的扩展, 只包含工件(Artifact)元素, 用于表示本系统中用到的可复用构件, 这里列出的构件可在应用层组件中通过属性的方式被引用, 所以在图上没有和任何元素有关系连线. 其中, 构件列表自动关联中汇构件库, 根据不同类型的构件定制不同的图标, 并自动选择构件库中最新的构件版本.
除了对层次进行细化, 项目组也对层次之间的关系进行了规范限定: 规定应用服务层和技术服务层与上一层的关系都是服务于(Serving)关系; 组件和接口层以及基础设施层与上一层的关系都是实现(Realization)关系. 同时, 应用接口和应用组件的服务于关系上注明了组件之间通讯的方式, 比如HTTP-REST等方式.
4 结论与展望随着互联网和信息化的不断进步和发展, 企业的架构设计也必然会越来越受到重视, 企业架构框架也将飞速发展. 接下来需要持续关注该领域的变动和发展情况, 同时, 企业架构方法论在企业中的落地也显得十分重要, 如何低成本的引导企业相关人员使用架构方法设计出符合企业要求的架构设计, 也是需要持续考量的关注点.
| [1] |
IEEE Standard. ANSI/IEEE 1471–2000 - IEEE recommended practice for architectural description for software-intensive systems. http://standards.ieee.org/findstds/standard/1471-2000.html. [2017-12-01].
|
| [2] |
Zachman J A. Zachman framework. https://en.wikipedia.org/wiki/John_Zachman. [2017-12-01].
|
| [3] |
Office of Management and Budget. Federal Enterprise Architecture (FEA). https://obamawhitehouse.archives.gov/omb/e-gov/FEA. [2017-12-01].
|
| [4] |
The Open Group. The open group architecture forum. http://www.opengroup.org/subjectareas/enterprise/togaf. [2017-12-01].
|
| [5] |
Sessions R. A comparison of the top four enterprise-architecture methodologies. http://www3.cis.gsu.edu/dtruex/courses/CIS8090/2013Articles/A%20Comparison%20of%20the%20Top%20Four%20Enterprise-Architecture%20Methodologies.html. [2017-12-01].
|
| [6] |
Scholtz B, Calitz A, Connolley A. An analysis of the adoption and usage of enterprise architecture. Proceedings of the 1st International Conference on Enterprise Systems. Cape Town, South Africa. 2013. 1–9.
|
| [7] |
Persson A, Stirna J. Organizational adoption of enterprise modeling methods – experience based recommendations. In: Frank U, Loucopoulos P, Pastor Ó, et al, eds. The Practice of Enterprise Modeling. Berlin, Heidelberg: Springer, 2014. 179–192.
|
| [8] |
Gill AQ. Agile enterprise architecture modelling: Evaluating the applicability and integration of six modelling standards. Information and Software Technology, 2015, 67: 196-206. DOI:10.1016/j.infsof.2015.07.002 |
| [9] |
彭桦. 基于TOGAF和ProVision的供应链管理CTO架构分析与建模[硕士学位论文]. 上海: 复旦大学, 2012.
|
| [10] |
The Open Group. The archiMate® enterprise architecture modeling language. http://www.opengroup.org/subjectareas/enterprise/archimate-overview. [2017-12-01].
|
| [11] |
Object Management Group®, Inc. Unified modeling language. http://www.uml.org. [2017-12-01].
|