企业架构研究总结（15）——联邦企业架构之FEA实施指南（上）

      通过前面的论述，我们可以了解到在接管了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投资管理流程。

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