联邦企业架构之FEA实施指南

    

 

 

 

 

  下载LOFTER我的照片书  |

通过前面的论述，我们可以了解到在接管了FEA的开发之后，OMB先后制定了诸如参考模型、联邦过渡框架以及企业架构评估框架等标准用于为FEA的开发提供帮助。但是FEA的开发并不是最终的目的，美国联邦政府创建的FEA的初衷是为了提高政府整体的信息资源的利用率和效能，并改善政府针对信息技术的投资水平，因而如何开发和应用FEA并使其为上述目标提供价值才是目标所在。为了达到这一目标，OMB于2007年底发表了《FEA Practice Guidance》用以指导如何开发和利用联邦企业架构，从而实现联邦政府性能的改善。

      不论是具有什么样职能的部门都需要寻找能够提升其职能效率和效能的方法，尤其是在信息化技术被普遍使用的今天。为了达到这一目标，各个部门引入了各种理论和技术，并对很多最佳实践经验进行了借鉴。这些被引入的理论和技术可以被划分为多个实践领域（Practice Area），而企业架构正是这些实践领域中的一个。通过将部门的战略目标、部门的投资以及需要达到的可测量的性能改善结合起来，企业架构实践领域可以最大限度将部门的资源、IT投资和系统开发活动的效能发挥出来，从而实现部门的性能目标。企业架构实践领域只是部门所涉及的各项实践领域中的一环，为了达到部门性能的改善，各部门需要将企业架构实践领域与其他各个实践领域进行结合并加以应用，例如战略规划、资金规划和投资控制以及项目管理等。所有这些实践领域都需要在各部门对其效能进行改善的过程中进行适时并适当地使用，而这一改善过程在联邦企业架构实施指南中被称为“效能改善生命周期”（Performance Improvement Lifecycle）。本节的主要内容就是以此效能改善生命周期为背景，详细介绍企业架构是如何在这个背景下被开发和使用的。

1.　　效能改善生命周期

效能改善生命周期

      效能改善生命周期是一个反复迭代的循环过程，在此过程中，各部门通过对各个实践领域进行相互结合，逐步将其制定的各项战略目标进行实现，并最终达到可测量的效能改善。这一生命周期分为三个前后衔接的阶段：架构阶段、投资阶段和实施阶段，而且每个阶段都包含着若干紧密结合的流程。通过这些流程的结合运行，能够为部门带来效能改善的各种需求得以被实现，而这些能够驱动效能改善生命周期行进的原动力或需求来自于两个方面：

• 自上而下的驱动力，即部门为了效能改善而主动制定的战略目标。
• 自下而上的需求，即在实际运行中产生的诸如系统改进等方面的需求。

      这两方面的驱动力并不是毫无关联的，他们的区别主要在于其产生的源头，而一般来讲“自下而上的需求”往往也会变成“自上而下的驱动力”产生的直接原因。

      效能改善生命周期各阶段所包含的各个流程以及阶段转换中涉及到的各个流程的描述总结如下：

阶段	流程描述
架构阶段	开发和维护企业架构，并通过它来为部门当前和未来状态提供共享视图
	对“片段”（Segment）的内容和优先级进行定义，并将其作为企业架构过渡战略的一部分。此过渡战略对各个片段的先后顺序进行了排列。
	开发片段架构（Segment Architecture）。该架构在企业愿景（企业架构与企业架构过渡战略）与针对各个业务与信息管理解决方案的投资和实施之间建立了沟通的桥梁
投资阶段	为从企业架构过渡战略中识别出来的，并在片段架构中描述的各解决方案定义实施和资金策略
	建立方案管理规划（Program Management Plan）来实现在实施和资金策略中定义的各项解决方案
实施阶段	依照方案管理规划执行各个项目
	对项目的执行效果进行评测，检查期望目标的达成情况，并对企业架构和片段架构的开发过程进行反馈，从而促进他们的发展

 

