企业架构（五）——联邦企业架构（FEA）实施指南

• 在接管了FEA的开发之后，OMB先后制定了诸如参考模型、联邦过渡框架以及企业架构评估框架等标准用于为FEA的开发提供帮助。
• 但是美国联邦政府创建的FEA的初衷是为了提高政府整体的信息资源的利用率和效能，并改善政府针对信息技术的投资水平，因而如何开发和应用FEA并使其为上述目标提供价值才是目标所在。
• 为了达到这一目标，OMB于2007年底发表了《FEA Practice Guidance》用以指导如何开发和利用联邦企业架构，从而实现联邦政府性能的改善。
• 企业架构实践领域：通过将部门的战略目标、部门的投资以及需要达到的可测量的性能改善结合起来，企业架构实践领域可以最大限度将部门的资源、IT投资和系统开发活动的效能发挥出来，从而实现部门的性能目标。
• 企业架构实践领域与其他领域结合：企业架构实践领域只是部门所涉及的各项实践领域中的一环，为了改善部门性能，各部门需要将企业架构实践领域与其他各个实践领域进行结合并加以应用，例如战略规划、资金规划和投资控制以及项目管理等。

所有这些实践领域都需要在各部门对其效能进行改善的过程中进行适时并适当地使用，而这一改善过程在联邦企业架构实施指南中被称为 “效能改善生命周期”（Performance Improvement Lifecycle）。本节的主要内容就是以此效能改善生命周期为背景，详细介绍企业架构是如何在这个背景下被开发和使用的。

• 三个阶段：架构阶段、投资阶段和实施阶段，而且每个阶段都包含着若干紧密结合的流程。通过这些流程的结合运行，能够为部门带来效能改善的各种需求得以被实现。
• 驱动效能改善生命周期行进的原动力或需求：两方面
  • 自上而下的驱动力，即部门为了效能改善而主动制定的战略目标。
  • 自下而上的需求，即在实际运行中产生的诸如系统改进等方面的需求。
  • 区别与联系：主要区别是其产生的源头，而一般来讲“自下而上的需求”往往也会变成“自上而下的驱动力”产生的直接原因。

• 企业架构实践领域与效能改善生命周期：效能改善生命周期的演进过程本身是企业架构逐步细化、专门化的演进过程。具体来讲，企业架构起初以部门级的信息整合体的形态出现，经过细化而转变为面向各个具体任务领域的片段架构，并最终体现为包含了各种实现部门目标的方案和项目的解决方案架构。
• 企业架构实践领域作用：不仅为整个效能改善生命周期提供部门级的可共享的信息资源、规范和标准，而且企业架构所涉及的框架方法也是此周期能够顺利进行的重要工具。

• 1、企业架构的关注点基本在对于通用或共享资产（战略目标、业务流程、投资、数据、系统或技术等）的识别和组织之上。
  • 企业架构往往是以战略目标为原动力的，它有助于一个部门识别其资源的分配与其任务和战略目标是否相适合。
  • 从投资的角度来看，企业架构一般被用来促成部门整体IT投资组合的生成。
  • 企业架构所面对的干系人包括组织中的所有角色，其中包括决策层和高级执行层的干系人，而他们也是确保组织能够高效地实现其任务的关键力量。
• 2、片段架构以业务管理为驱动力，并且为改善对市民的服务交付而提供各种工作制品。
  • 与企业架构关注于部门级的信息资源不同，片段架构更关注于部门的核心任务领域、业务服务和用于保障和支持他们的企业服务。
  • 从投资的角度来说，片段架构促进了用于具体IT投资的业务案例的产生。
  • 片段架构所面对的干系人主要是各个业务的拥有者。
  • 片段架构与企业架构并不是毫无关系的，他们在如下三个方面具有关联：
    • 片段架构继承了企业架构所使用的框架方法，并根据其面向的核心业务领域和共享服务对该框架方法进行扩展或特化。
    • 片段架构重用了在企业架构中定义的各项信息资产，包括数据、通用业务流程和投资、应用和技术等。
    • 片段架构遵守在企业架构中定义的各项规范和标准，包括业务战略、法规、标准和效能目标等。
