企业架构笔记（二）

简述几种主要的企业架构和企业架构框架理论。

注意：

• 由于企业架构的特性所致，其真实形态在不同的企业之间差异很大，即便是联邦企业架构也只是提供了五层参考模型而已，所以对于企业架构的总结无法逐一进行，而作为指导企业架构创建的方法论，亦即企业架构框架，由于其具备标准化的特性，将被作为本章内容的重点。
• 当然，即便企业架构框架具有其标准性的一面，也并不意味着每个企业都要削足适履，摒弃自己的真实需求和特色而强行照搬这些框架理论，所以在现实生活中企业应该按照各自的需要对企业架构框架进行适当的裁剪，甚至联合几种框架进行定制（例如TOGAF + Zachman），而也只有这样才能创建出适合于自己的企业架构。

一、企业架构框架之异同

先对这些企业架构框架理论进行对比，寻找共性和差别，对企业架构框架有整体性的认识。

1、企业架构框架的共性

（1）概述

目的：指导创建符合自己企业特点的企业架构，以及使用何种方式维护企业架构，使之与企业的发展相同步。

为了达到这一目标，各种企业架构框架基本上都在如下两个方面阐述创建企业架构的方法论：

• 创建和维护企业架构的过程：如何创建企业架构，以及如何确保企业架构正确的演进。
• 企业架构的内容描述：企业架构的内容如何分类，以及每一类都应该包含哪些内容。

基本上所有的企业架构框架都有关于创建企业架构过程的描述。在这些企业架构框架中，企业架构的生命周期都被描述成一个循环演进的过程，并且在演进过程中还需要施以适当的治理，从而保证每一次的演进都是在一种有序、受控的环境下进行。在企业架构的开发过程中，大多数框架理论还推荐通过使用企业架构成熟度模型来对企业架构的状态进行评估。

（2）企业架构演进过程

企业架构演进过程：基本上也采用类似的方法来逐渐完善企业架构

• 首先识别并定义此次循环的目标、范围以及相关干系人。
• 建立用于描述企业在各个领域（业务、数据、应用和技术）当前状态的基线架构。
• 使用相同的描述方式并依照此次循环的目标与范围定义出目标架构。
• 采用差距分析的方法，识别并归纳出当前架构与目标架构的区别。
• 按照差距分析的结果，在征得相关干系人同意的情况下开展迁移实施工作。

（3）层次划分

关于企业架构的内容，虽然不同的企业架构框架理论由于角度不同，但是他们对企业架构内容的层次划分大体上还是一致的，基本上都是从如下几个方面（或至少包含如下几个方面）对企业架构进行描述：

• 业务架构
• 数据架构
• 应用架构
• 技术架构

同时，虽然不同的企业架构框架对这些层次的具体内容有着不一样的描述，但是基本上所有的框架理论都是采用不同干系人的视角来对各层次具体内容进行归纳分类。

除了架构过程和内容方面的共性，几乎所有的架构框架理论都强调企业高层对于企业架构成功的重大意义。

• 架构推动方面：由于企业架构包含企业自业务到信息系统的各个方面，因而会涉及到企业中大多数的人员，如果没有企业高层的决心和驱动，协调这么多的人员本身就是个巨大的难题，从而直接影响到一个企业架构的成功与否。
• 企业发展战略方面：此外企业高层的思路往往就是企业发展的战略，亦即企业演进变化的源头，而将这些战略在企业各层中加以贯彻，通过信息技术加以实施正是企业架构的意义所在。

2、主流企业架构框架之对比

由于企业架构框架理论出现的历史背景和研发团体都不相同，因而企业架构框架理论的适用范围和侧重角度都有较大的差异。

注意：本章将根据 《Comparison of the Top Four Enterprise Architecture Methodologies》所述对四种主流的企业架构框架理论（Zachman，FEA，Gartner，TOGAF）进行比较。需要注意的是，由于这篇文章应该完成于2007年，因而TOGAF还没有发布第9版，因而文章中关于TOGAF重视架构过程而没有架构内容的描述的论点在当前看是不准确的，在后面的内容中笔者将给予修正。

（1）Zachman框架（第一个）

Zachman框架仅仅提供了关于企业架构内容的分类方法，而对于企业架构的创建过程却并没有相应的描述。