2.　　企业架构的开发和应用

      从效能改善生命周期中各个流程的描述中我们可以看出，部门效能的改进是多个实践领域相互结合、共同作用的结果，但其中贯穿始终的还是企业架构这一实践领域。企业架构实践领域不仅为整个效能改善生命周期提供部门级的可共享的信息资源、规范和标准，而且企业架构所涉及的框架方法也是此周期能够顺利进行的重要工具。除此之外，效能改善生命周期的演进过程本身也是企业架构逐步细化、专门化的演进过程。在此生命周期中，企业架构起初以部门级的信息整合体的形态出现，经过细化而转变为面向各个具体任务领域的片段架构，并最终体现为包含了各种实现部门目标的方案和项目的解决方案架构。

2.1 架构级别

     企业架构、片段架构和解决方案架构采用不同的详细度，为各个相互关联但关注不同的干系人提供了关于部门的视图。他们之间的关系如下图所示：

 

不同级别架构对比示意

 

      企业架构的关注点基本上都落在对于通用或共享资产（战略目标、业务流程、投资、数据、系统或技术等）的识别和组织之上。企业架构往往是以战略目标为原动力的，它有助于一个部门识别其资源的分配与其任务和战略目标是否相适合。从投资的角度来看，企业架构一般被用来促成部门整体IT投资组合的生成。企业架构所面对的干系人包括组织中的所有角色，其中包括决策层和高级执行层的干系人，而他们也是确保组织能够高效地实现其任务的关键力量。

      相比之下，片段架构以业务管理为驱动力，并且为改善对市民的服务交付而提供各种工作制品。此外，与企业架构关注于部门级的信息资源不同，片段架构更关注于部门的核心任务领域、业务服务和用于保障和支持他们的企业服务。从投资的角度来说，片段架构促进了用于具体IT投资的业务案例的产生。片段架构所面对的干系人主要是各个业务的拥有者。片段架构与企业架构并不是毫无关系的，他们在如下三个方面具有关联：

• 片段架构继承了企业架构所使用的框架方法，并根据其面向的核心业务领域和共享服务对该框架方法进行扩展或特化。
• 片段架构重用了在企业架构中定义的各项信息资产，包括数据、通用业务流程和投资、应用和技术等。
• 片段架构遵守在企业架构中定义的各项规范和标准，包括业务战略、法规、标准和效能目标等。

      解决方案架构定义了用于将部门业务功能进行自动化和高效化的IT资产。一个解决方案架构范围往往被限制在一个项目的范围之内，而该项目一般被用来实现系统和业务解决方案的全部或一部分。解决方案架构所面向的干系人一般是系统用户和开发者。解决方案架构也不是孤立存在的，它与上面两种架构也是相互关联的，例如片段架构定义了在核心业务领域或共享服务中所使用的各种接口，而这些接口将在会在各解决方案中被访问；此外在一个解决方案中所采用的各种技术同样也要接受在企业架构中定义的各种技术标准的约束。

2.2　　架构演进

      效能改善生命周期的演进过程实际上也就是各种架构制品的演进过程。为了实现组织的战略目标并达成各项可测量的性能改善，架构开发小组需要与各干系人一起以企业架构为起点协力开发面向组织核心任务领域的片段架构，并将用以实现目标的各个项目用解决方案架构组织起来。在这些架构中片段架构有着承上启下的作用，而且片段架构的开发在整个效能改善生命周期中占据着核心地位。下图展示了在效能改善生命周期的各个阶段中企业架构是如何通过片段架构与用于实现目标的各项目以及效能评测发生关联的：

 

企业架构在效能改善生命周期中的演进

 

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

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

• 核心业务领域片段（Core Mission Area Segments）
• 业务服务片段（Business Service Segments）
• 企业服务片段（Enterprise Service Segments）

 

片段类型

      上图展示了联邦政府中各个部门（SBA、EPA、HHS等）所对应的各种片段。其中，核心业务领域片段代表了组织的主要任务方面，而业务服务片段则代表了用以支持组织的各主要业务的通用服务。以上两者对应于联邦参考模型的业务参考模型中的内容。对于企业服务片段来说，它所代表的是用于保障和支持各部门组织的核心业务和业务服务的各种应用服务，而它对应的是联邦参考模型的服务组件参考模型。

