ImageVerifierCode 换一换
格式:DOCX , 页数:384 ,大小:10.58MB ,
资源ID:3524539      下载积分:10 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.docduoduo.com/d-3524539.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录   微博登录 

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(企业架构研究总结.docx)为本站会员(weiwoduzun)主动上传,道客多多仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知道客多多(发送邮件至docduoduo@163.com或直接QQ联系客服),我们立即给予删除!

企业架构研究总结.docx

1、企业架构研究总结本人不是作者,本文来自作者:闹市闲云 博客:http:/ 目录企业架构研究总结 .1企业架构研究总结(1) 参考资料列表 1企业架构研究总结(2) 问题的由来和基本概念 2企业架构研究总结(3) 企业架构的发展历程 6企业架构研究总结(3) 企业架构的发展历程 6企业架构研究总结(4) 企业架构与企业架构框架概论 .9企业架构框架之异同 .9企业架构研究总结(5) Zachman 框架 .15企业架构研究总结(6) 联邦企业架构之 FEAF 的出现和构成(上) .20企业架构研究总结(7) 联邦企业架构之 FEAF 的出现和构成(下) 25企业架构研究总结(8) 联邦企业架构之

2、 CIO 委员会的企业架构实施指南(上).30企业架构研究总结(9) 联邦企业架构之 CIO 委员会的企业架构实施指南(下).35企业架构研究总结(10) 写在中间的感想 .39企业架构研究总结(11) 联邦企业架构之 FEA 及参考模型(上) .42企业架构研究总结(12) 联邦企业架构之 FEA 及参考模型(中) .48企业架构研究总结(13) 联邦企业架构之 FEA 及参考模型(下) .51企业架构研究总结(14) 联邦企业架构之联邦过渡架构及企业架构评估框架 .66企业架构研究总结(15) 联邦企业架构之 FEA 实施指南(上) .71企业架构研究总结(16) 联邦企业架构之 FEA

3、实施指南(下) .84企业架构研究总结(17) 联邦企业架构之我见 .93企业架构研究总结(18) TOGAF 总论及架构开发方法(ADM)概述 .941. 架构开发方法 .96企业架构研究总结(19) TOGAF 架构开发方法(ADM)之准备阶段 .99企业架构研究总结(20) TOGAF 架构开发方法(ADM)之架构愿景阶段 .104企业架构研究总结(21) TOGAF 架构开发方法(ADM)之业务架构阶段 .108企业架构研究总结(22) TOGAF 架构开发方法(ADM)之信息系统架构阶段.113企业架构研究总结(23) TOGAF 架构开发方法(ADM)之技术架构阶段 .122企业架

4、构研究总结(24) TOGAF 架构开发方法(ADM)之机会及解决方案阶段.126企业架构研究总结(25) TOGAF 架构开发方法(ADM)之迁移规划阶段 .130企业架构研究总结(26) TOGAF 架构开发方法(ADM)之实施治理阶段 .135企业架构研究总结(27) TOGAF 架构开发方法(ADM)之架构变更管理阶段.138企业架构研究总结(28) TOGAF 架构开发方法(ADM)之需求管理阶段 .145企业架构研究总结(29) TOGAF 架构内容框架之概述及架构工作产品分类 1481. 企业架构工作产品分类 .150企业架构研究总结(30) TOGAF 架构内容框架之内容元模型

5、(上) 1512. 内容元模型(Content Metamodel) 151企业架构研究总结(31) TOGAF 架构内容框架之内容元模型(下) 156企业架构研究总结(32) TOGAF 架构内容框架之架构交付物 1623. 架构交付物(Architecture Deliverables) .162企业架构研究总结(33) TOGAF 架构内容框架之架构制品(上) 1794. 架构制品(Architectural Artifacts) 179企业架构研究总结(34) TOGAF 架构内容框架之架构制品(下) 192企业架构研究总结(35) TOGAF 架构内容框架之构建块(Building

6、Blocks).200企业架构研究总结(36) TOGAF 企业连续体和工具之企业连续体构成及架构划分 .2051 . 企业连续体的构成 2052. 架构划分 .211企业架构研究总结(37) TOGAF 企业连续体和工具之架构资源库及架构工具的选择 .2173. 架构资源库 .2174. 架构工具的选择 .222企业架构研究总结(38) TOGAF 架构能力框架之架构能力建设和架构治理 2261. 架构能力的建设 .2282. 架构治理 .2302.3 架构治理框架 233企业架构研究总结(39) TOGAF 架构能力框架之架构委员会和架构合规性 2373. 架构委员会 .2374. 架构合