• 3、解决方案架构定义了用于将部门业务功能进行自动化和高效化的IT资产。
  • 一个解决方案架构范围往往被限制在一个项目的范围之内，而该项目一般被用来实现系统和业务解决方案的全部或一部分。
  • 解决方案架构所面向的干系人一般是系统用户和开发者。
  • 与企业架构和片段架构的联系：例如片段架构定义了在核心业务领域或共享服务中所使用的各种接口，而这些接口将在会在各解决方案中被访问；此外在一个解决方案中所采用的各种技术同样也要接受在企业架构中定义的各种技术标准的约束。

（1）概述

效能改善生命周期的演进过程实际上也就是各种架构制品的演进过程。

• 为了实现组织的战略目标并达成各项可测量的性能改善，架构开发小组需要与各干系人一起以企业架构为起点协力开发面向组织核心任务领域的片段架构，并将用以实现目标的各个项目用解决方案架构组织起来。
• 在这些架构中片段架构有着承上启下的作用，而且片段架构的开发在整个效能改善生命周期中占据着核心地位。

在效能改善生命周期演进过程：

• 在架构阶段中，相关干系人需要对企业架构进行开发和维护，并对各面向组织核心业务领域的“片段”进行识别和定义。
• 在投资阶段中，在架构阶段被定义出来的各“片段”被组织成片段架构，同时相关干系人还需要为项目执行制定相关的资金策略，并开发出各个业务案例，从而调整在资金规划和投资控制过程中所制定的投资。
• 在实施阶段中，更加详细的项目管理规划被制定了出来，用以指导项目的实施。相关干系人在实施阶段中对各项目进行落实，并对项目的执行情况以及所产生的效果分别进行监督和评测。
• 注意：在整个效能改善生命周期中，各个干系人在开发片段架构、定义实施和资金战略、创建项目管理规划以及效能评测这些子过程中的活动可能会对企业架构的内容产生影响，因而在上图中这些子过程都具有一条到达起始点的反馈路径。

（2）片段架构

与企业架构着眼于整个组织级别的信息资产不同，片段架构所组织的各个片段关注于组织的业务层面以及用于支持各项业务的应用服务层面。
片段架构中所组织的内容分为如下三类：

• 核心业务领域片段（Core Mission Area Segments）：表示组织的主要任务方面，对应于联邦参考模型的业务参考模型中的内容。
• 业务服务片段（Business Service Segments）：表示用以支持组织的各主要业务的通用服务，对应于联邦参考模型的业务参考模型中的内容。
• 企业服务片段（Enterprise Service Segments）：表示用于保障和支持各部门组织的核心业务和业务服务的各种应用服务，而它对应的是联邦参考模型的服务组件参考模型。

图5 片段关系之间示例

① 片段的识别和定义过程

总的来讲，片段的识别和定义过程是一个持续发展的迭代过程，在此过程中各组织需要将自身的企业资产（包括各种系统和IT投资等）通过联邦企业架构参考模型映射成为组织的一个面向片段的视图。这些企业资产的描述信息来自于组织内外，可以看作是该过程得以顺利进行的必要输入，包括组织任务声明、战略目标、相关法律法规、通用或共享的业务和信息需求，以及在FTF中定义的各项跨部门举措。

② 片段架构的开发和维护过程

片段架构的开发和维护过程可分为：“分析”、“定义”和“操作”三个阶段，并且它们贯穿于效能改善生命周期之内并与此生命周期的三个阶段相互交织，从而使得片段架构能够在整个效能改善生命周期内对其进行支持。

• 分析阶段（Analyze）：定义片段架构的范围和变更需求，概括当前业务和信息管理环境，并在比较高的层次上描述效果改善的机会。
• 定义阶段（Define）：识别出用来支持业务和信息需求的目标片段架构，并概括出各种实现的可能性，包括针对相关跨部门举措的实现。同时在该阶段还需要制定一份过渡战略，其重点在于开发一系列用于IT投资和预算制定的业务案例。
• 操作阶段（Operate）：开发一份用于支持目标片段架构实现的项目管理规划，并将其与项目执行和解决方案开发建立联系。

