1.3 企业架构理论

企业架构的设计和实现要基于架构理论的不断发展和完善。不同的企业架构理论，内容也不尽相同。美国架构规划专家扎克曼在1987年创建了第一个企业架构的框架理论，国际上通称为Zachman架构框架（Zachman Framework，扎克曼架构框架）。Zachman架构框架后来发展成为企业架构的一个经典框架，扎克曼本人也被誉为EA之父。之后，EA的框架和方法论不断地被提出。

架构框架是一个或一套基础结构，用来开发大范围的不同架构。它描述一个用构建块的集合来设计企业目标状态的方法，并显示这些构建块如何搭配在一起。它应该包含一套工具并提供共同词汇，也应该包含所提议标准的清单以及符合标准的可以实现构建块的产品。构建块可以是架构元模型实体的目录清单、矩阵及图表、功能规格、应用模块、软件和硬件产品及其组合。企业架构框架并不是企业架构本身，但是它可以告诉我们如何组织和描述企业架构。企业架构框架至少包含以下内容。

● 识别描绘企业架构所需要的信息类型。

● 将信息类型组织成逻辑结构。

● 描述信息类型之间的关系。

企业架构信息的分类可以方便架构的建立和信息的整合，企业架构框架还可以识别出产品类型（模型）。这种类型（模型）用来描述企业架构和演示如何描绘不同企业架构信息类型（如使命需要、商业过程、数据和IT能力等）之间的联系，它可以帮助组织运行企业架构。使用预先决定的企业架构产品描述可以加速体系结构的发展过程。在不同的但相关的企业架构中使用同样的框架和产品类型可以增加企业架构之间的可比性，便于在不同企业架构中的工作者进行交流。

根据企业架构所需要的信息内容，企业架构框架至少要能组织信息类型并描述商业过程、数据、IT系统使命和IT基础设施之间的关系。企业架构框架还必须处理标准的安全问题，将企业架构与企业战略和目标关联起来，使基础架构最终变成目标架构。因为企业架构将面对许多不同的使用者，所以企业架构框架还必须针对不同使用者来说明哪些信息最适用的问题。一些框架还处理存储需求或者提供对过程、管理或结构管理的指导。大部分框架没有描述系统模型建立的方法原则、分析性的办法或工具。为确保用统一的方法和格式说明企业架构，许多行业和政府组织采用“架构框架”方法来统一用于描述架构各方面所用的“语言”。这些架构框架通常与专业领域有关，例如国防工业用的美国国防部架构框架DoDAF以及相关的框架，再如电信行业的eTOM模型为电信营运商制定企业业务架构提供了参照。企业架构框架包含了从企业战略层次到IT技术的战略层次，再到最基本的技术元素的全部内容。目前影响较大、使用比较广泛的企业架构框架和方法论主要有Zachman、TOGAF、FEA和DoDAF。

1.3.1 Zachman架构框架

全球第一个企业架构框架理论是由约翰·扎克曼于1987年创立的，即Zachman架构框架理论，扎克曼的论文《信息系统架构框架》至今仍被业界认为是企业架构设计方面最权威的理论，是其他企业架构框架的源泉。扎克曼的崇高声誉不仅仅是由于他在架构框架上的工作，还由于他早期对于IT系统规划方面的贡献。系统规划在20世纪70年代是IBM广泛使用的信息规划的方法论。作为一个强化的和系统的理论，信息规划给IBM的核心领导层、规划和计划部门、技术部门提供了一个强大和完善的工具。20世纪70年代以来，扎克曼先生致力于信息系统的战略规划、计划和企业架构的推广与应用工作。他撰写了许多相关书籍和文章，还一直在全球范围内为企业和政府提供教育和咨询，促进和完善了企业的战略规划和决策行动，带动了企业架构在全球的发展。