片段之间关系示例

      片段架构的开发首先是以针对片段的识别和定义开始，并在企业架构和企业过渡策略的制定过程中得以实现的。由于组织的企业架构的详细程度有可能不足以进行片段的识别和定义，在联邦企业架构实施指南中针对此种情况提出了如下方法和步骤用于应对这种情况：

• 定义业务信息管理需求和架构变更驱动力，并根据其优先级进行排序。
• 定义、审查用于改善组织效能的各个候选方案，并根据其优先级进行排序。
• 将经过优先级排序的候选方案映射到组织的业务模型和服务模型，并由此识别出候选的片段。核心任务领域和业务服务片段会从业务模型中被识别出来，而企业服务片段将从组织的服务模型中被识别出来。
• 根据被选中的片段的范围明确用于片段架构开发的各项资源，包括管理支持、业务和技术专家等。
• 创建片段架构开发团队。

 

片段识别方法

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

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

 

片段架构开发过程

 

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

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

• 架构分析（Architecture Analysis）：在此步骤中，架构开发团队需要为企业片段定义一份简洁的愿景，并将其与组织的战略规划相联系，同时架构开发团队需要考虑当前的各种变更驱动力，包括关键战略、法规和各种管理需求，从而识别出能够达到效能改善的各种机会。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 各片段的范围是什么？为了解答这个问题，架构开发团队需要开发一张简洁的概念图与总结性描述，用以对组织各片段的范围以及当前的运营环境进行定义。
      2. 影响各个片段的主要变更驱动力是什么？为了解答这个问题，架构开发团队需要识别并描述新的和修改过的业务需求，以及其他影响片段的变更驱动力。
      3. 当前的系统片段和资源是什么？为了解答这个问题，架构开发团队需要对组织当前的片段状态信息进行编制。这些描述当前状态的信息需要涵盖架构的各个层面（性能、业务、数据、服务和技术），同时还需要包括当前系统、投资，乃至人员情况。除此之外，所收集的信息还需要达到足够的详细程度，从而支持各效能改善机会的发现。
      4. 在当前这些片断中制约其成功的因素有哪些？为了解答这个问题，架构开发团队需要审查当前各片段相关的资产和各变更驱动力，从中寻找能够改善组织效能且能够达到可量测目标的各种机会，并将其通过文档记录下来。
      5. 针对各片段的愿景是什么？为了解答这个问题，架构开发团队需要编制一张简单的图表来阐述组织对各片段的愿景。这张概念图应针对建议的运营环境进行描述，包括为了解决之前已经被记录下来的各种不足以及达成各种可量测效能改善而做出的对于干系人交互方式、业务流程、信息共享、应用、技术等方面的计划变更。除此之外，此概念图还需要一份描述建议的运营环境以及与组织战略目标之间关联的总结性愿景说明文档来进行补充。