• 作为第一个被广泛承认的企业架构框架理论，Zachman首先提出了一种根据不同的干系人的视角来对信息系统的各个方面进行描述的方法，从而使得站在不同角度的干系人可以针对信息系统的建设使用相同的描述方式进行沟通，而这也对其后的各种企业架构框架理论的发展指明了方向。
• 在Zachman框架中，企业架构的内容被抽象成采用六种视角来观察的信息系统在六个方面的描述，并且Zachman认为当所有这些角度针对每个方面的描述都完备则一个企业架构的内容是完备的。

（2）FEA框架（最早的政府部门的框架）

FEA不仅在企业架构内容上由其自己的分类方式，而且关于架构过程也有着相当的描述。上述两者也是FEA的核心内容。

• FEA vs. FEAF：FEAF（联邦企业架构框架）是一个真正意义的企业架构框架理论，而FEA是以美国联邦政府为客观对象的企业架构的具体实例，但FEA中所抽象出来的各种参考模型和治理方法倒比方法论级别的FEAF更加容易让人接受，所以在很多情况下，FEA也被看作是一种企业架构框架理论。

企业架构内容分类方法：

• 由于FEA的具体内容相对明确，例如：其对服务的分类就包括健康服务、教育服务、自然资源服务以及国土安全服务等有着明显政府性行为的服务，不过FEA所采用的架构内容分类方法的确是值得借鉴的。
• 架构内容分类方法的实现：
  • 1. 总结业务线：首先采用服务的概念对企业部门的各种服务能力以业务线（Line-of-Business）为单位进行标识、组织和定义，并且将这些服务按照其使用的范围归纳为企业服务（Enterprise Service）和片段服务（Segment Service）两大类。通过这样的方式，联邦政府各部门的各条业务线得到了总结，而且原先功能上相互重复的服务也被识别了出来，从而有助于服务的重用。
  • 2. 分层描述：同时针对每条业务线或服务能力，FEA从业务、数据、应用和技术这几个方面进行详细的描述。所有这些层次的描述在FEA中通过五层参考模型的方式进行规范，从而为各个部门建立起一种统一的用于描述各自服务能力的方法。

企业架构的架构过程：各部门首先需要通过五层参考模型描述企业当前以及目标架构，根据差距分析找到现实和理想的差别，并且细化成各种实施项目。在为这些项目确立了投资和筹资战略后，对着这些项目进行实施和管理，从而促进企业的发展和企业架构的演进。

此外，联邦企业架构体系还包括了用以评估一个企业架构完整性、使用状况和使用效果的企业架构评估框架（EAAF），以及被OMB用来识别和管理各跨部门项目的联邦过渡框架（FTF）。

小结：由此可见，相对于Zachman，FEA既含有针对架构内容的分类法，又具备架构过程描述，甚至还包括了用于评估架构水平的方法，所以FEA更加具备一个企业架构框架的特性。但是从抽象度和通用性的角度来看，Zachman框架无疑是一种通用的架构建设方法论，而FEA则更倾向于一种基于具体实例的最佳实践。

（3）TOGAF

目的：为企业架构的创建提供一套标准的方法。TOGAF提出一套经过高度抽象的方法论，并且不依赖于任何一个具体的组织形式（例如，如果使用FEA来创建企业架构，和可能需要像美国政府那样建立OMB这样一个统一协调管理企业架构的组织，否则诸如FTF这样的框架将无从实施和管理），甚至他对自身提出的各个方法和内容分类法都没有硬性照搬的要求，也没有排斥其他任何架构框架理论，因而任何企业均可按照自身的情况对TOGAF进行裁剪或与其他框架进行混合，从而创建和维护符合自身情况的企业架构。

核心：架构开发方法（ADM：Architecture Development Method）——用来指导企业如何建立和维护其企业架构的一套流程化的架构开发步骤。

• 具体：ADM将架构过程看成一个循环迭代的过程，并且此迭代过程可以是分层级的，即企业可以使用一个小组负责整个企业架构的迭代开发，也可以由多个架构开发小组针对每一部份进行迭代开发，并最终归为一体。
• 在TOGAF中，ADM一共定义了十个步骤，除了“需求管理”这一步骤位于各个步骤中心作为其他各步骤的驱动和管理办法外，其余九个步骤还是有着先后关系的，即前面步骤的输出作为后面步骤的输入。

ADM创建和管理企业架构的思想：