Zachman架构框架理论最具代表性的是通过6列5行共30个元素表示的矩阵表格，如表1-2所示，以最简便的形式刻画了构成所有内在关系的设计元素以及这些元素在设计中的功能和作用，它构成了一个完整的理论和模型。扎克曼将每部分都看成独立的变量，这是关系型数据库中的标准思维；数据必须与功能、网络位置独立区分，以保持思维的灵活性和清晰性。

Zachman架构框架共分为5个层次，以5行来描述。每一行代表不同类型的项目涉众的看法和观点，它明确了企业架构工作的流程和流程承担者。

第1行是企业的规划和管理人员范畴，它定义组织的方向和目的以及架构工作的边界。明确系统所支持的业务范围，规划系统在功能、性能和成本等方面的整体要求。

第2行是系统的拥有者（或称所有者）范畴，它用业务术语来定义组织的本质，包括它的结构、过程、组织。明确业务实体和他们之间的关系，以及业务流程与规则。

第3行是系统设计者和项目架构师范畴，它需要用比上一行更加严格的术语来决定和定义系统提供的功能和数据模型。也就是要把这个模型提高到一个更高的细节程度上。在Zachman架构框架的最初版本中，这行被称为信息系统设计师的观点。

第4行是系统的构建者和实施方范畴，它定义应该采用怎样的技术和手段来满足前面各行所定义的需求。在这个层次，需要考虑系统开发的工具、技术方案和平台等。

第5行是系统的开发者和承包方范畴，它定义详细设计，考虑实现语言、数据库存储和中间件的使用。包括定义具体的数据库、系统模块、业务规则等，能够分配工作给开发者具体执行。

Zachman架构框架认为无论从哪个层次来看，企业信息化的建设都应该从数据（what）、功能（how）、网络（where）、人员（who）、时间（when）和动机（why）等6个方面来综合考虑，也就是所谓的5W1H方法，在Zachman架构框架中以6列表示。

前3列是抽象产品，即什么内容，着重点是组织之内的重要的实体、对象、组件，以及它们之间的关系；流程是如何工作的，着重点是如何来支持组织和它的客户；组件在何处，着重点是组织活动的地理分布。从系统的角度来看就是数据、功能和网络。在最初的Zachman架构框架中，只有这3列抽象的产品，随着架构理论的不断发展和成熟，企业架构的实施和IT治理不可避免地包括在了企业架构框架之中。这就是Zachman架构框架中的后3列——“人员、时间、动机”。

在后3列中，人员描述谁做什么，着重点是谁参与了组织的业务；时间描述事件何时发生，着重点是事件发生的时间及其对组织有多大作用和影响；动机描述选择该事件的原因，着重点是把业务目标、战略和限制转化为具体的实现。

相对于前3列抽象产品，后3列更抽象、更不容易建模和仿真。关于Zachman架构框架理论，有以下3个方面需要认真理解并引起注意。

● 在每一列中，模型被演化或者转变来反映每行中涉众的观点。

● 在每一行中，模型应当是彼此之间互相一致的。

● Zachman架构框架并不是为架构定义一个过程，它是定义了架构应该包含的观点。Zachman架构框架仅仅是一个模板，所空缺部分必须由每个组织根据所需要的具体过程来填充。如果这些过程不存在，使用Zachman架构框架将有助于识别这些架构中的空白。

Zachman架构框架的主要优势是明确地展示了企业架构需要解释的许多观点，不管组织或企业是否决定采用Zachman架构框架，它都可以提醒你在架构中所需要考虑的问题；Zachman架构框架还明确地指出架构除了有架构师和开发者外，还有其他的涉众，这就意味着需要让所有的涉众都参与到架构设计中去，以确保满足他们的需求，而且理想上来说，应当尽量促使涉众活跃的参与架构实践。

尽管Zachman架构框架广泛地被企业和政府接受，但它存在以下几个潜在的问题，也引起了人们的关注。

● Zachman架构框架可能会导致一种文档繁杂。表1-2中有30个单元格，每一个单元格都需要一个或多个工件（artifact）来作为支持，这意味着文档的编写和管理一定非常繁杂。因此每个层次对象需要站在全局的高度，明确什么信息是实际上需要的，什么是可有可无的。换句话说，只有建立和维护文档的价值超过它的开销才有意义。