7、规性 .241企业架构研究总结(40) TOGAF 架构能力框架之架构合同、成熟度模型和架构技能框架 .2595. 架构合同 .2596. 架构成熟度模型 .2617. 架构技能框架 .263企业架构研究总结(41) 企业架构与建模之 ArchiMate 的由来和详述(上) .2741. ArchiMate 的由来 2762. ArchiMate 建模详述 277企业架构研究总结(42) 企业架构与建模之 ArchiMate 详述(中) .301企业架构研究总结(43) 企业架构与建模之 ArchiMate 详述(下) .318企业架构研究总结(44) 企业架构与建模之 Archimate 视

8、图和视角 .3333. ArchiMate 的视角与视图 333企业架构研究总结(45) 企业架构与建模之使用 ArchiMate 进行分析(全系列完).3604. 使用 ArchiMate 进行分析 .360企业架构研究总结(1) 参考资料列表在 2010 年公司有幸参与到了某公司的企业架构建设项目之中,但对于一直从事于企业信息化建设的我们来说,由于一贯以来的努力都集中于企业的数据建模、管理和访问这些方面,像企业架构这样一门牵涉颇广的学问对我们来说还比较陌生,因而一条漫长的学习曲线是无法避免了。笔者有幸参与到这一项目之中,在漫长的学习过程中,笔者感触最深的就是资料的繁杂和中文资料的缺乏,虽然

9、公司同事参加了某知名机构的企业架构培训,但其所带回的资料和标准原文相比差距甚远,因而从那时起笔者就一直想着有朝一日将自己的研究所得进行忠于原标准的总结,希望能对感兴趣的人产生帮助。基于企业架构的复杂性,这篇总结必定篇幅不短,笔者将抽空持续添加,现在先将涉及到的参考资料罗列如下:1. 企业信息化总体架构赵捷,20112. 从 FEA 看中国电子政务的顶层设计姚乐3. 美国政府在社会信息化中的主导作用,袁传宽、侯炳辉4. 什么是 EA(企业架构)?,CIO 时代网5. TOGAF Version 9The Open Group, 20096. Enterprise Architecture at

10、Work2nd,Marc Lankhorst et al.,20097. Building an enterprise architecture practice: tools, tips, best practices, ready-to-use insights, Martin van den Berg, Marlies van Steenbergen,20078. Comparison of the Top Four Enterprise Architecture Methodologies, Roger Sessions,20079. Results of FY 2007 Federa

11、l Enterprise Architecture Assessment10. Overview of the Federal Enterprise Architecture,Blueprint Technologies Inc.,200411. A practical guide to Federal Enterprise Architecture,CIO Council, 200112. Federal Enterprise Architecture Framework,CIO Council,199913. Federal Enterprise Architectureand E-Gov

12、ernment: Issues forInformation Technology Management,Jeffrey W. Seifert,200814. FEA Practice Guidance,OMB ,200715. FEA Consolidated Reference Model Document Version 2.2,OMB ,200716. The Data Reference Model Version 2.0,OMB,200517. Federal Transition Framework Usage Guide,OMB ,200618. Enterprise Arch

13、itecture Assessment Framework v3.0,OMB,200819. ArchiMate 1.0 Specification,The Open Group,200920. ArchiMate 2.0 Specification,The Open Group,201221. A framework for information systems architecture,J.A.Zachman,198722. The Zachman Framework For Enterprise Architecture,J.A.Zachman ,200323. ISO/IEC 420

14、10: 2007,ISO,200724. ISO/IEC 42010: 2011,ISO,2011以上各项为笔者阅读过的主要资料,而这篇总结将以对这些资料的翻译、集成和总结为手段,以回本溯源为主旨,希望至少能够为感兴趣的人们提供一个集中参考,免去学习时四处收集材料之苦。企业架构研究总结(2) 问题的由来和基本概念自上世纪中后叶以来,随着信息技术的发展,各个工业、制造业领域,甚至是在人们的日常生活领域中,自动化以及效率提升等方面均得到了长足的发展,因此各个领域也纷纷加大了对信息技术的投资,从而形成了一个良性的循环。可以说,借助于信息技术的发展,人们的工作方式得以从传统的“蓝领式” 的工作方式逐步