• 识别和定义高层的策略、目标以及驱动力等。
• 创建针对架构的高层次的期望，亦即架构愿景。
• 细化架构愿景，在业务、数据、应用和技术这些层面进行详细描述，并针对采用相同方式描述的当前架构和目标架构进行差距分析。
• 将差距分析结果具体化为解决方案，进而形成一个个项目规划。
• 实施并管理这些架构项目。
• 在所有过程中监控内外部环境的变化，从而可以将变化快速反映到架构创建过程中。

分析：

• 与FEA相比，前两步相当于FEA五层参考模型中PRM（Performace Reference Model）的目标，而第三步的细化又于FEA中后面的四层参考模型不谋而合（当然，FEA五层参考模型并不是一个架构过程的概念，但是ADM的使用过程并不排斥对他们的使用，况且其核心思想是一致的）。至于后面的差距分析直到项目的规划、实施以及管理又与FEA的架构过程在思想上是一致的。而且，通过上述步骤我们可以看出，ADM采用了自上而下的原则通过逐步细化的方式将企业高层的策略过渡到详细的技术实施，从而构建涵盖所有干系人角度的企业架构。
• 需要注意的是，虽然ADM中的各大步骤在表面上有着先后依赖的关系，但是这种关系并不是硬性规定的，一个企业可以根据自己的需要调换这些步骤的顺序，甚至是跳过某些步骤，而这也是TOGAF所提倡的。此外，ADM除了定义这十大步骤，还详细定义了每大步骤所包含的各个小步骤、目标以及每大步骤的输入与输出。

TOGAF 9（2009）：The Open Group为TOGAF加入了内容框架（CF，Content Framework），从此企业架构不单单是一份仅仅关于企业架构过程的框架理论了。

• 在内容框架中，企业架构内容按照表现形式分为目录、矩阵和图形三种，并且根据ADM在各个阶段的目标定义了每个阶段需要完成的架构制品。
• 除此之外，内容框架还对ADM中各个步骤的输入、输出与这些架构制品的关系进行了详细描述。
• 内容架构中关于架构制品的定义构成了TOGAF下的架构内容元模型，但是这一元模型也只是一种参考性材料，TOGAF并不建议将其强搬至各个企业或组织的架构实践当中。为了达到这种灵活度，内容框架采用插件方式对内容元模型进行组织，即把一些关键并常用的架构制品当作核心内容，并将其推荐到架构实践过程当中，而把剩下的架构制品分别归纳到治理扩展、服务扩展、流程建模扩展、数据扩展、基础设施整合扩展以及动机扩展这几个分组之中。需要注意的是，TOGAF只是对架构内容进行了建议，即便是核心分组中的架构制品在实践中的具体内容也应按照企业自身的需求而进行定制。

由此可见，TOGAF相对于其他框架理论，具有更加标准、更加通用的特点，而且自从在TOGAF 9种增加了内容框架之后，此企业架构框架理论的完整度也大幅提高，也正因为如此，TOGAF发展至今日已经得到了最广泛的应用，堪称业界最流行的企业架构框架理论。

（4）Gartner

Gartner并不提供通常意义上的方法论，而是以其在企业架构建设领域中积累的大量实践经验为基础，对外提供关于企业架构方面的各种最佳实践（咨询服务 或 参考实例）。Gartner关于企业架构的建设也有着自己的理念和实际案例。

• Gartner将企业架构看作为一个动态的过程，而不仅仅是一个静态的名词。
• 在Gartner的观念中，企业架构建设的起点应该是对企业发展方向的明确，而不是仅仅对企业当前状态的描述，并且一个成功的企业架构应该能将业务拥有者、信息专家和技术实现者联系起来，并为他们提供一个统一的针对企业现状和发展方向的愿景。

3、四种框架的比较

上述四种企业架构框架各具特点，先将他们放在一起比较如下：

评测方面	含义	评分	评分	评分	评分
		Zachman	TOGAF	FEA	Gartner
