企业架构（三）——联邦企业架构框架（FEAF）

现状：随着各个政府部门建立符合各自特点的企业架构框架并逐步实现各自企业架构，例如财政部（DOT）的企业架构框架TEAF（Treasury Enterprise Architecture Framework），但是在当时这些企业架构的范围还是局限在各自的部门范围内。

问题：而从美国联邦政府这一整体角度来看，诸如组织目标与信息系统的相互适配以及信息系统和资源的冗余浪费等方面的问题并没有得到完美的解决。无论从组织架构、组织职能，还是从其服务对象的角度来审视，美国联邦政府都是极为复杂的组织系统，因而如何站在美国联邦政府这一全局角度来考虑企业架构所面对的问题是极具挑战的。

解决方法：为了解决这一问题，一个从联邦政府这一整体性角度出发的企业架构框架需要被开发出来，并以此为基础建立和维护适合联邦政府自身的企业架构，从而能够促进各个政府部门之间的信息整合和共享，提高整个联邦政府在信息化投资方面的效率。这一思想在付诸实行后历经多年演进最终结晶为联邦企业架构FEA。

发展历程：

• 1996年颁布的Clinger-Cohen法案（亦称为信息技术管理改革法案），该法案的主旨是美国政府指导其下属的各联邦政府机构通过建立综合的办法来管理信息技术的引入、使用和处置等，并且该法案要求各政府机构的CIO负责开发、维护和帮助一个合理的和集成的IT架构（ITA）的实施。
• 在此法案的推动之下，CIO委员会于1999年9月发布了FEAF（Federal Enterprise Architecture Framework），用于指导联邦政府各部门创建企业架构。
• 随后，联邦企业架构创建和管理工作被移交给了美国的管理和预算办公室（OMB），而OMB也随即成立了联邦企业架构程序管理办公室（PMO）来专门开发联邦企业架构（FEA），并于2002年2月发布了第一版的FEA。

一、FEAF

FEAF是一个以架构建设过程为重点的企业架构框架理论，并且对于企业架构内容也有着一定程度的归纳（虽然标准化程度并不高），同时最重要的是FEAF所提出的片段架构（Segement Architecture） 的概念对于以后的FEA的影响是非常大的，并且为日后大型企业创建企业架构指明了一条道路。随后，在2001年CIO委员会又发布了联邦企业架构实施指南（ 《A practical guide to Federal Enterprise Architecture》）。在这篇指南中，CIO委员会介绍了联邦企业架构建设的具体流程和企业架构框架（例如FEAF等）如何在企业架构建设过程中发挥作用。并且在此指南中，企业的生命周期也被定义成由企业架构过程与其他几个企业管理过程相互结合并互相作用的过程，从而体现了企业架构在一个组织中的重要意义。

1、FEAF的出现

联邦企业架构所管理的信息资源分布于各个机构之中，所以FEAF必须能够被各个机构方便地采用，并且不能影响到各个机构已有的企业架构，从而保护各机构为各自企业架构所付出的投资和努力。为了达到上述目标，CIO委员会制定了三种方法：

• 传统方法——首先在时间和资金上申请大量的初始投资，然后开发一个能够对架构进行描述的框架，并使用此框架对当前架构以及目标架构进行描述。在此之后，通过设计、开发以及系统采购等方式实现企业架构的演进。
• 片段方法——建立一个结构化的企业架构框架，并对中的架构片段进行增量式开发，其中每个片段被限定在一个特定的业务领域内。
• 维持现状。

CIO委员会采用了片段方法，即将联邦企业架构看成若干片段，每个片段对应某个特定的业务领域，针对每个业务领域进行架构描述，能够大大降低系统的复杂度，但是问题的总体复杂度依然守恒。。