● Zachman架构框架可能过于偏向于方法学。使用Zachman架构框架来提倡所偏好的工作方式，或者使用它来改善现有方法似乎是一个很好的解决方案，但是如果不能选择反映当前组织文化、业务环境、技术环境以及参与人员的技能的工件的话，它可能会起负面作用。

● Zachman架构框架可能偏重过程。Zachman架构框架需要定义一套严谨的过程来支持它的必要性，为了维护在表格中那30个元素的可跟踪性，需要开发和维护一套详细的轨迹矩阵或者元数据的数据库，这些活动无疑会增加开销并影响到项目的进度。

● Zachman架构框架并没有被开发领域广为接受。虽然其在IT架构领域中的普及性正在增长，但是似乎它还没有设法让自己进入到主流开发领域中去。

● Zachman架构框架提倡的是自顶向下的开发方法。在人们一开始接触它的时候，大家倾向地认为这意味着要从第1行开始，然后进行第2行等，然而实际情形并不一定非要这样。一个自顶向下的开发方法在有些情况下是好的，而有些时候自底向上的方法可能会更好，在其他时候从中间向外的方法又更合适，所以可以根据实际情况选择最合适的单元格作为起点，然后从那里开始进行。

Zachman架构框架从5个层次和6个方面定义了企业架构和需求。将30个元素有机结合，就可以建立起企业业务运营中实际运行的系统。Zachman架构框架主要还是解决系统建设问题，而不涉及业务和流程的设计。

1.3.2 TOGAF架构框架

TOGAF架构框架是由欧洲共同体的IT协会The Open Group开发的一个企业架构框架理论。在这个组织之下的企业架构分会有欧洲和北美很多的专业组织，如VISA、NASA、计算机协会、英国国防部、美国国防部及NATO等研究机构和政府部门，还有许多国际知名企业，如NEC、Motorola、波音、惠普、日立等。以The Open Group协会会员国为基础，从1993年开始制定系统架构的标准，1995年开始开发了一个称为“X/Open Architecture Framework v1.0”的企业架构框架理论模型。1996年推出了TOGAFv2.0版本，1997年推出了TOGAFv3.0版本，一直到2009年推出TOGAFv9.0版本。TOGAFv9.0版本是在开放组织成员的共识下发展起来的，其方法可以用于其他框架或其余TOGAF版本中推荐的信息。由于TOGAF是一个跨行业的、开放的免费架构框架，所以在全球得到了广泛使用。

TOGAF架构框架能为企业各级领导和员工描绘出一个未来企业信息化中业务、信息、应用和技术互动的蓝图。

1．TOGAF架构框架是沟通业务与信息技术间的桥梁

在企业信息化建设中，业务部门与信息服务部门之间、业务主管与信息主管之间、业务与信息技术之间的鸿沟是实现信息化目标的最大障碍之一。彼此的信息不对称是形成这种差距的主要原因：一方面，信息技术人员可能无法了解业务的真实意图；另一方面，业务人员也体会不到信息技术的真正作用。TOGAF架构框架能够搭起业务与信息技术沟通的桥梁，它在同一个平台上，用双方都能够理解的语言，描述出业务与信息技术之间的关联。

2．TOGAF架构框架是适应企业业务变革的方向盘

企业信息化是一个渐进的过程，在信息化的过程中也伴随着企业战略、管理和业务变革的过程。当前企业信息系统如何适应企业的变革成为企业CIO们思索的一个突出问题。以不变应万变是适应变化的一个基本战略，TOGAF架构框架所描绘出的蓝图容纳了各种业务与技术标准，是企业CIO们掌握信息化方向、适应业务战略变革的方向盘，能从根本上解决企业信息化中遇到的信息孤岛、集成和互操作等问题。

3．TOGAF架构框架的组成：实现业务、信息、应用和技术的协同