• • 此步骤要达到最终效果是：对在后续步骤中将要进行开发的目标片段架构的范围进行定义的各种机会加以明确，并对他们之间的优先级顺序达成共识。
• 架构定义（Architecture Definition）：此步骤的目的是定义各片段将要达到的状态，并开发一份用以达到此状态的过渡计划。此步骤需要在组织的资金规划和投资控制过程开始之前完成。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 各片段的效能改善目标是什么？为了解答这个问题，架构开发团队需要为各个片段建立效能目标，包括目标效能量测以及达到这些目标的时间表。效能改善目标构成了目标片段架构在性能层面的基础，并且它需要与组织企业架构和战略目标相适合，从而将效能目标与组织整体战略目标联系在一起。
      2. 能够达到效能目标的设计方案都有哪些？为了解答这个问题，架构开发团队需要评估和对比各种用于达到效能目标的设计方案。为了达到这个目的，架构开发团队需要参考FTF中定义的各种跨部门举措，从中寻找与片段相关并能够重用的举措。除此之外，架构开发团队还需要进行市场调研，从而对现存的各种资产、系统、组件、服务和最佳实践进行评估，判断其是否能够被重用并被整合到片段架构之中。
      3. 用以组织各片段的目标架构是什么？为了解答这个问题，架构开发团队需要开发目标片段架构，这既包括组织的效能目标，也包括用以支持这些目标实现的业务、数据、服务和技术方面的架构。需要注意的是，目标片段架构需要采用联邦企业架构参考模型进行描述。
      4. 为了达到目标片段架构而需要进行的项目有哪些，以及他们之间的执行顺序是什么？为了解答这个问题，架构开发团队需要开发片段过渡战略。架构开发团队需要使用目标片段架构来识别出当前状态与目标状态之间的差距，并制定出为了弥合这些差距而需要被执行的项目。除此之外，架构开发团队还需要评定这些项目的优先级和依赖关系，并据此决定他们的执行顺序。所有这些活动的结果最终都将被记录到片段过渡战略之中。

• • 此步骤要达到最终效果是：在组织中产生对于目标片段架构和过渡战略的共识。
• l投资和资金战略（Investment & Funding Strategy）：此步骤的目的是为项目执行制定资金战略，并为资金规划和投资控制过程中的投资制定创建相关业务案例。此步骤需要在组织将其预算提交给OMB之前就要完成。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 针对各个项目的资金战略是什么？为了解答这个问题，架构开发团队需要为在片段过渡战略中明确的各个项目制定资金策略。架构开发团队需要与CPIC（资金规划和投资控制）人员紧密合作，通过使用在片段过渡战略中的项目序列计划，为各个项目分析出各种可能的资金策略。这既包括分析各种可能的资金来源，也包括判断各种适用的资金调配方法。资金策略需要考虑整合在目标片段架构中明确的现有投资。架构开发团队和CPIC人员制定的资金策略需要确保在目标片段架构实施时必要的资金已经准备停当。
      2. 用于实现目标片段架构的各项投资的理由是什么？为了解答这个问题，架构开发团队需要为各项用于支持项目实施的投资制定各种业务案例。这些案例包括了来源于架构分析、目标片段架构和项目资金策略的信息。

• • 此步骤要达到最终效果是：产生IT投资组合以及经过批准的资金策略。
• 方案管理与执行（Program Management & Execution）：此步骤的目标是将片段架构和资金战略转化成一份方案管理计划，该计划定义了用于实现目标片段架构的各个项目的性质和范围，以及各个片段、其他组织的举措以及相关的跨部门举措之间的依赖关系。方案管理计划还包括了一份效能改善战略，其中定义了一系列与效能目标相关联的用于维护组织企业架构过渡战略的里程碑。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 如何运用现有资源来达成效能目标？为了解答这个问题，架构开发团队需要开发一份详细且可执行的方案管理计划，用于描述各个实施项目以及为了达成目标片段架构而制定的这些项目之间的逻辑顺序。方案管理计划必须具有足够的详细程度，从而使得项目经历和开发人员能够明晰各个项目的范围、开发周期以及各个实施任务和活动之间的关系。此外，方案管理计划还需要明确其与其他组织的方案以及跨部门举措之间的关系。
      2. 用于实现目标片段架构和达到各效能目标的解决方案的性质是什么？为了解答这个问题，架构开发团队以及相关干系人需要协力执行在方案管理计划中制定的各个项目，并为目标片段架构中的各元素制定解决方案架构。各个项目的执行过程需要遵守组织的项目管理规则，而解决方案架构的定义和实施则需要与组织的系统开发方法相协调。片段架构的各种工作产品可以在系统开发过程中被重用，同时他们也为开发解决方案架构定义了需求和标准。解决方案架构的开发需要与片段架构和企业架构相兼容，并通过组织的治理流程来保证针对标准的兼容和重用。
      3. 向效能目标发展的进程执行情况如何？为了解答这个问题，架构开发团队以及相关干系人需要定义和监督各个效能量测指标以及目标效能评测量，并借此验证效能是否得以改善。