15、转变为“ 白领式”的工作方式。随着时间的推移,企业中的信息系统越来越复杂,而且业务与信息系统的关系也日趋紧密,从而使得组织或企业中信息系统的优劣直接影响了其竞争力的强弱。随着这股以自动化和高效化为目标的潮流的演进,各个组织和企业对于信息系统的发展不约而同地走上了“技术驱动”的道路,不过 IT 技术在带来便利的同时也引起了业务和职责范围的扩大,这使得企业或组织中信息系统的结构也渐为复杂,之前靠纸笔或少量信息系统的方式已疲于应付,诸如信息孤岛之类的顽疾所带来的问题也逐渐凸显,而由于无法掌握全面的信息而产生的错误决策所带来的负面影响却在自动化和高效化的帮助下被进一步放大,IT 技术沦为双刃剑,而这正

16、是由于企业对信息技术发展的态度依然保持着自动化和高效率化的惯性思维,而并没有注意到境况已经发生了变化,他们在信息系统的发展过程中仅仅关注于眼前问题的解决,而忽视了他们自身的环境以及其已经具备的信息化资源,从而缺乏全局性的眼光来指导信息化系统的建设。甚至在一些业务部门与信息技术部门脱节相对严重的组织内部,企业的信息化建设与企业的核心业务的不平衡发展日渐严重:一方面企业的业务部门还在用较为落后的办公软件进行日常业务的维护和发展,另一方面企业的信息技术部门却仅仅因为信息技术的发展,不顾业务环境的真实境况而进行着信息系统的更新换代,而企业的决策者们却苦于没有足够的全局化的视角和手段在这两者之间进行决策

17、和协调。上面提出的问题,其根本原因是企业长期以来一直秉承“技术驱动”路线,而没有意识到环境已经发生变化,并且当前企业和组织中的信息系统的数量和复杂度与以前相比都不可同日而语,同时企业和组织的业务与信息系统之间的关系也越来越紧密。信息技术在将人们的工作方式变为“白领式”之后,其发展方式不应该是按照“技术驱动”的惯性前进,而应该使人们的工作更加“智能”。这里所说的“智能”,并不仅仅包括前述的“自动化”和“高效化”,其主旨是使人们工作于一个信息完备且条理清晰的工作环境之中,从而人们可以在给信息系统发布指令之前确保其决策是符合现实环境并经过深思熟虑的,且对指令发布后的结果以及影响均也能有一定程度的了解

18、和评估,也只有在这样的环境中,人们才能真正了解自己所要完成的工作、所处的工作环境以及他们之间的关系,从而重用企业中的各种信息资源并得出切实可行的决策。综合来说,随着信息化的发展,企业逐渐开始面对两个问题: 系统复杂度升高,并越来越难以进行管理。 业务和信息技术之间的关系虽然越来越紧密,但是却越来越不同步。这两个问题的本质可以概括为 “复杂”二字,因而这些问题的解决最终还是要落实到“复杂度管理 ”之上,而企业架构以及企业架构框架理论在本质上正是将企业或组织看作为复杂的客观对象,并对其在各个领域(战略决策、业务、数据、应用、技术和项目实施)中的复杂度进行有效管理,从而辅助企业或组织健康发展的学说。

19、由此可见,解决以上两个问题的方法就是以企业架构以及企业架构框架理论为指导,在企业或组织中建立完备并且准确的企业架构。要正确掌握企业架构相关理论与技术,首先要准确界定“企业”、“架构”、“企业架构”、“框架”、“企业架构框架”等概念。1. 什么是企业:企业架构中所指的企业并不是通常在商业环境中所定义的企业,按照TOGAF Version 9 的定义,企业是对一个组织的最高层次的描述,一般涵盖该组织的全部使命和功能。一个企业通常会跨越多个组织(The highest level (typically) of description of an organization and typically

20、covers all missions and functions. An enterprise will often span multiple organizations.)。由此可见,这里的“企业 ”是一个用于描述组织的抽象概念,强调的是组织的使命、功能与单一的基线,以及其组成。它既可以代表具体的一个公司、企业或政府,也可以是公司、企业或政府管辖之下的某个部门或部门集合,而具体的 “企业”的范围是什么,应该由驱动企业架构建立的需求范围来决定。2. 什么是架构:在 ISO/IEC 42010: 2007 中,架构被定义为:一个系统的基础组织,具体体现为其所包含的各个组件、组件之间以及与外部