• 在“片段方法”中，首先从各个业务领域的视角开始对整个联邦政府在逻辑上进行分解，然后采用传统企业架构建设方法对每个分解出来的片段进行建设。也正是由于这种“片段方法”，联邦企业架构的建设过程也成为了一个基于各个业务领域的增量式的演进过程，而且由于建设单元被细化，联邦企业架构针对外界变化的反应能力得到了增强。
• 不过笔者认为，分段方法并不能减少问题的总体复杂度，而是使复杂的问题简单化，从而使复杂问题的解决成为可能，但是问题的总体复杂度依然守恒。
• 原来整体的一块被分解为相对琐碎的若干片段，虽然就每个片段来说实现难度下降了，但由于这些片段之间的相互联系性，维持这些片段一致性发展就会成为新的问题点，如果只注重于某个片段的发展而忽视片段之间的协调性，那么类似于之前所说的“技术驱动”路线的弊端还会显现，甚至更为严重，因而一个全局的针对联邦政府企业架构的治理、共享和评测机制也需要建立起来，并施以同样的重视度，我想这就是在后面将提到的联邦过渡框架（FTF）、企业架构评估框架（EAAF）和企业架构实施指南等框架和导则存在的原因之一。但不论怎么说，FEAF的这种“片段方法”可以说是联邦企业架构的主要特色，此后OMB建立的FEA的很多内容实际上也是该方法的延伸和具体化。

2、FEAF构成

（1）Level 1

在联邦企业架构的建立方面，FEAF首先是一种组织机制，被用来管理企业架构描述的开发和维护，而在将企业架构付诸实施方面，FEAF还提供了一种结构，用于组织联邦政府资源以及描述和管理联邦企业架构的相关行为。

在联邦企业架构框架的设计过程中，CIO委员会将企业架构的开发和维护过程以模型的形式进行表述，并且他们还将这一模型分成八个相互结合并互相作用的子部件，八种部件组合在一起就形成了FEAF开发和维护企业架构的模型：

• 架构驱动力（Architecture Drivers）：架构驱动力是促使架构产生和演进的原动力，一般来说包含两种类型的来自于外界并对企业架构的变革产生刺激的推动力：业务驱动力和设计驱动力。

  • 业务驱动力：代表联邦政府的核心业务需求，例如公众访问需求、Clinger-Cohen法案对架构开发的要求、其他新法案要求电子化访问或者电子签名的使用，以及关于政府行为的各种创新。
  • 设计驱动力：代表实现联邦政府业务需求的各种革新方法，包括新的软件或硬件技术，以及新的针对软硬件系统的部署方式等。

• 战略方向（Strategic Direction）：战略方向指导者目标架构的开发，包括愿景、原则和目标。

• 当前架构（Current Architecture）：通过描述企业架构的当前状态，展示了企业当前的业务能力和技术能力。它包括企业当前的业务架构 和 设计架构 两个部分。

  • 当前架构的业务层面：代表了在当前技术能力支持下企业目前的业务需求。
  • 当前架构的设计层面：代表了用于实现当前业务需求的数据、应用和技术方面的内容。

• 目标架构（Target Architecture）：描述了企业架构将要达到的目标状态，展示了企业未来的业务和技术能力。它包括企业的目标业务架构和设计架构两个部分。

  • 目标架构的业务层面：代表了在未来技术能力支持下的企业未来的业务需求。
  • 目标架构的设计层面：代表了用于支持未来业务需求的数据、应用和技术方面的内容。

• 过渡过程（Transitional Process）：用于支持从当前架构到目标架构的迁移。联邦政府的重要过渡过程包括了资本的IT投资规划（capital IT investment planning）、迁移规划（migration planning）、配置管理（configuration management）以及工程变更控制（engineering change control）。

• 架构片段（Architectural Segments）：如前所述，整个企业架构被分为若干部分，而每一部分对应一个架构片段。

• 架构模型（Architectural Models）：定义了用于对各个架构片段进行描述的业务和设计模型。

  • 业务模型：为在架构驱动力推动下出现的各种业务需求进行建模。
  • 设计模型：为支持业务需求而必须的数据、应用和技术进行建模。

• 标准（Standards）：代表架构开发和维护过程中所涉及的所有标准（有些可能是强制性的要求）、导则和最佳实践。

结论：