如上图所示，片段架构开发和维护过程的各个阶段的活动分布于效能改善生命周期之中并与其各个阶段相互交织成五个步骤：

• 步骤一 ：架构分析（Architecture Analysis）。在此步骤中，架构开发团队需要为企业片段定义一份简洁的愿景，并将其与组织的战略规划相联系，同时架构开发团队需要考虑当前的各种变更驱动力，包括关键战略、法规和各种管理需求，从而识别出能够达到效能改善的各种机会。
  • 在此步骤中需要对如下几个问题进行解答：
    1. 各片段的范围是什么？为了解答这个问题，架构开发团队需要开发一张简洁的概念图与总结性描述，用以对组织各片段的范围以及当前的运营环境进行定义。
    2. 影响各个片段的主要变更驱动力是什么？为了解答这个问题，架构开发团队需要识别并描述新的和修改过的业务需求，以及其他影响片段的变更驱动力。
    3. 当前的系统片段和资源是什么？为了解答这个问题，架构开发团队需要对组织当前的片段状态信息进行编制。这些描述当前状态的信息需要涵盖架构的各个层面（性能、业务、数据、服务和技术），同时还需要包括当前系统、投资，乃至人员情况。除此之外，所收集的信息还需要达到足够的详细程度，从而支持各效能改善机会的发现。
    4. 在当前这些片断中制约其成功的因素有哪些？为了解答这个问题，架构开发团队需要审查当前各片段相关的资产和各变更驱动力，从中寻找能够改善组织效能且能够达到可量测目标的各种机会，并将其通过文档记录下来。
    5. 针对各片段的愿景是什么？为了解答这个问题，架构开发团队需要编制一张简单的图表来阐述组织对各片段的愿景。这张概念图应针对建议的运营环境进行描述，包括为了解决之前已经被记录下来的各种不足以及达成各种可量测效能改善而做出的对于干系人交互方式、业务流程、信息共享、应用、技术等方面的计划变更。除此之外，此概念图还需要一份描述建议的运营环境以及与组织战略目标之间关联的总结性愿景说明文档来进行补充。
  • 此步骤要达到最终效果是：对在后续步骤中将要进行开发的目标片段架构的范围进行定义的各种机会加以明确，并对他们之间的优先级顺序达成共识。
• 步骤二：架构定义（Architecture Definition）。此步骤的目的是定义各片段将要达到的状态，并开发一份用以达到此状态的过渡计划。此步骤需要在组织的资金规划和投资控制过程开始之前完成。
  • 在此步骤中需要对如下几个问题进行解答：
    1. 各片段的效能改善目标是什么？为了解答这个问题，架构开发团队需要为各个片段建立效能目标，包括目标效能量测以及达到这些目标的时间表。效能改善目标构成了目标片段架构在性能层面的基础，并且它需要与组织企业架构和战略目标相适合，从而将效能目标与组织整体战略目标联系在一起。
    2. 能够达到效能目标的设计方案都有哪些？为了解答这个问题，架构开发团队需要评估和对比各种用于达到效能目标的设计方案。为了达到这个目的，架构开发团队需要参考FTF中定义的各种跨部门举措，从中寻找与片段相关并能够重用的举措。除此之外，架构开发团队还需要进行市场调研，从而对现存的各种资产、系统、组件、服务和最佳实践进行评估，判断其是否能够被重用并被整合到片段架构之中。
    3. 用以组织各片段的目标架构是什么？为了解答这个问题，架构开发团队需要开发目标片段架构，这既包括组织的效能目标，也包括用以支持这些目标实现的业务、数据、服务和技术方面的架构。需要注意的是，目标片段架构需要采用联邦企业架构参考模型进行描述。
    4. 为了达到目标片段架构而需要进行的项目有哪些，以及他们之间的执行顺序是什么？为了解答这个问题，架构开发团队需要开发片段过渡战略。架构开发团队需要使用目标片段架构来识别出当前状态与目标状态之间的差距，并制定出为了弥合这些差距而需要被执行的项目。除此之外，架构开发团队还需要评定这些项目的优先级和依赖关系，并据此决定他们的执行顺序。所有这些活动的结果最终都将被记录到片段过渡战略之中。
  • 此步骤要达到最终效果是：在组织中产生对于目标片段架构和过渡战略的共识。