• • 此步骤要达到最终效果是：

1. 1. 1. 产生新的或经过修改的业务和信息管理需求。
      2. 产生用于描述片段架构的开发和实施所带来影响的效能矩阵。

• 片段架构的维护（Segment Architecture Maintenance）：此步骤吸收和同化新的业务和信息需求，并使用他们来更新片段架构的工作产品。
  • 在此步骤中需要对如下几个问题进行解答：

1. 1. 1. 针对各片段的新的或修正过的变更驱动力是什么？为了解答这个问题，架构开发团队需要更新架构变更驱动力列表。在此过程中，新的或经过修改的变更驱动力将作为片段架构维护活动的输入，并被用来定义新的驱动力对现有片段架构工作制品的影响。架构开发团队还需要对各个自上而下以及自下而上的变更驱动力（包括从业务和信息管理解决方案的开发和实现而来的反馈）进行监督和同化。
      2. 这些新的变更驱动力针对片段架构工作产品的影响是什么？为了解答这个问题，架构开发团队需要对新的变更驱动力进行分析，判断其优先级顺序，并确定各项需求对现有片段架构工作产品的影响。项目经理和架构开发团队还需要制定一份用于更新片段架构工作产品的行动计划来应对各具有优先级的驱动力，并将其中的各项行动纳入到方案管理计划中。这一行动计划应包含用于修改片段架构的片段架构开发流程中的各项元素，并需要被安排来支持各生命周期流程，例如IT投资管理流程。

• • 此步骤要达到最终效果是：为片段架构相关元素的更新分配合适的资源。

3. 企业架构过渡战略

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

      企业架构过渡战略是一个有效的企业架构的重要内容，它为组织在指定时间内实现目标架构描述了一份全局性规划，并将组织的各项投资与目标架构进行了明确的关联，从而使组织资金策略的制定更加有效。除此之外，企业架构过渡战略还定义了各种过渡活动之间的逻辑依赖关系，以及他们之间的相对优先级。一般来讲，企业架构过渡战略是一个跨越多年的规划（通常三至五年），而对于组织内外不断变化的今天来说，这么长时间的过渡计划往往是难以维护和保证的，因而在企业架构的当前状态和目标状态之间还需要制定多个中间过渡状态，从而方便对企业架构过渡战略执行进行监督和维护。

企业架构过渡战略示意

 

      针对企业架构过渡战略的开发发生在效能改善生命周期的架构阶段，同时它也是这一阶段的关键产出物，并且在接下来的投资阶段中为组织催生出一份建议的投资组合。由于这份投资组合来源于架构，所以通过针对该组合中的各项投资的落实和实施，组织将可以展示出其在达成任务目标和业务产出这一过程中的进度。

企业架构过渡战略开发所处的阶段

      企业架构过渡战略的开发包含若干步骤，但由于各组织在复杂程度、任务性质和范围以及治理流程等方面的不同，在不同的组织之中关于企业架构过渡战略开发的具体步骤在细节上也不尽相同，不过从比较高的抽象层次来看这些步骤还是可以被归纳如下：

企业架构过渡战略开发步骤

 

• 建立当前和目标架构。
• 执行冗余和差距分析。
• 定义并修缮各片段，并制定他们的优先级顺序。
• 制定企业序列计划。
• 开发片段架构。
• 定义方案和项目。

3.1　　建立当前和目标架构

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