• 在FEAF的世界里企业架构的出现和变更都是在一系列的架构驱动力的刺激之下来进行的。由于外界的刺激以及环境的变化总是绝对的，因而FEAF是站在一个适应变化的角度上阐述企业架构的开发和维护过程，并将其定义为一个循环往复的过程，这是非常客观的。
• 在架构驱动力的推动之下，企业的战略方向也会跟随演进，并且目标架构的制定是需要与企业的战略方向相一致的。由此可见，FEAF将外界推动、企业战略结合了起来，并将企业战略细化为更加具体的目标架构描述，从而使企业战略即符合现实需要，又在整个组织范围内得到了一致认同。
• 当前架构和目标架构需要使用相同的方式和语言（架构模型）进行描述，从而可以分析出现实和目标的差距，并将这些差距具体化为一系列的过渡过程，从而指导企业和企业架构的同步演进。并且在演进过程中，所需要遵循的各项标准，以及所采用的导则和最佳实践等工具也被明确了出来，从而达成在实施过程中的无障碍沟通性和标准性。
• 架构片段的划分大大降低了开发联邦企业架构的复杂性，并且也可以按照增量的方式对联邦企业架构进行循序渐进的开发和维护。
• 采用相同的架构模型对各个架构片段进行描述可以提高各个架构片段开发的标准性，并且不同架构片段之间的沟通也更加通畅，例如通用性架构片段对各个具体业务领域架构片段的支持和融入将变得非常容易。

（2）Level 2

细化中，组成FEAF模型的各个组件作了如下的扩展：

• 在上个层次中的当前设计架构被细化为当前的数据架构、应用架构以及技术架构。
  • 数据架构：定义了用来支持业务各种数据，以及他们之间的关系。
  • 应用架构：定义了用来管理数据并支持业务功能的各个应用。
  • 技术架构：定义了用于为管理数据和支持业务功能的各个应用提供支持的各种技术。
• 与当前设计架构的细化类似，目标设计架构也被细化为数据架构、应用架构以及技术架构。
• 在上个层次中的架构设计模型被细化为数据模型、应用模型和技术模型，他们分别为数据、应用和技术架构的描述提供了更加详细的描述方式。
• 在这个层次中每个架构片段对应联邦政府中的一个主要业务领域。一个架构片段的选择和定义需要与框架以及加载到联邦企业架构资源库中的模型、架构信息相符合。一个架构片段也可以看作为一个事件驱动的流程，它贯穿联邦组织机构，并拥有足以使其被纳入到联邦企业架构中的投资回报率（ROI，return-on-investment）。
• 过渡过程的内容也被进一步细化和明确，包括且不限于如下几个过程：
  • 资金IT投资规划和决策制定（Capital IT Investment Planning and Decision Making）：根据筹资预测、投资回报率和成本效益等判定条件来评估投资是否值得为其编制预算。
  • 投资管理审查（Investment Management Review）：为投资审查决策过程提供架构信息。
  • 片段协调（Segment Coordination）：协调片段架构与联邦企业架构的整合，同时配置管理和工程变更控制过程也必须到位。
  • 市场调研（Market Research）：执行一个周期性的市场搜索和分析，用以寻找先进的且具有潜在收益的技术。
  • 资产管理（Asset Management）：管理所有基于联邦企业架构的基础设施资产。
  • 采购实践（Procurement Practices）：使采购活动与架构以及其他过渡过程相同步。
  • 架构治理（Architecture Governance）：协调架构建设和维护过程中的种种活动，从而避免工作的混乱、误解和返工。
• 标准的内容进一步细化和明确，包括且不限于如下几种标准：
  • 安全标准（Security Standards）：包括所有方面都必须遵循的各种安全准则。这不仅包括信息技术方面的各种安全方针，还包括在业务领域也需要遵循的各种安全准则。
  • 数据标准（Data Standard）：用于描述数据、元数据以及他们之间关系的各项准则。
  • 应用标准（Applications Standards）：应用于各种应用软件上的各项原则和标准。
  • 技术标准（Technology Standards）：应用于各种操作系统、平台以及硬件系统等信息技术基础设施上的各项标准。

（3）Level 3——架构模型细化

FEAF在最后一个粒度层次的细化中仅是针对架构模型的内容来进行的，通过借鉴Zachman框架的内容将架构模型的内容进一步细分如下：

视角	数据架构	应用架构	技术架构
规划者 （目标和范围）	业务对象列表	业务流程列表	业务地点列表	业务架构模型
拥有者 （企业模型）	语义模型	业务流程模型	业务物流系统
设计师 （信息系统模型）	逻辑数据模型	应用架构	系统空间部署架构	设计架构模型
建造者 （技术模型）	物理数据模型	系统设计	技术架构
分包商 （详细规范说明）	数据定义、字典	执行方案	网络架构
	数据架构模型	应用架构模型	技术架构模型