• 步骤三：投资和资金战略（Investment & Funding Strategy）。此步骤的目的是为项目执行制定资金战略，并为资金规划和投资控制过程中的投资制定创建相关业务案例。此步骤需要在组织将其预算提交给OMB之前就要完成。
  • 在此步骤中需要对如下几个问题进行解答：
    1. 针对各个项目的资金战略是什么？为了解答这个问题，架构开发团队需要为在片段过渡战略中明确的各个项目制定资金策略。架构开发团队需要与CPIC（资金规划和投资控制）人员紧密合作，通过使用在片段过渡战略中的项目序列计划，为各个项目分析出各种可能的资金策略。这既包括分析各种可能的资金来源，也包括判断各种适用的资金调配方法。资金策略需要考虑整合在目标片段架构中明确的现有投资。架构开发团队和CPIC人员制定的资金策略需要确保在目标片段架构实施时必要的资金已经准备停当。
    2. 用于实现目标片段架构的各项投资的理由是什么？为了解答这个问题，架构开发团队需要为各项用于支持项目实施的投资制定各种业务案例。这些案例包括了来源于架构分析、目标片段架构和项目资金策略的信息。
  • 此步骤要达到最终效果是：产生IT投资组合以及经过批准的资金策略。
• 步骤四：方案管理与执行（Program Management & Execution）。此步骤的目标是将片段架构和资金战略转化成一份方案管理计划，该计划定义了用于实现目标片段架构的各个项目的性质和范围，以及各个片段、其他组织的举措以及相关的跨部门举措之间的依赖关系。方案管理计划还包括了一份效能改善战略，其中定义了一系列与效能目标相关联的用于维护组织企业架构过渡战略的里程碑。
  • 在此步骤中需要对如下几个问题进行解答：
    1. 如何运用现有资源来达成效能目标？为了解答这个问题，架构开发团队需要开发一份详细且可执行的方案管理计划，用于描述各个实施项目以及为了达成目标片段架构而制定的这些项目之间的逻辑顺序。方案管理计划必须具有足够的详细程度，从而使得项目经历和开发人员能够明晰各个项目的范围、开发周期以及各个实施任务和活动之间的关系。此外，方案管理计划还需要明确其与其他组织的方案以及跨部门举措之间的关系。
    2. 用于实现目标片段架构和达到各效能目标的解决方案的性质是什么？为了解答这个问题，架构开发团队以及相关干系人需要协力执行在方案管理计划中制定的各个项目，并为目标片段架构中的各元素制定解决方案架构。各个项目的执行过程需要遵守组织的项目管理规则，而解决方案架构的定义和实施则需要与组织的系统开发方法相协调。片段架构的各种工作产品可以在系统开发过程中被重用，同时他们也为开发解决方案架构定义了需求和标准。解决方案架构的开发需要与片段架构和企业架构相兼容，并通过组织的治理流程来保证针对标准的兼容和重用。
    3. 向效能目标发展的进程执行情况如何？为了解答这个问题，架构开发团队以及相关干系人需要定义和监督各个效能量测指标以及目标效能评测量，并借此验证效能是否得以改善。
  • 此步骤要达到最终效果是：产生新的或经过修改的业务和信息管理需求 和 用于描述片段架构的开发和实施所带来影响的效能矩阵。