分类法完整度 （Taxonomy completeness）	用以表明当前框架理论对各种架构制品划分的优劣程度。	4	3	2	1
过程完整度 （Process completeness）	用以表明当前框架理论在指导人们创建企业架构方面是否采用了渐入式的方式，且表现如何。	1	4	2	3
参考模型指南 （Reference model guidance）	用以表明当前框架理论在帮助人们创建一系列相关的参考模型中的作用。	1	3	4	1
实践指南 （Practice guidance）	用以表明当前框架理论在帮助人们将企业架构的精神融入到组织中，并为其创建一个珍视并使用企业架构的企业文化时的帮助程度。	1	2	2	4
成熟度模型 （Maturity model）	用以表明当前框架理论在评估企业使用企业架构的有效性和成熟度方面的帮助程度。	1	1	3	2
业务关注度 （Business focus）	用以表明当前框架理论是否着眼于使用技术来驱动业务价值。其中，业务价值被定义为减少成本或增加收入。	1	2	1	4
治理指南 （Governance guidance）	用以表明当前框架理论在理解和创建有效的企业架构治理模型方面的帮助程度。	1	2	3	3
划分指南 （Partitioning guidance）	用以表明当前框架理论在帮助人们对企业进行有效的自治性分区划分方面的帮助程度。此种分区划分对于复杂性管理来说是一个重要的方法。	1	2	4	3
视角目录 （Perspective catalog）	用以表明当前框架理论在指导人们设置架构资产目录方面的帮助程度。这些架构资产会在未来的活动中被重用。	1	2	4	2
厂商无关度 （Vendor neutrality）	用以表明当前框架理论与某个特定咨询组织的锁定程度。此方面评分越高表示与特定厂商的锁定程度越低。	2	4	3	1
信息易获取性 （Information availability）	用以表明与当前框架理论相关的免费或廉价信息的数量和质量。	2	4	2	1
价值获取效率 （Time to value）	用以表明从开始使用当前框架理论到创建具有高度业务价值的解决方案这一过程的效率。	1	3	1	4

在上面表格中评分量级从1至4，其意义分别定义如下：

• 在当前评测方面无所表现。
• 在当前评测方面有所表现，但是并不足够。
• 在当前评测方面有着可以接受的表现。
• 在当前评测方面有着很好的表现。

二、Zachman框架

1、架构简述

Zachman框架起源于John Zachman先生在1987年完成的那篇著名的信息系统架构论文（《A framework for information systems architecture》 ），并一直发展至今。在这篇论文中Zachman先生以修建房屋为例从两个维度将与信息系统架构设计相关的各种元素归纳到如下表格之中：

每行和列相交的单元格表示了各个干系人在各自视角上对于信息系统的某个方面的具体描述。

表格中的每一行代表了在信息系统构造过程中所涉及到的某干系人在描述信息系统时所采用的视角，包括：

• 范围/规划师（Planner）：包括整个信息系统描述所处的环境上下文、产生于内部与来源于外部的各种约束，以及其他视角下对信息系统的描述所需要考虑的相关构成部分的列表。
• 业务模型/拥有者（Owner）：有关最终产品的概念视图，反映了最终产品的使用特性，即用户准备如何对最终产品加以使用。具有此视角的干系人包括最终产品的客户或用户。
• 系统模型/设计师（Designer）：有关最终产品的逻辑视图，反映了最终产品的本质规律以及逻辑约束。具有此视角的干系人包括工程师、架构师以及能够将期望所得与现有的物理、技术上的实现联系起来的各种中间人。
• 技术模型/建造者（Builder）：反映了在产品构建过程中现有技术的物理约束。具有此视角的干系人包括制造工程师、总承包商以及具有生产最终产品所需的技术能力的组织或人员。
• 详细表述/分包者（Sub-Contractor）：关于为了达到生产目的而对复杂对象进行分解的详细描述，这些内容在从设计媒介到最终产品媒介的转换中起着非常重要的作用。例如，用于将技术模型中所阐述的技术约束与供应商为所提供的产品联系在一起的产品规格说明。
• 产品/运行中的企业（Functioning Enterprise）：在1987年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构描述的范畴的之内，不过为了使得架构Zachman框架对于架构的表述更加完备，这一行最终还是被加了进去。这一行的内容代表了最终产品，是架构在客观现实中的实例体现。例如，对信息系统架构来说，此行的内容就是最终产出的信息系统，同理，对于企业架构来说，这一行所代表的就是运行中的企业本身。简而言之，前面五行的内容是对于客观对象的描述，而这最后一行的内容就是客观对象本身了。

表格中的每一列代表了用于描述信息系统的某一个方面，这几个基本方面可以清晰的解释信息系统。这些方面包括：