分析：FEAF只采用了Zachman框架中的前三列的内容，将在第三个层次中细化出来的业务架构模型、数据架构模型、应用架构模型和技术架构模型分别按照不同参与者的视角进行了更加详细定义。在上面的架构模型定义表格中：

• 业务架构模型被进一步细化，包括了规划者视角下的业务对象列表、业务流程列表、业务地点列表，以及拥有者视角下的语义模型、业务流程模型和业务物流系统。
• 数据架构模型的内容被细化为逻辑数据模型、物理数据模型，以及数据定义和字典。
• 应用架构模型的内容被细化为应用架构、系统设计和执行方案。
• 技术架构模型的内容被细化为系统空间部署架构、技术架构和网络架构。

小结：

• 作为用于描述组织核心任务的业务架构模型，其主要关注者就是承担规划者和业务拥有者角色各个干系人，他们所关注的范围包含了数据、应用和技术等所有方面，只不过相对于下面用于支持业务的参与者来说，他们对于这三方面的描述角度是站在业务相关的立场上的，因而业务架构模型与从属于设计架构模型的数据、应用和技术架构模型并不是一个平行的层次关系，而是不同角色的干系人针对相同事物在不同角度的所看到的不同视图。
• 相对于业务架构模型与设计架构模型这两者根据视角的不同而采取的水平划分方法，对于设计架构模型的细化采取的就是垂直划分了，即从数据、应用和技术三个方面对设计架构模型进行划分，并且在每个划分出来的模型区域中又根据设计师、建造者以及分包商所具备的视角分别制定更加详细的模型制品。

（4）Level 4——业务架构模型细化（EAP方法）

FEAF还通过借鉴企业架构规划技术（EAP，Enterprise Architecture Planning）为业务架构模型的建立提供了方法。

• 企业架构规划（EAP）：指为利用信息支持业务而定义架构的过程，以及用来实现这些架构的规划。
• EAP可以看作是关于数据、应用和技术的一张高层次（业务和管理视角）蓝图，并借此保证他们之间的协调发展（alignment）。

具体到FEAF，EAP为上面的FEAF架构模型中的业务架构模型（第一和第二行内容）提供了一套实现方法。在CIO委员会的FEAF文档中，EAP的作用表现如下：

EAP在架构模型中的作用：与Zachman框架将关注点放在架构内容描述上不一样，EAP所关心的是对信息技术与业务的相互校准过程进行规划和管理，因而EAP所采用的是不同于具体设计和实现的高层次的视角。

二、企业架构实施指南

1、企业生命周期

如何使用架构框架理论为联邦政府以及各个机构建设企业架构呢？
企业架构的建设、维护和使用又该如何融入到各个机构中？

面对这些问题，2001年CIO委员会发布了《A practical guide to Federal Enterprise Architecture》，用于为各个机构提供一份关于建设和维护企业架构的详细指南，并且该指南还介绍了如何将企业架构融入到各机构的生命周期中，从而促进机构的良性发展。

企业的生命周期：在企业的存续和发展过程中，企业需要不断的吸收新的技术、业务流程等新鲜事物，并将其转换为能够促进企业前进的各项能力，而这样一个循环往复的过程。

• 三个核心过程：企业架构过程（EA Process）是一个独立运行的迭代过程，而除此之外一个企业的良性发展还需要企业工程和项目管理（Enterprise Engineering and Program Management）和资金规划和投资控制过程（CPIC，Capital Planning and Investment Control），并通过他们之间的协调合作来达成。
  • 企业架构过程：用于企业架构的建设、维护和使用的指导过程；
  • 企业工程和项目管理：用于负责针对企业各个实施或采购项目的管理；
  • 资金规划和投资控制过程：企业关于投资的选择、控制和评估方面的重要工具。
• 三个核心过程的关系：
  • 这三个过程并不是相互隔绝的，企业架构过程的实施最终要落实到一个个具体实施项目之上，而确保这些项目能按时按质的实现就需要企业工程和项目管理以及资金规划和投资控制过程方面的强力支持。
  • 此外，企业架构过程所产生的企业架构内容也为这两个核心过程提供了准确可靠信息基础，并且企业架构过程还可以保证这些信息能够快速反映和消化外界环境的变化。
• 其他支持性过程：企业生命周期的良性发展还需要系统生命周期、人力资源以及安全管理这三个支持性的管理过程的帮助。这三个支持性过程具有普适性，他们不像上面三个核心过程那样直接作用于企业的具体任务，但是他们确实是支持各个核心过程并保证企业任务能够顺利进行的重要保障。