• 步骤五：片段架构的维护（Segment Architecture Maintenance）。此步骤吸收和同化新的业务和信息需求，并使用他们来更新片段架构的工作产品。
  • 在此步骤中需要对如下几个问题进行解答：
    1. 针对各片段的新的或修正过的变更驱动力是什么？为了解答这个问题，架构开发团队需要更新架构变更驱动力列表。在此过程中，新的或经过修改的变更驱动力将作为片段架构维护活动的输入，并被用来定义新的驱动力对现有片段架构工作制品的影响。架构开发团队还需要对各个自上而下以及自下而上的变更驱动力（包括从业务和信息管理解决方案的开发和实现而来的反馈）进行监督和同化。
    2. 这些新的变更驱动力针对片段架构工作产品的影响是什么？为了解答这个问题，架构开发团队需要对新的变更驱动力进行分析，判断其优先级顺序，并确定各项需求对现有片段架构工作产品的影响。项目经理和架构开发团队还需要制定一份用于更新片段架构工作产品的行动计划来应对各具有优先级的驱动力，并将其中的各项行动纳入到方案管理计划中。这一行动计划应包含用于修改片段架构的片段架构开发流程中的各项元素，并需要被安排来支持各生命周期流程，例如IT投资管理流程。
  • 此步骤要达到最终效果是：为片段架构相关元素的更新分配合适的资源。

上述针对片段架构和片段过渡战略开发的描述从本质上讲是在组织的各个业务层面以及对其进行支持的服务层面对组织如何改善其效能进行指导。但正如一个水桶的最大盛水量是由其最短木板决定的一样，在组织中一个部分的优化并不代表整个效能的改善，因而如何从组织全局的角度将各个片段的过渡战略进行优化整合才是能够使组织获得最优效能改善的最佳方法，其最终产出就是优化组合了各片段过渡战略的企业架构过渡战略，因而每个片段过渡战略也可以说是企业架构过渡战略的一个细粒度的子集。

• 企业架构过渡战略是组织由当前状态向目标状态过渡的规划设计，因而用于描述其当前状态架构（基线架构）和目标状态架构（目标架构）需要被提前建立。
• 虽然采用相同的框架方法，但由于表述内容对象不同，基线架构和目标架构的构建方法也不尽相同。
  • 基线架构的建立基本上是一个数据收集个过程，而目标架构的创建则更多的依赖于分析。
  • 一般来讲，基线架构需要在全局的抽象层次之上为组织进行建模，但对于组织任务中受到优先关注的领域则需要提供更加详细的描述，其描述的详细度应受限于用于确定需要进行改进的领域的各种信息。相比之下，在目标架构的开发过程中，架构师们就需要与各个业务负责人进行紧密的合作，确定所制定的目标能够符合业务在未来的需求，并关注于这些目标间的优先级顺序，从而使组织对于任务的执行效能得以改善。目标架构需要对业务负责人发现的各项不足之处进行解决，并对各种新的方案进行明确。此外还需要注意的是，建立目标架构的关键之处在于明确各个与组织的核心任务领域与通用服务相关的片段。

（2）执行冗余和差距分析

执行冗余和差距分析：寻找当前架构与目标架构之间的区别和差距，并借以识别出针对基线架构的各项改进机会。

• 这些分析方法应该着眼于针对组织任务价值的评估，以及对效能差距与各种成本削减的机会的明确，而这些能够促成效能改善各项机会将会在后面的企业序列计划中，通过定义在其中的各项方案和项目而实现。

（3）定义并修缮各片段，并制定他们的优先级顺序

当组织全局级别的企业架构被定义出来时，组织中的各个片段也应该被识别出来，而一旦这些片段被明确，组织就应该按照他们的重要性来对其进行优先级评定，并且片段架构的开发也应该被纳入到企业架构方案计划（EA Program Plan）和企业架构过渡战略之中。

• 通常来讲，片段架构应该比组织级的企业架构具有更高的详细度，它应该包含各个计划好的效能改善里程碑和/或成本缩减里程碑，并且这些里程碑应该在企业架构过渡战略中有所反映。
• 注意：企业架构过渡战略并不等同于企业架构方案计划。相比之下，后者的范围局限于架构师们可以立即执行的各项活动，而前者则是关于整个组织中所有里程碑的总结，相对于各项组织范围内的计划，它可以更好地对项目进程进行管理和汇报。

（4）制定企业序列计划

企业序列计划提供了一份关于整个组织范围内的所有现代化活动（现代化活动：通过信息技术的引入而使组织运行得到改善的活动）的视图。