3.2　　执行冗余和差距分析

      此步骤的目的就是要寻找当前架构与目标架构之间的区别和差距，并借以识别出针对基线架构的各项改进机会。这些分析方法应该着眼于针对组织任务价值的评估，以及对效能差距与各种成本削减的机会的明确，而这些能够促成效能改善各项机会将会在后面的企业序列计划中，通过定义在其中的各项方案和项目而实现。

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

      当组织全局级别的企业架构被定义出来时，组织中的各个片段也应该被识别出来，而一旦这些片段被明确，组织就应该按照他们的重要性来对其进行优先级评定，并且片段架构的开发也应该被纳入到企业架构方案计划（EA Program Plan）和企业架构过渡战略之中。通常来讲，片段架构应该比组织级的企业架构具有更高的详细度，它应该包含各个计划好的效能改善里程碑和/或成本缩减里程碑，并且这些里程碑应该在企业架构过渡战略中有所反映。需要注意的是，企业架构过渡战略并不等同于企业架构方案计划。相比之下，后者的范围局限于架构师们可以立即执行的各项活动，而前者则是关于整个组织中所有里程碑的总结，相对于各项组织范围内的计划，它可以更好地对项目进程进行管理和汇报。

3.4　　制定企业序列计划

      企业序列计划提供了一份关于整个组织范围内的所有现代化活动（所谓现代化活动指的是通过信息技术的引入而使组织运行得到改善的活动）的视图。企业序列计划中包括了各个片段以及用于落实这些片段架构的各项实施方案和项目，从而使得组织的高层人员能够借助于企业架构来为整个组织做出规划。此外，企业序列计划还定义了各项实施项目和方案之间的依赖关系与相对优先级顺序，从而使得诸如由于预算裁剪、项目取消或延迟以及方案优先级变化等方面的变化而带来的影响得以被清楚地识别出来。

企业序列计划概念图

 

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

3.5　　开发片段架构

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

3.6　　定义方案和项目

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

4　　评测企业架构项目效果

      组织的企业架构项目将会产出各种工作产品以及服务，借助于这些产品和服务，决策者可以在信息准确充足的情况下进行业务决策的制定，并且组织中的IT投资、项目管理以及运营的效率和有效性都将会得到改善。但是如何具体地衡量这些产品和服务所带来的种种效益，并进而得出企业架构项目对组织的贡献度呢？为了解答这个问题，OMB的企业架构实施指南针对企业架构项目成果的评测提出了一些概念和实施导则。企业架构价值评测是一个与效能改善生命周期各个阶段机密结合的以“客户”为中心的持续不断的过程，其目标是为组织决策者证明企业架构的价值，并对能够为企业架构产品和服务带来改善的各种机会进行明确。为了达到这一目标，企业架构价值评测过程将针对企业架构的开发和使用情况进行跟踪，并监督企业架构中各种产品和服务对IT投资决策、协作和重用、标准兼容性、干系人满意度等评测领域及相关指标所产生的影响。

      在论述如何对企业架构的价值进行评测之前，我们需要先明确企业架构的价值到底是什么。在这份企业架构实施指南中，企业架构价值的含义是通过一个名为企业架构价值框架的概念来描述的：

企业架构价值框架

 

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

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

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

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

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

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

      除了上述的针对评测指标类型的划分方法之外，企业架构价值评测指标还可以根据其内容的特殊性程度来进行划分。由于在联邦政府各部门之间许多企业架构举措的元素是共同的（例如，针对企业架构对IT投资规划的有用性的评测），因而针对他们的评测指标也是基本一样的，但由于各部门的具体任务、组织复杂度等方面的不同，他们的企业架构在很多方面又各具特点，所以用于衡量这些方面的评测指标也必将不同。总的来说，一个具体组织中的企业架构评测指标应该是那些通用的评测指标以及特殊评测指标的集合体。

      在明确了企业架构的价值以及用于对其进行评测的指标的含义之后，我们再来探讨一下企业架构的价值评测过程。根据OMB的企业架构实施指南，企业架构的价值评测过程被划分为三个步骤：

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

      由于每个组织都处在一个内外部环境不断发展变化的环境之中，因而作为描述一个组织情况的企业架构也不会是一成不变的，以此类推，用来对企业架构的各工作产品和服务进行评测的各项指标也不会是静态的，各种用于提升企业架构价值的反馈信息在帮助组织改善其企业架构的同时也会对于各个评测指标本身发生影响：

企业架构价值评测过程

 

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