2、企业架构过程

企业架构过程
企业架构过程：以采用步进的方式，将开发、维护与应用描述成一个 循环往复的迭代过程。

• 与架构开发方法（ADM）同异：
  • 同：都采用了循环迭代的方式，且大部分的步骤都有着相似的意义和内容；
  • 异：在步骤的具体描述方面，CIO委员会只是针对此过程中的每个步骤进行了较为详尽的说明，而TOGAF的ADM的描述方式则更具标准性，除了各步骤的说明之外还包括了每个步骤的目标、输入、输出以及进一步细化的分支步骤。
• 组成：九个部分，除了最后的“控制与监督（Control and Oversight）”之外，其余八个部分都是以前后衔接的方式来布置。即，按照箭头所指方向前面步骤的完成为后面步骤的启动奠定基础，并且这八个步骤都处于“控制与监督”这一过程的控制之下。
• 顺序步骤：
  • 取得上层主管的认同和支持（Obtain Executive Buy-In and Support）
  • 建立管理结构和控制（Establish Management Structure and Control）
  • 定义架构过程和方法（Define an Architecture Process and Approach）
  • 开发基线企业架构（Develop Baseline Enterprise Architecture）
  • 开发目标企业架构（Develop Target Enterprise Architecture）
  • 开发序列计划（Develop the Sequencing Plan）
  • 使用企业架构（Use the Enterprise Architecture）
  • 维护企业架构（Maintain the Enterprise Architecture）
  • 控制与监督（Control and Oversight）

（1）取得上层主管的认同和支持

定位：取得所有上层主管的认同和支持是一个企业架构过程建设的起始，也是决定一个企业架构是否能够被成功建立的先决条件。

• 原因：企业架构涉及全组织的信息资产，其开发和维护需要整个组织提供持续的资源支持，因而得到组织全体尤其是高层的支持是非常重要的。
• 核心内容：CIO和主架构师（主要推动和执行核心）需要在企业的不同层面分别获得相关人员的支持和认同，而其中最主要的是获得管理层对架构过程所必需的资源支持的承诺、各业务负责人和领域专家在业务角度对企业架构目标的认知以及在预算及其他约束方面的分析。

具体步骤：

• 首先CIO需要创建市场策略，并与企业最高领导进行交流，使其了解企业架构开发在战术和战略上的价值。在取得最高领导的认同之后，CIO需要取得他对企业架构支持的承诺，为获得必要的资源支持打下基础。同时，CIO需要与最高领导在高层管理团队中选择主架构师。然后，CIO还要和最高领导一起基于各项用于治理企业架构的开发、实施和维护的架构原则创建企业架构方针（Architecture Policy）。
• 接下来，CIO需要起草市场方案来进一步强化企业架构的价值，并在高层管理团队中获得认可，并得到他们以及他们下属组织和资源会积极投入的承诺。主架构师需要起草一份更为具体的企业架构计划，从而获得企业中包括业务负责人和领域专家在内的各个业务单元的支持，并且还需要他们从业务策略角度，结合预算以及其他约束条件对架构的业务层以及相关序列计划的合理性进行分析。
• 最后，CIO和主架构师需要举行一个企业架构项目的启动会议，用于阐述企业架构的目标、里程碑、流程、产品，以及企业架构过程与系统生命周期活动、资金规划和投资控制过程等相关过程之间的关系，从而在业务的中层和下层的参与人员中获得共识和支持。

（2）建立管理结构和控制

企业架构管理组织结构概念图
建立用于管理、控制和监督企业架构过程中各项活动的组织结构： 各种角色的责任以及他们之间的责任和沟通关系需要被清晰地定义出来，而且该组织架构的构成应该有助于其中的各个角色在企业架构中职能的发挥。

• 注意：由于企业规模的差别以及业务复杂度等方面的不同，企业架构管理组织中角色的构成以及角色的职能也是具有不小的差别。
  • 在指南中，该企业架构管理组织包括了企业架构执行委员会（EAESC，EA Executive Steering Committee）、技术审查委员会（Technical Review Committee）以及企业架构项目管理办公室（EA Program Management Office）这样的专为企业架构过程所设的部门，也包括诸如质量保证（Quality Assurance）、配置管理（Configuration Management）、风险管理（Risk Management）、安全以及评估这样的较为通用的信息技术支持职能单元。