• 包括：
  1. 各个片段以及用于落实这些片段架构的各项实施方案和项目，从而使得组织的高层人员能够借助于企业架构来为整个组织做出规划。
  2. 各项实施项目和方案之间的依赖关系与相对优先级顺序，从而使得诸如由于预算裁剪、项目取消或延迟以及方案优先级变化等方面的变化而带来的影响得以被清楚地识别出来。

分析：与片段架构的过渡战略相比，企业序列计划的描述详细度是站在组织全局角度而制定的，因而它定义了组织中所有方案和项目的执行顺序和依赖关系，以及用于评测效能改善和成本节省情况的各个里程碑。除此之外，在企业序列计划的内容制定过程中还需要考虑跨部门举措（于FTF中定义）的引入和重用，以及这些跨部门举措与过渡战略中各元素（包括片段架构、现代化方案和项目、方案和项目里程碑以及效能里程碑等）之间的关系。

（5）开发片段架构

• 片段：作为企业架构过渡战略的一部分，片段描述了组织的核心任务领域以及用以对其进行支持的各种通用服务。
• 片段架构：提供了一个详细且面向结果的架构，以及一份关于组织的一个片段或部分的过渡战略。
• 片段架构的开发是一个相互协作的过程，它在企业级规划和解决方案的开发实施之间建立起了联系的桥梁。对于片段架构的具体开发过程可以参照前面的相关部分。

（6）定义方案和项目

企业架构过渡战略中的各个实施项目和方案需要以组织的目标和企业架构为基准进行比对和检查，但一个项目是否能够被启动，以及这些项目按照何种顺序进行，往往还需要依赖于组织对这些项目在投资方面的决策。这些通过企业架构明确出来的项目和方案将作为输入而直接进入到组织的投资管理和预算制定过程之中，而这些用于实现组织战略目标的项目和方案也由此成为了联系企业架构和组织投资管理的桥梁，他们可以对组织来说是特定的存在，也可以使政府全局级别的解决方案。在资金规划和预算制定的过程中，企业架构过渡战略将会被用来对项目资金决策的影响进行评估，并对在组织为了达成过渡战略中计划安排的效能里程碑而需具备的能力与实际预算之间的权衡进行帮助。在投资管理和预算制定过程结束之后，过渡战略还应该根据最终的资金策略而进行调整，不过需要注意的是，这并不意味着过渡战略是受投资管理和预算过程而驱动的，相反是组织的战略和架构促使了各项投资的产生。

企业架构项目作用：将会产出各种工作产品以及服务，借助于这些产品和服务，决策者可以在信息准确充足的情况下进行业务决策的制定，并且组织中的IT投资、项目管理以及运营的效率和有效性都将会得到改善。