21、环境之间的关系,以及用于指导架构的设计和演进的各项原则(The fundamental organization of a system embodied in its components,their relationships to each other,and to the environment, and the principles guiding its design and evolution)。 经过若干年的修订后,在 ISO/IEC 42010: 2011 中,这一关于架构的定义又被修改为:一个系统在其所处环境中所具备的各种基本概念和属性,具体体现为其所包含的各个元素、他们之

22、间的关系以及架构的设计和演进原则之中( fundamental concepts or properties of a system in its environment embodied in its elements,relationships,and in the principles of its design and evolution)。根据TOGAF Version 9所述,TOGAF 9 对于架构的定义涵盖了 ISO/IEC 42010: 2007 中对于架构定义的各个方面,并以此为基础做出了自己的解释:1. 架构是以指导某个系统的实施为目标的有关该系统的形式化描述,或在组件级

23、别为此系统的实现而制定的详细规划。(A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010: 2007).)2. 架构描述了组成系统的各个组件在系统中的布局、它们之间的相互关系以及用于对这些组件的设计和演进进行治理的各项原则及指南。(The structure of components, their inter-relationships, and the principle

24、s and guidelines governing their design and evolution overtime.)什么是架构描述:在 ISO/IEC 42010: 2007 中,架构描述被定义为:用于记录架构的产品集合(A collection of products to document an architecture)。而在 ISO/IEC 42010: 2011 中,这一定义被修订为:用于对架构进行表述的工作产品(Work product used to express an architecture)。什么是视角和视图:企业架构的主要用处是在企业或组织的各个干系人之间建

25、立起一座无障碍沟通的桥梁,因而“沟通”是企业架构的主要精神之一。这里所说的“沟通”,不单单指的是人与人之间的沟通,业务信息系统本身也可以被看作是“干系人”,只不过他们所需要的企业架构的描述信息在抽象程度上比自然人更加精细、其所使用的语义也更加规范罢了。即便不考虑各种干系人中的自然人与信息系统之间的不同,不同自然人之间由于其背景、责任的差异,其对于企业的关注点也具有很大的不同,而这些不同也造就了各种不同的视角(ViewPoint)。通过不同视角观察所得的关于企业的某一侧面形象就产生了此视角之下的一份视图(View)。一言以蔽之,视角用于描述从何处看,而视图则是看到的内容,视角是视图的模式,而视图

26、是视角的实例化结果。 在 ISO/IEC 42010: 2007 中,视角和视图分别定义如下:视角(Viewpoint):一份与构建和使用视图相关的各项规范的说明。借助于对视图的目标和受众所进行的明确,以及在视图的创建和分析过程中所采用的各项技术,视角还可作为各个视图的开发模式或模板(A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purpos

27、es and audience for a view and techniques for its creation and analysis)。视图(View):站在一组相互关联的关注点的角度之上对整个系统所进行的表述(A representation of a whole system from the perspective of a related set of concerns)。在 ISO/IEC 42010: 2011 中,视角和视图的名称发生了变化,在他们的名字之前分别增加了“架构”这一名词,而他们的定义也被修订为:架构视角(Architecture Viewpoint):(w

28、ork product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns)。架构视图(Architecture View):(work product expressing the architecture of a system from the pe rspective of specific system concerns)。 TOGAF 9 中的定义多来源于 ISO/IEC 42