（3）定义架构过程和方法

架构内容深度和详细度制约因素

定义架构过程和方法：企业需要指定用于建设企业架构的过程和方法。

• 1、明确企业架构的使用目的和范围，而这也是推动后续企业架构过程活动的主要动力。
• 2、判断出使用目的和范围对企业架构在内容深度和详细度方面的需求，并保证各个视角下的视图内容都遵循相同的深度和详细度标准。
• 3、选择适当的企业架构制品，并使用上一步指定的深度和详细度水平来约束架构制品的内容。
  • 这个选择既包括挑选包含了必要内容的核心架构制品，也包括明确用于进一步阐述核心制品或在特定领域和范围内对其进行描述的支持性架构制品。
  • 从架构制品内容这一角度来看，他们需要包含企业的业务和技术资产这两个方面。
• 4、选择适当的架构框架理论和用于辅助架构建设的自动化工具。
  • 在联邦政府的范围内，企业架构框架理论，例如上面提供过的FEAF，DoDAF和TEAF等，因而各机构可以按照自己的实际情况在这些框架中选择并定制出符合自身情况的框架理论。
  • 为了加强架构的可用性并提升架构开发的效率和准确性，选择适当的自动化架构工具是必不可少的。
  • 注意：自动化工具的选择也要照顾到企业的规模、复杂度以及员工熟悉度等多个方面。

（4）开发基线企业架构

开发基线企业架构：各个企业或组织需要根据已经确定的架构目标、范围和所采用的架构框架对当前自身的状态进行各种制品的开发，包括针对核心架构制品的开发、支持性架构制品的开发、其他由于特定需求而单独定义的架构制品（简报图表、会谈纪要等）的开发。

在联邦企业架构指南中，关于企业架构核心团队对于架构开发过程（对基线企业架构和目标企业架构的开发均适用）所要进行的各种活动做了如下图所示的归纳：

架构制品开发过程

• 数据收集：识别和收集用于描述企业或机构当前状态的各种信息。
• 初步架构制品制定：在此步骤中各种初步的架构制品将会被创建。
  • 注意：架构开发过程是个循环往复的过程，因而在一次迭代中也许并不能创建所有的架构制品，或者架构产品的详细度也不能达到最终要求，这都需要在后续的迭代过程中加以改善。
• 审核与修订：审核架构制品的准确性和完成度，并根据审核结果对架构产品进行修订和改善。
  • 具体过程：该审核过程应该在架构开发过程中的多个时点进行，而不是一个一次性的过程，并且每次审核过程应该分为两个阶段：首先由架构核心团队的资深成员对架构制品进行一个快速审查，在此之后提交给各个课题专家（在这一次的审查中，参与的成员可能包括主架构师、架构核心团队、质量保证人员、风险管理人员、课题专家以及各业务领域负责人）进行再一次的审核。在审核结束后，需要针对架构制品进行适当的修改和完善，之后提交给企业架构执行委员会（EAESC）和技术审查委员会（TRC）用于对架构制品进行验证和最终确定。
• 发布和交付：在架构制品被提交给企业架构执行委员会（EAESC）和技术审查委员会（TRC）后，若通过，则包含各种架构制品的企业架构将会被发布，而且相关文档也会被一并交付，同时相关的数据库以及架构工具也要被更新。

（5）开发目标企业架构

“开发目标企业架构” 与 “开发基线企业架构” 只在内容方面有区别：

• 企业架构制品开发过程的适用性：前者用于为企业或组织未来的目标状态而制定架构，而后者则用于描述企业或组织当前的状态。因而（4）中的架构制品开发过程同样也适用于开发目标企业架构制品。
• 实际上，在这个架构制品开发过程中关于基线（当前）企业架构制品的开发和关于目标企业架构制品的开发应该是同步进行的，所以这两个过程可以被统称为“企业架构制品开发过程”。

（6）开发序列计划