• 如何定量评估？( 评估企业架构项目对组织的贡献度）：OMB的企业架构实施指南针对企业架构项目成果的评测提出了一些概念和实施导则。
  • 企业架构价值评测是一个与效能改善生命周期各个阶段机密结合的以“客户”为中心的持续不断的过程，其目标是为组织决策者证明企业架构的价值，并对能够为企业架构产品和服务带来改善的各种机会进行明确。
  • 为了达到这一目标，企业架构价值评测过程将针对企业架构的开发和使用情况进行跟踪，并监督企业架构中各种产品和服务对IT投资决策、协作和重用、标准兼容性、干系人满意度等评测领域及相关指标所产生的影响。

在这份企业架构实施指南中，企业架构价值的含义是通过一个名为企业架构价值框架的概念来描述的。

企业架构价值框架为企业架构在效能改善生命周期中所产生影响的概念化提供了一条途径，从上图分析可得，企业架构框架的价值贡献遍布于整个效能改善生命周期的各个阶段之中：

• 在企业（Enterprise）级别，企业架构中的工作产品（主要是企业架构过渡战略）推动了组织中用于实现其战略目标（即目标运营环境）的IT投资组合的产生。
• 在片段（Segment）级别，用于描述组织的核心业务领域以及用于支持核心业务的通用服务（业务服务和企业服务）的片段架构指导并促进了各个业务案例的开发，并由此促成业务和信息管理方案的制定，从而落实组织企业架构并获得目标业务产出。
• 在解决方案（Solution）级别，解决方案架构促成了针对具体实施项目（在片段级别的架构和方案管理规划中定义）的预算制定，并通过指导一个或多个项目的具体实施来实现战术层面的目标。

由于企业架构的各个工作产品在效能改善周期各阶段中被分别创建和维护，并且这些工作产品由于其内容对象的不同也被划分为三种级别，所以针对企业架构价值的评测也分布到了这些阶段之中，并分别针对不同级别的架构产品。
此外，针对企业架构价值评估信息的收集、分析和汇报行为应该发生在与效能改善生命周期各阶段相关的时间点上，所以主架构师和企业架构项目组成员就必须对于以下两点进行工作：

• 企业架构价值的评测都有哪些？
• 在什么时点能够对这些评测标准进行评定？

（1）企业架构价值测评分类

针对企业架构价值的评测最终还是要落实到针对具体的评测指标的评估之上，因而对于评测领域和指标的制定和定义是整个企业架构价值评测的基础，也是在评测进行之前需要明确的主要内容。按照内容分类，评测指标分为：

• 主观评测指标：此种类型的指标来源于各干系人的意见，即各个干系人根据企业架构在业务决策以及在施行其角色任务过程中所体现出的作用对企业架构各工作产品和服务而进行的评估，其优点在于它从“客户满意度”这个角度获得了各干系人对于企业架构的直接反馈。主观评测指标评测结果信息的获取一般是通过对相关干系人进行调研或会谈而达成的，并且对于不同的评测指标根据其重要性的不同往往还需要加以不同的权重，从而获得较为合理的评估结果。
• 客观评测指标：此种类型的指标并不像主观评测指标那样依赖于各干系人的主观意见，而是代表了经过量化的企业架构价值产出，它反映了企业架构为IT投资、IT项目效能或者组织运营所带来的变化，其优点在于为企业架构的价值评测提供了量化的数据，并且通过针对这种量化数据在多个时间间隔的跟踪，这些信息还可以反映出企业架构的价值变化趋势。

根据其内容的特殊性程度，评测指标分为：由于在联邦政府各部门之间许多企业架构举措的元素是共同的（例如，针对企业架构对IT投资规划的有用性的评测），即通用的评测指标，因而针对他们的评测指标也是基本一样的，但由于各部门的具体任务、组织复杂度等方面的不同，他们的企业架构在很多方面又各具特点，所以用于衡量这些方面的评测指标也必将不同，即特殊评测指标。

（2）企业架构的价值评测过程

根据OMB的企业架构实施指南，企业架构的价值评测过程被划分为三个步骤：

• 步骤一：定义价值评测领域
  • 识别干系人团体：干系人表示具有相同视角或责任的人员（推而广之，甚至是系统也可以被看作为干系人，不过对于高层次的企业架构来说，干系人通常指代的都是人员）所组成的团体，而企业架构的范围又往往涵盖了从组织高层到项目经理、项目组长、预算分析师以及开发人员等多个干系人团体。由于不同的干系人具有不同的视角，因而其对于企业架构价值的看法也有着很大的区别，因而在定义价值评测领域和指标之前，需要识别出组织中各个相关的干系人团体。
  • 识别企业架构项目的价值目标：针对不同的干系人明确其所需最重要的价值，即企业架构能够为他们提供什么信息，从而可以使他们在工作中得到最好的支持。==》各个基于干系人真实需要的评测指标将会被定义出来（在企业架构实施指南中列举出了一系列在联邦政府中通用的评测指标，有兴趣的读者可以对其进行参考借鉴）。
• 步骤二：识别评测数据源：在评测指标被确定后，需要识别能够获得这些评测信息的数据源。
  • 与客观评测指标相关的信息员一般都来源于组织内的各种统计和文档（组织预算图表、项目评估评价工具（PART，Program Assessment Rating Tool）的分数、外界对于组织的评估等资源），而与主观评测指标相关的信息则更多的是通过与各干系人进行各种形式的沟通（调查、会谈等）而获得。
  • 原则：优先采用已有信息源，而不要总是开发新的信息源，如此这样才能最小化信息采集的成本。
• 步骤三：执行价值评测：当企业架构价值评测指标和获取指标信息的数据源都被确定以后，则可启动针对企业架构价值的评测。步骤如下：
  • 执行基线评测：用于为将来针对目标评测的对比充当参考起点。如果在一个企业架构项目中针对其价值评测的过程处于刚开始阶段，基线评测通常就是针对组织中当前企业架构产品和服务的价值的评估，而如果价值评测的过程已经被建立过，则基线评测将会使用在某个时点的评测作为对照起始点。
  • 执行目标评测：通过创建目标评测标准来定义企业架构在支持组织实现其目标过程中所需要达到的标准，从而在针对企业架构的开发、使用与其为组织的IT投资、项目管理和运营方面所带来的效益之间建立起关联。
    • 注意：目标评测的制定通常要为未来某一特定时段而制定目标，一般来讲这个时间段往往会长达三至五年，而为了便于管理和评估的执行，这个时间段需要被切分成若干更加短小的时间段，并在每个中间时间点上定义相应的评测标准。
  • 执行当前真实情况评测：当基线和目标评测标准都制定好以后，组织就可以在特定的时间点上对企业架构产品和服务的价值进行评定，从而监控企业架构在历经各中间阶段，并最终达成目标评测标准过程中的进展情况。

图12 企业架构价值评测过程

如图所示，企业架构的评测过程是一个持续的循环过程，而且在定义评测指标和执行企业架构价值评定之后，组织需要对获得的各项评测结果信息进行分析，并将分析结果作为修改项目计划的依据，同时在最后三个步骤中产生的会对企业架构带来影响的各种信息也为企业架构价值评测指标的修订提供了反馈。

通过从FEAF到FEA的发展历程，我们可以看到企业架构和企业架构框架在美国联邦政府中是如何得以应用并日臻成熟的。

1. 存在问题：虽然在美国联邦政府中建立全局性的企业架构和在某一个政府机构中创建企业架构在概念上来讲没有太大分别的，他们所要解决的问题都是在组织范围内达到信息资源的共享和最大化利用，并借此优化组织内针对信息技术方面的投资。但是受制于联邦政府组织结构的复杂度和体制方面的不同，这一假设的等同性也只是在概念层面成立，在实际中并不可行。
2. FEAF：CIO委员会制定了FEAF，并借此为联邦政府企业架构这一全局性企业架构的建立提出了框架理论。此框架理论重点是为联邦政府企业架构的建设提出了一整套方法和流程，而且对架构的内容也在一定程度上进行了定义。除此之外，FEAF最大的贡献应该是提出了“片段架构”（Segment Architecture）这一概念，从而使得联邦企业架构的建设既可以保证对各部门已建企业架构的最小影响性和最大可适用性，同时还可以使联邦企业架构的建设可以通过一种增量发展的方式循序渐进。虽然FEAF有着上面的各项好处，但是它还是只是在理论层面上给出了方法和指导方向，这也促成了FEA的出现。
3. FEA：在FEA中，“片段架构”的概念得到了进一步的具体化，同时FEA通过参考模型的方式使得不同政府机构之间得以采用相同的方式描述其企业架构，从而为不同政府机构之间进行无障碍沟通建立基础。而且，由于采用了相同的描述方式，FEA可以在各个政府机构之间寻找可重用的信息资源，从而达成全联邦政府级别的信息资源共享。此外，FEA还提供了用于评估企业架构成熟度水平的框架和流程。

FEAF更注重于企业架构的建设过程，虽然它针对企业架构内容的分类和归纳也有论述，但是其标准性和详细度也过于简单，只是通过借鉴并修剪了一下Zachman框架来实现，而FEA对于这方面却做出了更详细的定义。但是与FEAF相比，FEA不能算是一个企业架构框架理论，它既没有指明企业架构的开发过程，也没有表明企业战略、干系人、业务活动以及基础设施等方面以及他们之间关系。实际上FEA的核心在于借助于详细参考模型的定义，为企业架构的描述提供了统一的描述语言，并借此针对跨部门的企业信息资源进行了描述和定义。