TOGAF架构框架是一个多视图的体系结构，它由企业的业务架构、信息架构、应用架构和技术架构共同构成。

（1）企业业务架构：贯彻企业业务战略。企业业务架构描述了企业各业务之间相互作用的关系结构。企业的业务构架以企业的业务战略为顶点，以企业各主营业务为主线，以企业各辅助业务为支撑，以人流、物流、资金流、信息流等联络各业务线，构成贯彻企业业务战略的企业基本业务运作模式。

（2）企业信息架构：建立企业信息模型。企业信息架构是将企业业务实体抽象成为信息对象，将企业的业务运作模式抽象成为信息对象的属性和方法，建立面向对象的企业信息模型。企业信息架构实现从业务模式向信息模型的转变、业务需求向信息功能的映射、企业基础数据向企业信息的抽象。

（3）企业应用架构：实现企业信息流动。企业应用结构是以企业信息架构为基础，建立支撑企业业务运行的各个业务系统，通过应用系统的集成运行，实现企业信息自动化流动，代替手工的信息流动方式，提高企业业务的运作效率，降低运作的成本。

（4）企业技术架构：保障企业应用执行。企业技术架构是实现企业应用架构的底层技术基础结构，通过软件平台技术、硬件技术、网络技术、信息安全技术间的相互作用，支撑企业应用的运转。

4．TOGAF架构框架方法论：搭建灵活的TOGAF架构框架

TOGAF架构框架的建立遵循科学的方法论：横向，从企业业务战略导入，实现企业业务架构、信息架构、应用架构和技术架构的渐进演化；纵向，每个架构的建立，按照“计划—评价—执行”的循环方法，逐步完善。这一过程对专业性的要求很高，需要有企业业务、管理、信息、技术等方面经验的专门人才的参与，目前IT管理咨询公司所提供的IT战略咨询或IT规划咨询服务对建立TOGAF架构框架具有重要作用。

TOGAF架构框架的运转也需要一定的机制来保证，基本思想是按照“运行—监督—反馈”的过程，建立配套的组织、资源、方法和工具来保证TOGAF架构框架的运转。

评价TOGAF架构框架方法论的基本准则是：建立起的TOGAF架构框架在运行中是否能够真正满足企业业务战略发展的需要。

5．TOGAF架构框架的最佳实践：实施成功的企业信息化

（1）成功实施TOGAF架构框架的最佳投资准备：价值和风险的平衡。成功实施TOGAF架构框架需要准确评估企业IT投资的价值和风险，在价值与风险间找到平衡点。经验证的企业信息化投资的基本准则是：TOGAF架构框架的投资应当占整个企业信息化投资的20%，而且把它当作一个长期战略性投资来考虑。因为，事实证明20%的投资已经决定了企业信息化建设80%的价值，企业信息化的风险也因此而降低。

（2）成功实施TOGAF架构框架的最佳组织准备：业务和IT的互动。成功实施TOGAF架构框架需要业务部门和IT部门重新审视自己的组织定位，真正提升IT组织在企业中的重要性，使IT组织成为企业业务战略制定、业务运作模式规划的主动参与者。

（3）成功实施TOGAF架构框架的最佳资源准备：机会和能力的匹配。成功实施TOGAF架构框架必须从战略的角度对企业进行SWOT分析，考虑企业在环境中的机会和威胁，考虑企业的特点和能力与其机会的匹配程度，从而正确评价在现有资源状况下TOGAF架构框架建立的广度和深度，保证企业信息化目标的实现。

1.3.3 FEA框架