为了实现从当前架构到目标架构的过渡，企业或机构需要通过一系列相互关联的活动以一种增量的方式逐步实现，而为了管理和维护这样一个繁复的演进过程，企业或机构就需要制定和维护一个系统过渡路线图或者序列计划。由于目标企业架构往往是描述企业在一段时间之后（可能三到五年的时间）的未来状况，因而为了增强这一过渡过程的可行性和应变能力，企业或架构需要在当前架构和目标架构之间采用与之相同的描述方式建立起一系列用于描述中间过渡状态的架构。由于环境是不断变化的，符合实际的当前架构和目标架构也需要在环境的推动下而发生变化，因而这些描述中间过渡状态的架构也需要通过维护来确保其准确性和可行性。为了将这样一个包含若干中间状态的过渡过程加以细化，从而得到一个可以用来指导实施的序列计划，企业或组织可以通过如下几个步骤来实行：

• 进行差距分析：企业或组织需要以当前架构和目标架构为依据，通过差距分析方法并对其进行对比，在两者的相关架构制品中寻找演进的机会，从而得出为了达到目标状态而需要进行改变的各个组件。
• 识别遗留、过渡和新系统：此三种系统组成了演进至目标架构所需的各技术组件。其中遗留系统指的是当前在运行，但是在目标架构部署后会被淘汰的各种系统和应用；过渡系统是指当前在运行，甚至在过渡过程开始后或者在目标架构被部署后的一段时间内都需要被使用的各种系统和应用；新系统，顾名思义，是指在当前还不存在，但是在目标架构中需要被实现的系统和应用。在这些系统被识别之后，他们之间的关系以及在过渡过程中的演进情况需要被明确（例如，通过系统迁移图）。
• 进行迁移规划：企业或机构需要把当前和目标架构的差距进一步细化为一个个的可执行项目，并为这些项目配置合适的资源，同时还需要按照优先级顺序为这些项目制定实施规划。这既需要企业或机构了解自身的变化适应能力，也需要掌握这些项目在资源需求、风险、优先级等方面的情况。
  • 对变化了的业务过程所做的实施工作可以被表示为一个个包含若干可执行项目的方案倡议（program initiatives）。通过差距分析，企业或机构可以发现需要被增强、修改或替换的各个方面，并通过依赖性分析决定用于实现演进的各种活动的各种组合方式（例如，顺序执行或并发执行），以及每个项目所需要完成的工作内容，并借此定义每个项目。
  • 对项目进行依赖性分析、衡量每个项目的重要度，并借此为每个项目评估其优先级，从而为项目组合制定序列规划的草案。
  • 最后，根据企业或组织的短期需求、财务约束下各业务单位潜在的动荡因素等方面对序列规划进行审核和修缮。

（7）使用企业架构

企业架构过程通过与其他企业中的管理过程和方法结合可促进企业或组织的良性发展，即使用企业架构的过程就是将企业架构与其他管理过程相协同的过程。

• 企业架构描述了企业或组织的当前状态、未来的期望状态，以及实现未来状态的过渡实施方案，即企业架构为企业或组织提供了一个包罗万象但组织有序的信息库。企业或组织中的各种活动都可以将该信息库作为基础，从而在信息充足且可靠的情况下做出各项决策，并且企业中原本隔绝的各个角色也可以使用相同方式进行交流，从而加强了企业或组织内外的合作。
• 例如，在资金规划和投资控制（CPIC）过程中，企业架构可以为其提供目标状态，从而企业或组织的投资可以在符合未来期望的前提下进行，并且企业架构所提供的各种企业当前状态也为企业或组织的投资决策提供了准确可靠的信息。

此外，企业架构还可以有如下用途：

• 即使一个企业或组织并不打算进行一个大幅度的IT升级，企业架构也可以作为库存管理、日常维护以及咨询等方面的资源而存在。针对企业当前架构的分析可以为在企业或组织中寻找各种改进机会提供帮助。
• 企业或组织可以借助企业架构中的各种制品来对企业的业务和技术方面的培训进行辅助。
• 可以使用企业架构对企业或组织进行调研和验证。由于企业架构对企业或组织的自业务到技术的各个层面都进行了建模和描述，因而可以基于这些信息对企业或组织以模拟的方式进行调研和概念证明（proofs-of-concepts）。
• 企业或组织可以在CPIC过程之外进行小型、低风险的项目开发，但是项目的管理还是需要与企业架构相一致。与企业架构相一致有助于项目与企业或组织的集成。
• 各个运维项目需要以当前架构作为其背景，而且他们的优先级和决策会受到企业架构过渡计划和目标架构的影响。

（8）维护企业架构