• 数据（What，即什么内容）：用于表示客观对象的材料组成，即材料清单。对于企业来说，此部分内容就是组成事物模型（Thing Model，之所以将其称为组成事物模型而不是数据模型是因为由于不同的行代表了不同的视角，而仅在设计师所处的第三行才会关注真正信息化意义上的“数据模型”，因而在此才使用“组成事物”来对所有视角在此列中的描述对象进行指代）。
• 功能（How，即如何工作）：用于表示功能和转换行为。对于企业来说，这部分内容就是流程或功能模型等。
• 网络（Where，即何处）：用于表示各组成部件的坐落位置以及相互之间的联通关系。对于企业来说，这部分内容就是物流或网络模型等。
• 人（Who，即何人负责）：用于描述了何人应该做何事，例如用户手册和操作说明等。对于企业来说，这部分内容就是人力模型或工作流模型等。
• 时间（When，即什么时间）：用于描述事物发生的时间以及不同事物之间的相对时间关系，例如生命周期和时序图等。对于企业来说，这部分内容就是时间或动态模型等。
• 原因（Why，即为什么做）：用于表示最终结果和意义。对于企业来说，这部分内容就是动机模型等。

2、使用规则

• 不能为此框架增加新的行或列。在Zachman框架看来，框架中的六行视角以及六列描述方面构成了系统描述的最基本元语，即为了构建系统而对其架构所做的描述只要能够从六种视角出发，并能为每个视角在六个方面（什么内容（What）、如何工作（How）、何处（Where）、何人负责（Who）、何时（When）和为什么动机（Why））做出解答，那么此架构描述就是完备的，也由此足以成为系统的复杂度管理和变更管理的基础。
• 每一列中的内容都遵从某一通用模型。由于每一列都代表了所描述架构的某一个方面，因而处于同一列的各个描述在本质上应符合某种经过高度抽象的元模型：
  • “数据”列（What） 应遵从：事物——关系——事物。
  • “功能”列（How） 应遵从：流程——输入/输出——流程。
  • “网络”列（Where） 应遵从：节点——连接——节点。
  • “人”列（Who） 应遵从：人员——工作——人员。
  • “时间”列（When） 应遵从：事件——周期——时间。其中，“事件”指代某一时间点，而“周期”代表了一段时间区间。
  • “原因”列（Why） 应遵从：结果——方式——结果。其中，“结果”代表了目标状态，而“方式”则用于表示为了达成目标状态而采用的行为。
• 每个表格单元中的模型应该是其所在列采用的通用模型的具体特化。虽然在前面规则中提到过，每一列中的架构描述都遵循相同的模型，但是由于每一行所代表的视角对于描述所采用的术语、语法以及所受的约束各有不同，因而对于每个具体的单元格来说，其中的架构描述也应该是以该列所采用的通用元模型为基础并受其所在行视角约束的特化。
• 表格单元中架构描述的详细度与其所在的行无关。人们很容易有一种错觉，那就是在同一列中不同行里面架构描述的详细度有一个自上而下越来越详细的趋势，因为好像越是位于上面的行，其所代表的视角就越不关注于最终产品的实现细节，因而其中的架构描述也无需太高的详细度，反之越靠下方的行就需要更高的详细度。从实现的角度来说，这一担心不无道理，不过就架构描述的目标来说，这种详细度自上而下渐渐增高的趋势是有待商榷的。由于框架中的每一行代表了不同的视角，但这并不代表所有的视角都关注于最终产品在实现方面的问题，而正因为每个视角的关注点不同，所以仅从实现细节这个角度来说详细度的差异是有问题的。例如第一行的规划者关注于最终产品的所处的上下文环境，因而对在这一角度所进行的描述来说，其详细度应该根据具备这一视角的干系人的要求而定，而其下各行由于关注点不同，所以他们在描述的详细程度方面不具备可比性。由此我们可以发现，不同行的架构描述是相互独立但又互相联系的，他们之间是转换关系而不是演进关系，
• 不存在可以在不同的表格单元之间共享的元概念元素。由于表格中的每行或每列都是代表着某一视角或基本元语，因而由他们组成的各个表格单元中的架构描述也应该是独一无二的，所以不同表格单元之间的架构描述不应该出现共享元概念元素的情况。
• 不要在对角线方向上对不同的单元格进行直接联系，这样只会增加沟通障碍。每一个单元表格只与同行或者同列中位于其上和其下的单元表格之间有着直接关联，如此才能把沟通障碍和变更管理的难度最小化。
• 不要改变行或列的标头名称。在Zachman框架看来，由于本身逻辑框架已经完备，因而修改行或列的标头名称或含义会对整个逻辑框架产生不利的影响。这里需要注意的是，在图3所示的Zachman框架列表中，其行标头和列表头都含有上下两个名称，例如，第一行的标头就具有“范围”和“规划者”两个名称，而第一列也具有“数据”和“什么（What）”这两个称呼。这两种名称系列（用加粗大号字体标明的名称和采用小号斜体字体的名称）代表着Zachman框架的两种使用情境：
  • 通用情景：此种情景下，Zachman框架具有更高的通用性，例如房屋建筑、飞机等。其中各个标头将采用由小号斜体字体标明的名称。
  • 企业特定情景：此种情景下，Zachman框架的目标放诸“企业”这一特定的概念之上，而其中各个标头将采用由加粗大号字体标明的名称。
  • 需要注意的是，不论是上述哪种使用情境，按照Zachman框架的使用规则，这些标头名称都不能因为实际情况的不同而进行变更。