1996年，美国国会通过了《信息技术管理改革法案》，即《克林格·科恩法案》。该法案的主要内容包括命令各联邦机构开发和维护信息技术架构（ITA）来最大化政府内部信息技术投资的收益；改变了联邦机构在IT采购上的角色和职责，提升了OMB（美国管理和预算办公室）的职责，由OMB进行集中统一管理；要求每个联邦机构必须任命一个CIO, CIO的一个重要职责就是开发、维护和辅助实施一个完善的、集成的信息技术架构。同年，美国13011号总统令建立了CIO理事会。从1998年开始，CIO理事会根据《克林格·科恩法案》的要求，着手开发联邦企业架构框架（FEAF）。框架是为了提供一个可支撑的机制来识别、开发和记录高优先级领域的架构描述，这些领域建立在跨组织边界的共同业务域和设计之上。FEAF于1999年正式发布，主要内容是八大构件，即架构驱动力、战略方向、当前架构、目标架构、过渡流程、架构分块、架构模型和标准。FEAF还展现了从4个不同层级上看到的细节程度。FEAF的目的是为了推动联邦政府各机构和其他政府实体之间共同联邦流程的共享开发、互操作以及信息共享。

2001年，CIO理事会在实施指南中发布了架构开发方法论。该架构开发方法论包括八大步骤：获取管理层的认可和支持、建立管理机构和控制、定义一个架构流程和方法、开发基线EA、开发目标EA、开发顺序计划、使用EA和维护EA。2001年的架构开发方法没有说明EA制品（artifact）以及如何做出它们。与此同时，国防部推出了C4ISR（DoDAF前身）。DoDAF有架构制品的详细内容，FEAF开始转向使用DoDAF模型。直到2002年，又开始转向参考该模型的方法论。

2002年2月，OMB成立了FEA项目管理办公室（FEA-PMO），开始着手开发一个综合的、业务驱动的政府蓝图，即联邦企业架构（FEA）。FEA是为了帮助政府管理层制定有效的决策，并允许他们在跨机构之间增加合作以及资源共享的机会。FEA由一套相互关联的参考模型组成，用来进行跨机构业务分析，识别机构内部或跨机构的重复投资、差距和机会。这些参考模型共同组成一个框架，用共同的、一致的方式来描述FEA的重要元素，如图1-2所示。

在FEA参考模型推出之后，FEA-PMO又陆续推出了EA评估框架（EAAF）、联邦过渡框架（FTF）和一系列实施指南。EAAF主要用于OMB对各联邦机构的EA进行评估。评估的内容包括EA的完整性、EA的使用状况以及使用EA的效果。FTF主要用于OMB对跨机构发起项目的识别和管理。另外，围绕FEA参考模型的使用，OMB还发布了一些通告，如用于预算的准备、提交与执行的通告A-11和用于联邦信息资源管理的A-130。特别是A-11中的Exhibit53和Exhibit300详细说明了预算提交与FEA的匹配和连接关系，从而使FEA成为联邦政府在各机构中间发现差距、共享、合作和复用机会的重要工具。

FEA是美国政府在长期的电子政务实践中探索和总结出来的一个顶层架构或顶层设计。FEA的核心思想是通过一个顶层架构来进行跨机构的IT投资立项分析和IT项目管理。特别是FEA实施指南中的分块架构方法论，是一个将整体问题科学合理地分割成一个个有机联系的分块，从而将复杂问题简单化的有效方法。FEA的这些核心思想和方法论并没有国体和政体的本质特征，它是关于一个复杂组织的IT投资立项和IT项目管理的最佳实践，值得各国政府和集团型企业借鉴学习。就好比平衡计分卡，世界各国的政府和企业都可以应用到其管理实践中去。

1.3.4 DoDAF框架