企业或组织自身和其所处的环境都是不断变化的，而企业架构的核心就是客观的反应企业或组织的当前和期望状态，并根据当前情况制定达到期望状态的计划，所以企业架构也需要跟随这些变化而进行不断的演进。

• 维护企业架构：在各个企业或组织中，负责维护企业架构演进的工作应由CIO、主架构师和企业架构项目管理办公室（EAPMO）负责，并且通过监管流程系统和独立的审核机制，企业架构核心团队可以周期性地对企业架构与不断变化的业务实践、资金配置和技术引入等方面的相符合情况进行评估和校准。
• 企业架构的内容包括了当前企业架构、目标企业架构和序列计划中所涉及到所有架构制品，因而针对企业架构的维护就是确保这些制品与企业或组织的实际情况相一致。

（9）控制与监督

控制与监督过程：作用于整个企业架构过程中的所有步骤，用于确保企业架构在开发、使用和维护过程中遵守由CIO委员会制定的这份联邦企业架构实施指南中对于各步骤所做的约定。

首先企业或组织需要确定企业架构项目管理控制的有效性。在企业架构管理组织架构的建立中，企业架构项目被交由CIO、主架构师和企业架构项目管理办公室负责，而为了得到关于项目进行情况的可视性，并借以监督管理企业架构项目的执行，这些责任实体需要在如下几个方面进行定义：

• 所需要知道的企业架构项目相关信息。
• 何时以及如何获得这些信息。
• 这些信息的具体内容和表现形式。

当这些企业架构过程的责任实体按上述定义获得了有关企业架构项目的信息，他们就可以借此识别出企业架构项目中不符合实施指南要求的地方，并针对这些问题采取相应的修正措施。

三、浅谈概念

“架构”、“架构框架”、“企业架构”和“企业架构框架”

• “架构”。
  • 架构的本质并非是要解决领域内的具体问题，而是复杂度管理，用于将所面对的复杂客观对象、问题或解决方案的复杂度进行有效的分解和管理，并尽量减轻内外变化所产生的影响。
  • 领域问题的解决靠的是相关的解决方案，同样一个问题可以有不同的解决方案，虽然他们的目标是一致的，但由于各自架构的不同，各个解决方案的灵活性、坚固性和扩展性均不相同，因而我们在为解决方案选择架构的时候关注的并不是其是否可以解决目标问题，更多是对架构所带来的灵活性、坚固性和扩展性与相应成本之间进行权衡。
• “企业架构”。以企业为描述目标的架构，注意：此处“企业”并非公司。
  • 架构的目标在于对目标问题的解决方案的复杂度进行分解和管理，那么对于“企业”来讲，企业架构所要管理的又是企业哪个方面的复杂度呢？企业中的IT与业务的协调问题。
  • 原因：虽然IT技术在企业中获得极大的应用和发展，但是其与业务发展的不平衡也逐渐显现，技术人员多强调技术的先进性和超前，忽略业务需要，甚至有时IT技术甚至充当了放大器的作用，将决策的错误加倍放大，因而才需要将两者的发展进行协调。
• “架构框架”和“企业架构框架”。
  • “企业架构框架”是以“企业架构”为目标的框架。在这里插入代码片
  • “架构框架”：用来创建、维护和/或使用架构的方法论。例如：Zachman和FEAF其实都是企业架构框架，论述了建设、维护和/或使用企业架构的方法。
  • “架构框架”和“架构”：前者提供了各种各种分析和运算方法，而后者是这些方法在某个领域内的产物。其实与企业架构理论相比，我倒是觉得企业架构框架明确了企业架构的内容和建设步骤及方法，是将企业架构落实的工具和方法，相对不应该那么空洞无物，不过如果忽视了企业架构的意义，恐怕企业架构框架也会觉得太过虚无缥缈。
  • 此外，由于业界的企业架构框架理论往往综合了多个组织和企业的实践经验，并天生具有高度抽象性，因而乍一看会给人一种过于庞杂的印象，其中步骤繁多，涉及到的企业架构内容也非常繁杂，但有一点需要说明，诸如TOGAF等有名的企业架构框架标准并非强制让人硬性照搬，相反鼓励使用者根据自己企业或组织的需要对框架理论进行定制和裁剪，因而强行照搬从某一方面倒违反了标准的精神，并且采用这种强搬的方式进行企业架构建设，也往往会让小企业望而却步，其实不然。