• Zachman框架逻辑具有通用性和迭代性。此框架虽然在企业架构领域名声斐然，不过这并不意味着他只能被应用于这一领域，实际上对于Zachman框架来说，他并不针对于某一具体事物，无论是有形的事物，诸如房屋、飞机等，亦或是抽象的概念实体，例如企业等，都可以是他描述的目标，因而在这一点上其具备普适性，而也正因为这一普适性，其每个单元格中的内容亦可以作为描述目标而被此框架无限迭代描述下去。

综上所述，Zachman框架认为一个关于客观事物（可以是房子或飞机这种有形实体，也可以是诸如企业这样的无形概念对象）的架构描述应包括两个维度，其中，一个维度表示了对架构进行描述所应采用的六种视角，而另一个维度则代表了架构描述所需要回答的六个方面的问题。这两个维度正交交叉，从而形成了36个交汇点，其中的每一个代表了架构描述的某一具体架构制品。举例来说，不论是规划师还是设计师在描述一个系统时，都需要描述系统的数据、功能等方面，但是对于某一个具体方面，例如数据，不同的角色有着不同的理解。对于业务拥有者来说，数据指的是诸如客户、产品这样的业务实体以及他们之间的关系，而对于执行系统设计的设计师来说，数据指代的就是完全信息化意义上的数据信息片段了。

3、意义

• 每个架构制品仅能存在于一个表格单元中。也就是说，每个架构制品的定义都必须是清晰的，如果某个架构制品可能出现于两个或两个以上的表单元中则表示此架构制品的内容是有问题的。
• 表单元和架构的完整性：仅当某一个角色针对系统某一方面提供了足够的架构制品才表示与之对应的表单元是完整的，而表中所有的表单元都被填充才表示一个架构是完整的。
• 针对表中每一列的内容必须是相互关联的。例如，在业务拥有者定义的数据必须在设计师的数据库设计中得到映射，并且每个数据库中的数据的定义都可以回溯到某个业务中的数据定义。

4、其他

Zachman框架从本质上来说是对企业架构描述的一种分类法，其对于如何解决企业信息化发展所面临的问题（系统复杂度管理、业务与信息技术的不协调发展）能够提供如下的帮助：

• 给出了企业架构内容的描述和分类法，从而可以复杂的系统进行分解描述。
• 确保每个干系人的每一个关注点被照顾到。
• 改进每个架构制品使其更加契合目标受众的关注点。
• 确保业务需求可以被映射到技术实现之上，同时每个技术实现也可以被回溯到业务需求之上。
• 加强业务人员与信息技术人员的沟通和交流，减免以前因缺乏沟通而导致的无谓的内耗。

尽管如此，有些学者并不将Zachman看作为一个框架（例如，《Comparison of the Top Four Enterprise Architecture Methodologies》 的作者），而仅仅把其当成企业架构描述的一个内容分类法。这种看法是有其根据的，就其原因还是因为此框架在如下方面无法给予解答：

• 虽然此框架描述了企业架构应该包含哪些内容，但是并没有给出如何创建这些内容，亦即缺乏一种关于架构开发过程的描述。
• 在此框架之下企业架构内容就像一张静态画面一样，而企业架构是应该随着企业的发展而变化的，因而如何在不断地演进过程中对企业架构进行治理也是他缺乏的内容之一。
• 此框架并没有提供一个判别标准，因而无法了解按照此种方式组织的企业架构是否是一个好的架构，也就是说该框架缺乏成熟度框架。