29、010: 2007,但也有着其自身的特点。在TOGAF Version 9中,视角和视图被分别定义为:视角(Viewpoint):一个针对某视图所采用的观察角度的定义,是构建和使用某视图的规约的描述(通常采用一个适当的模式或模版的形式)。通俗的说,视图描述了所看到的内容;而视角则描述了站在何处进行观察一个能够决定你所能看到的事物的制高点或角度。(A denition of the perspective from which a view is taken. It is a specication of the conventions for constructing and using a

30、view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from the vantage point or perspective that determines what you see)。视图(View):针对一系列相互关联的关注点的表达。一个视图描述了采用某个视角后所看到的事物。架构视图可以通过模型来进行表述,从而为不同的干系人根据各自针对架构的关注点而分别提供描述。一个视图从本质上讲不一定以可视化或图形

31、化的方式进行展示。(The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature)。什么是干系人:在早期的 ISO

32、/IEC 42010: 2007 中并没有关于干系人(Stakeholder)这一概念的定义,但之后的 ISO/IEC 42010: 2011 却对此作出了这样的定义:对系统具有利益关系的个人、团队、组织或其种类( individual, team, organization, or classes thereof, having an interest in a system)。与此非常相似,在TOGAF Version 9中 The Open Group 将干系人定义为:对架构的产出物具有利益关系或关注点的个人、团队或组织(或其种类)。担当不同角色的不同的干系人通常具有不同的关注点(An

33、individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns)。什么是企业架构:由于企业架构并没有一个统一的定义,且每个企业和组织在建立各自的企业架构的过程中均会按照各自的理解去对企业架构进行定义,因而目前在业界存在多种对于企业架构的正式定义:(下面内

34、容源自什么是 EA(企业架构)? ,其中 EA 指代企业架构,EAF 指代企业架构框架) Zachman:EA 是构成组织的所有关键元素和关系的综合描述。企业架构框架( EAF)是一个描述 EA 方法的蓝图。Clinger Cohen 法案:EA 是一个集成的框架用于演进或维护存在的信息技术和引入新的信息技术来实现组织的战略目标和信息资源管理目标。OPEN GROUP:EA 是关于理解所有构成企业的不同企业元素,以及这些元素怎样相互关联。OMB(Office of Management and Budget,美国的管理和预算办公室):EA 是业务和管理流程和信息技术之间当前和将来关系的显式描述

35、和记录。MetaGroup:EA 是一个系统过程,它表达了企业的关键业务、信息、应用和技术战略以及它们对业务功能和流程的影响。关于信息技术怎样以及应该如何在企业内实施,EA 提供一个一致、整体的视角,以使它与业务和市场战略一致。Microsoft:EA 是对一个公司的核心业务流程和 IT 能力的组织逻辑,通过一组原理、政策和技术选择来获得,以实现公司运营模型的业务标准化和集成需求。IBM:EA 是记录企业内所有信息系统、它们的相互关系以及它们如何完成企业使命的蓝图。 综上所述,一个企业架构具有三个方面的含义:1. EA 是一个描述工具:EA 为组织中的所有干系人提供了一种描述手段(模板),使其

36、可以对组织中的业务、信息系统及其之间关系按照各自的视角进行描述。而且由于使用统一的语言进行描述,所有干系人之间也有了无障碍沟通的基础,而这也正是 EA 最重要的用处。2. EA 是一个知识库:EA 为组织中所有参与者所提供的针对企业架构各方面的描述提供了一个分类管理、便于访问的知识库和信息资源库。3. EA 是一个系统过程:为了使组织内信息技术与业务的需求、变化相适应,EA 提供了一套实施准则和管理策略。什么是企业架构框架:TOGAF Version 9中将框架(Framework)定义成一种内容或流程结构,用于对思维进行结构化组织,并在此过程中确保其一致性与完整性(A structure f

37、or content or process that can be used as a tool to structure thinking, ensuring consistency and completeness)。它描述了如何用一系列信息技术模块化地设计一个信息系统,并揭示了这些模块是如何结合在一起的。以此类推,对于企业这一现实存在的客观对象来说,企业架构就是以这一客观对象的实现和正确运行为目标的形式化描述,而企业架构框架则是用来构建企业架构的工具集和方法论。从某种意义上说,企业架构框架是企业架构的元模型,通过它可以帮助企业全面的且有条理地定义自己的企业架构。目前在业界存在多种企业架构