2008年12月24日，美国防部副首席信息官发布了《国防部体系结构框架2.0版草案》，开始征询意见。这是自2007年4月23日颁布《国防部体系结构框架1.5版》的过渡版本之后，首次推出2.0版。该《草案》定于2008年12月29日至2009年1月22日交由首席信息官执行委员会、国防部体系结构和标准委员会以及相关单位评审。2009年1月23日至2月5日对评审意见进行汇总，2009年2月6日至2月26日最后定稿，呈交国防部首席信息官批准。国防部体系结构2.0版是以数据为中心，引进了国防部体系结构元模型（Meta-model）的概念，元模型由概念数据模型（Conceptual Data Model）、逻辑数据模型（Logical Data Model）和物理交换规范（Physical Exchange Specification）组成，是构成国防部体系结构框架整体的重要组成部分。元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型（Core Architecture Data Model）。2.0版的国防部体系结构框架分为三卷。第一卷的主要内容包括12部分：简介、体系结构的适用性、国防部体系结构回顾、企业体系结构、客户需求、体系结构规划、方法论、体系结构表示方法、国防部体系结构元模型、基于体系结构的分析、国防部体系结构框架的配置管理以及与其他框架的关系。第二卷的主要内容包括简介、国防部体系结构框架元模型、《国防部体系结构框架》2.0版视图。第二卷的支持文件的主要内容包括国防部体系结构框架的模型开发程序、国防部体系结构框架的产品开发问卷分析报告、《国防部体系结构框架》2.0版元模型数据词典。第三卷的主要内容包括物理交换规范。在2.0版中，共计有49个视图，这些视图并非都是必不可少的，可根据需要来确定哪些视图是必需的。

全局视图（All Viewpoint）体系结构描述中许多跨域性（overarching）方面与所有视图有关。该视图模型提供了对整个体系结构描述都有关的信息，如体系结构描述的范围和背景，范围包括问题域和时间跨度。体系结构描述存在的背景由组成背景的相关条件构成，这些条件包括条令、战术、技术、规程；相关的目标和设想的表述；作战思想（CONOPS）；假设和环境应满足的前提条件。

功能视图（The Capability Viewpoint）采集执行特定的一系列动作而达到企业的目标，或者在特定标准和条件下通过执行一系列任务而获得期望效果的能力。它为体系结构描述中所描述的功能提供战略级背景和相应的高层范围，比在作战思想图中定义的基于想定的范围更加概略性。这个模型是高层模型，利用术语描述，使得决策者更加容易理解，可以用于功能进化战略级的交流。

数据和信息视图（The Data and Information Viewpoint）采集业务信息需求和结构化的业务流程规则，描述了与信息交换有关的信息，如属性、特征和相互关系。在第二卷中对数据进行了完整的描述。在适当的情况下，该模型需要采集的数据应该由CIO考虑。

作战视图（The Operational Viewpoint）采集了组织、任务或执行的活动，以及在完成任务工程中需要交换的信息。该视图记录了交换的信息类型、频度，信息交换所支持的任务和活动以及信息交换本身的一些性质。

项目视图（The Project Viewpoint）说明了项目计划如何组合成具有前后承接关系的投资组合计划。该视图提供了一种描述多个项目间组织关系的方法，每个项目负责交付单个的系统或功能。

服务视图（The Services Viewpoint）说明了系统、服务以及支持作战活动的功能性的组合关系。DoD的进程包括作战、业务、智能和基础架构功能。该视图中的功能和服务资源以及组件可以与OV中的体系结构数据关联。这些系统功能或服务资源支持了作战活动，方便了信息交换。

标准视图（The Standards Viewpoint）是控制系统各部分或元素间组合、交互和互依赖性的规则的最小集合。其目标是确保系统能够满足特定的一系列作战需求。该视图提供了技术系统实现指导，基于此指导可以形成工程规范，建立通用模块，开发产品线。它包括技术标准、执行惯例、标准选项、规则和标准。

系统视图（The Systems Viewpoint）采集了关于自动化系统、互连通性和系统功能方面的信息。不久的将来，随着DoD将重点转移到面向服务的环境和云计算，该视图会消失。

DoDAF通过指导如何描述系统架构（使其能够被评估和理解）及根据同一指南开发的其他体系结构描述来说明该需求。运作决策制定者可以利用顺应DoDAF的报告来比较备选系统的架构，并管理现有系统的演进。

符合报告由模型视图组成，这些模型视图足够详细地描述了能够管理DoD的系统架构，并且使CBO（Congressional Budget Office）为了采购目的对系统进行评估。想要与DoD做生意的公司要在它们计划系统时，遵从DoDAF的一部分或全部。