38、框架理论,例如 TOGAF,FEAF,DODAF,Zachman 等。他们的虽然都是用来指导企业架构的创建的理论,但是他们各自的侧重点又不尽相同。无论什么样的企业架构框架理论,其内容大体分为如下两个方面: 1. 创建企业架构的过程和方法。2. 企业架构的内容定义。在上述的业界中存在的各种企业架构框架理论中,他们之间最大的不同应该就是针对上述两点的不同侧重程度上。例如在 Zachman 体系中,并没有侧重于针对企业架构的创建过程和方法的论述,而主要着眼于企业架构内容的定义(实际上在 Zachman 的论文中还没有提及企业架构这个字眼,他当时是从企业信息系统的构建这个角度来阐述,但后来业界人士均将

39、这篇论文奉为企业架构框架的开山之作)。TOGAF 9 之前各个版本的论述重点则放在企业架构的创建过程和方法论之上,并没有加入关于企业架构内容方面的论述,直到 2009 年 TOGAF 9 问世,才在其中加入了比较完备的用于描述企业架构内容的内容框架(Content Framework)。什么是架构制品:Comparison of the Top Four Enterprise Architecture Methodologies将架构制品(Architectural artifact)定义为有助于架构描述的特定文档、报告、分析结果、模型或者其他的形式的事物(A specific documen

40、t, report, analysis, model, or other tangible that contributes to an architectural description)。不同的架构框架对于架构制品有着不同的定义,例如在 TOGAF 的内容框架中,架构制品的形式就被定为目录、矩阵和图形三种方式。但不论如何,架构制品都是用来描述架构的,是架构描述的具体体现形式,因而在有的企业架构框里理论里,比如 TOGAF,将视角(Viewpoint)与架构制品的具体定义联系起来,并把一份具体的架构制品内容当作架构的一个视图(View)。企业架构研究总结(3) 企业架构的发展历程 企业架构研

41、究总结(3) 企业架构的发展历程 学习任何一项理论,我认为最好的入门方式就是探究其历史根源以及发展进程,借此阐明该理论产生的真实原因,避免读者一开始陷入各种理论所共有的晦涩之漩涡而不能自拔,最终连为什么而学都理不清楚。学习企业架构和企业架构框架理论亦然。企业架构是自上个世纪七、八十年代发展起来的一套理论,在这几十年的发展过程中已经衍生出很多种不同的企业架构方面的理论体系,而且很多国际大型企业和政府已经在反复摸索中创建了符合各自特点的企业架构,并且关于如何建立企业架构的方法论,暨企业架构框架,以及相应的企业架构工具也已经在业界得到广泛的普及。企业架构的主要发展脉络可以被表现如下:与很多技术一样,

42、首先对这种关于信息化的整合、信息资源的共享以及资源的节约方面的技术发生兴趣,并且有足够的资源能够进行研究的组织总是军方。上个世纪七十年代中期,美国启动了 C4ISR 计划(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 。这一计划的目标并不是要建立什么企业架构或企业架构框架理论,而是要建立一个大而全的系统,能够将美国军事指挥当局作出重大战略决策以及战略部队的指挥员对其所属部队实施指挥控制、进行管理时所用的设备、器材、程序关联在一起,从而形成美国现代军队的神经中

43、枢。经过多场战争的磨砺与数度起伏,该系统日臻成熟,而构建如此一个跨越众多领域的庞杂系统的方法理论也渐为体系,终于在 2003 年伊拉克战争时期这一美国军方的“企业架构框架”也由最初专门服务于 C4ISR 系统的 C4ISR AF(C4ISR Architecture Framework)发展成为更加成熟的 DoDAF,即美国国防部信息化总体架构框架理论。这一过程漫长且充满波折,期间很多部门涉及其中,早在 1986 年美国国防信息系统局(US Defense Information Systems Agency/Center )开始开发 TAFIM (这也是 TOGAF 在 1995 年初版的基

44、础) ,到 1991 年 TAFIM 的第一版草稿完成,该参考模型目的是指导使用开放系统和商业市场的新技术开发美国国防部范围内的应用。1996 年 6 月美国国防部完成 TAFIM 项目,同时 DODAF 的第一版发布,当时的名字叫做 C4ISR AF,直到 2003 年 8 月正式的 DODAF v1.0 发布。当前最新版是 2009 年 3 月 28 日发布的 DODAF v2.0。在军方发展了这样的企业架构框架理论后,企业也紧跟了军方的脚步,开始了企业架构框架理论的研究。1987 年,还在 IBM 工作的 John Zachman 先生撰写了著名的论文信息架构框架 (A framewor

45、k for information systems architecture )。虽然这篇论文中并没有明确提出企业架构和企业架构框架的定义,但是他的确首次提出了“信息系统架构框架”这一概念,并认为使用一个逻辑的企业构造蓝图来定义和管理企业中各系统和组件的集成是非常有用的。在这篇论文中,Zachman 先生以在现实生活中建造房子为例,以及其精简的方式设计了一个信息系统的构成所需要的全部设计元素以及他们之间的关系。这篇论文在业界也被奉为企业架构框架理论的开山之作,Zachman 先生本人也被称为企业架构框架理论之父。Zachman 框架中并没有提出“企业架构”这一概念,而美国在 1996 年颁布的

46、 Clinger-Cohen 法案要求美国政府的 CIO 要负责开发、维护和帮助一个继承性的 IT 架构的实施,并称之为“ITA”,现在被解释为 IT 企业架构,也就是企业架构(EA)这一概念的由来,同时这一法案也揭开了 FEAF 和 FEA 研究的序幕。可以说企业架构最早是应用在一些美国的政府机构,而美国政府对企业架构的应用的推动也发挥了重要的作用。其实早在这个法案之前,美国政府中已经有多个部门开始研究和建设自己的企业架构。在把 Zachman 框架引入美国政府之后,首先是美国国家技术标准研究所在 1989 年发布 NIST 框架,而从此后联邦政府内部出现了许多框架,例如国防部的 DOD,以

47、及财政部的 DOT 等。但这种各自为战的状态并不符合企业架构的精神,因为联邦政府应作为一个整体创建起企业架构,于是在 1999 年 9 月,美国联邦 CIO 委员会出版了联邦企业架构框架(FEAF) ,用以为联邦政府机构提供一个关于架构的公共结构和实施指南,从而帮助联邦机构之间的公共业务流程、技术引入、信息流和系统投资的协调等方面。到了 2002 年 2 月,建设联邦企业架构的责任由 CIO 委员会转移到了 OMB(美国政府管理和预算办公室)手中,并由其建立了一个联邦企业架构程序管理办公室(FEA-PMO)来开发联邦企业架构(FEA) ,提出了五层参考模型的概念,用以在联邦机构程序内和跨机构程

48、序间,通过跨部门的分析来找到重复的投资,找到相互的差距,从而有助于在联邦政府范围内的协作、互操作和交互作用。该办公室于 2006 年推出了企业架构评估框架(EAAF,2008 年升级为 3.0) ,同年又推出了联邦过度框架(FTF) 。另外,围绕 FEA 参考模型的使用,OMB 还发布了一些通告,如用于预算的准备、提交与执行的通告 A-11 和用于联邦信息资源管理的 A-130。特别是 A-11 中的 Exhibit53 和 Exhibit300 详细说明了预算提交与 FEA 的匹配和连接关系,从而使 FEA 成为联邦政府在各机构中间发现差距、共享、合作和复用机会的重要工具(引自从 FEA 看

49、中国电子政务的顶层设计 ) 。其实美国政府在二十一世纪的开始几年中关于联邦企业框架的发展还是比较坎坷的,根据 2004 年 GAO(General Accounting Office)的统计,在受调查的 96 个部门中,仅有 20 个部门建立了有效的架构管理的基础,并且自 2001 年以来,有 22 个部门在成熟度上有提高,24 个部门水平有所下降,而 47 个部门维持不变。并且在 2005 年 1 月,GAO 强烈谴责了一些美国政府部门没有很好的贯彻和使用企业架构,这其中就包括美国联邦调查局、国防部、国土安全部,以及美国宇航局。不过随着时间的推移,FEA 的发展的确是向着良好的方向进行着。一份 2007 年的调查报告显示,在 24 个受评估的部门中已经有 19 个部门的评分达到了表示令人满意的“绿色”,而且相较以前,当年的用于进行企业架构评定的企业架构评估框架(EAAF )

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报