企业架构研究总结（6）——联邦企业架构之FEAF的出现和构成（上）

      美国联邦政府可以说是企业架构应用的先行者和最大倡导者。通过企业架构的发展历史我们可以看出，早在上世纪九十年代以来，美国军方就对这种全局性的信息共享的理论开始了研究，并开发出符合其特色企业架构框架理论（DoDAF）。除此之外，在Zachman框架引入到美国联邦政府各部门之后，首先是美国国家技术标准研究所（NIST）于1989年发布了NIST企业架构模型（NIST EA Model，后来的联邦企业架构框架FEAF的便是以此为基石而建立起来的），随后各个政府部门也推出了他们自己的企业架构框架理论用于指导各自企业架构的开发，例如财政部（DOT）的企业架构框架TEAF（Treasury Enterprise Architecture Framework）。虽然各个部门都建立了符合各自特点的企业架构框架，并据此逐步实现着各自的企业架构，但是在当时这些企业架构的范围还是局限在各自的部门范围内，而从美国联邦政府这一整体角度来看，诸如组织目标与信息系统的相互适配以及信息系统和资源的冗余浪费等方面的问题并没有得到完美的解决。无论从组织架构、组织职能，还是从其服务对象的角度来审视，美国联邦政府可以算得上是世界上最复杂的组织系统之一了，这并不是一家企业或者某一个政府部门的复杂度所能比拟的，因而如何站在美国联邦政府这一全局角度来考虑企业架构所面对的问题是极具挑战的。为了解决这一问题，一个从联邦政府这一整体性角度出发的企业架构框架需要被开发出来，并以此为基础建立和维护适合联邦政府自身的企业架构，从而能够促进各个政府部门之间的信息整合和共享，提高整个联邦政府在信息化投资方面的效率。这一思想在付诸实行后历经多年演进最终结晶为联邦企业架构FEA。

      正如名字中说到的那样，联邦企业架构的产生和发展有着明显的政府色彩，它的出现与发展和一系列的政府法令息息相关，并由专门的政府机构负责协调和实施。一般来讲，人们在提到联邦企业架构的时候总会从1996年颁布的Clinger-Cohen法案（亦称为信息技术管理改革法案）讲起，因而该法案也被当作联邦企业架构出现的始因。这部法案的主旨是美国政府指导其下属的各联邦政府机构通过建立综合的办法来管理信息技术的引入、使用和处置等，并且该法案要求各政府机构的CIO负责开发、维护和帮助一个合理的和集成的IT架构（ITA）的实施。在此法案的推动之下，CIO委员会于1999年发布了FEAF（Federal Enterprise Architecture Framework），用于指导联邦政府各部门创建企业架构。随后，联邦企业架构创建和管理工作被移交给了美国的管理和预算办公室（OMB），而OMB也随即成立了联邦企业架构程序管理办公室（PMO）来专门开发联邦企业架构（FEA），并于2002年2月发布了第一版的FEA。

FEAF

      FEAF是自Clinger-Cohen法案颁布之后出现的第一个专门用于构建联邦政府企业架构的框架理论。CIO委员会自1998年4月启动了FEAF的开发，通过借鉴NIST企业架构模型、Zachman框架以及企业架构规划（EAP，Enterprise Architecture Planning）等技术，最终于1999年9月发布了FEAF 1.1版。通过这份文档，CIO委员会针对FEAF产生的目的、背景以及组成进行了详尽的描述。FEAF是一个以架构建设过程为重点的企业架构框架理论，并且对于企业架构内容也有着一定程度的归纳（虽然标准化程度并不高），同时最重要的是FEAF所提出的片段架构（Segement Architecture）的概念对于以后的FEA的影响是非常大的，并且为日后大型企业创建企业架构指明了一条道路。

随后，在2001年CIO委员会又发布了联邦企业架构实施指南（ 《A practical guide to Federal Enterprise Architecture》）。在这篇指南中，CIO委员会介绍了联邦企业架构建设的具体流程和企业架构框架（例如FEAF等）如何在企业架构建设过程中发挥作用。并且在此指南中，企业的生命周期也被定义成由企业架构过程与其他几个企业管理过程相互结合并互相作用的过程，从而体现了企业架构在一个组织中的重要意义。

FEAF的出现

      在FEAF出现之前美国联邦政府的许多机构已经开始了企业架构的建设，并提出了很多企业架构框架理论，这些理论和实践虽然为FEAF的创建提供了借鉴，但是这种繁杂的背景同时也为一个全局性的联邦企业架构的建立带来了不小的挑战。由于联邦企业架构所管理的信息资源分布于各个机构之中，所以FEAF必须能够被各个机构方便地采用，并且不能影响到各个机构已有的企业架构，从而保护各机构为各自企业架构所付出的投资和努力。在这个背景之下，当时负责指定FEAF的CIO委员会为联邦企业架构框架制定了三个方向：

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

       第三个方向其实不用多说，因为维持现状所带来的还是老生常谈的无法信息共享，以及缺乏针对环境变化而进行快速反映的能力，而且最关键的是无法符合Clinger-Cohen法案的要求（不要忘了联邦企业架构的政府色彩）。第一种方向听起来最合理，因为大部分企业架构框架理论都符合此特征，但是由于联邦政府的复杂性，此种方法虽然逻辑上可行，但实际上却很容易陷入“分析瘫痪”（paralysis by analysis），因为从根本上对联邦政府进行一步到位的描述几乎是不可能完成的任务，甚至可能会影响到各机构已经建立的企业架构的发展，而且即便采用这种方法，那么联邦架构的开发过程将会不可思议的漫长。经过反复权衡，CIO委员会采取了第二种方式，即将整个联邦政府架构看成若干片段，每个片段对应某个特定的业务领域，同时针对每个片段采用架构描述方法对各个业务领域进行架构描述。如此一来，联邦政府架构的建设可以被分割为若干较小型的针对某一业务领域的企业架构的建设，并最终组合成联邦的整体企业架构。

      从系统分析方法论的角度看，如果一个系统过于复杂，则对其进行分析的最好方法就是按照某种角度对整个系统进行解构。随着系统的解构，系统的复杂度也会被分解到各个部件中，因而分析各个部件将会相对容易，并且通过将各个部件的分析结果组合在一起将最终形成对整个系统的分析结果。实际上第一种传统方法可以看作是一种通用的企业架构建设方法，理论上如果资源充足应该能够适用于所有组织中的企业架构建设，但是其之所以不能实现就是因为联邦政府这一系统的复杂性所带来的资源需求无限制化倾向。因而一种能够将系统复杂度分解的方法与传统企业架构建设方法相结合的方法论才是能够打开联邦企业架构建设之门的金钥匙，而这也正是FEAF所采用的“片段方法”的主旨所在。在“片段方法”中，首先从各个业务领域的视角开始对整个联邦政府在逻辑上进行分解，然后采用传统企业架构建设方法对每个分解出来的片段进行建设。也正是由于这种“片段方法”，联邦企业架构的建设过程也成为了一个基于各个业务领域的增量式的演进过程，而且由于建设单元被细化，联邦企业架构针对外界变化的反应能力得到了增强。不过笔者认为，分段方法并不能减少问题的总体复杂度，而是使复杂的问题简单化，从而使复杂问题的解决成为可能，但是问题的总体复杂度依然守恒。从全局看，问题的复杂度并不会降低，某一局部的便利总会需要其他方面复杂度的提高来平衡。同理，这种片段式的方法只是通过分解复杂度使得建立如此庞杂的企业架构成为可能，至少降低了这一宏大项目的实施门槛，不过就总体复杂度来讲却不见得有任何减轻。原来整体的一块被分解为相对琐碎的若干片段，虽然就每个片段来说实现难度下降了，但由于这些片段之间的相互联系性，维持这些片段一致性发展就会成为新的问题点，如果只注重于某个片段的发展而忽视片段之间的协调性，那么类似于之前所说的“技术驱动”路线的弊端还会显现，甚至更为严重，因而一个全局的针对联邦政府企业架构的治理、共享和评测机制也需要建立起来，并施以同样的重视度，我想这就是在后面将提到的联邦过渡框架（FTF）、企业架构评估框架（EAAF）和企业架构实施指南等框架和导则存在的原因之一。但不论怎么说，FEAF的这种“片段方法”可以说是联邦企业架构的主要特色，此后OMB建立的FEA的很多内容实际上也是该方法的延伸和具体化。

FEAF的构成

      在联邦企业架构的建立方面，FEAF首先是一种组织机制，被用来管理企业架构描述的开发和维护，而在将企业架构付诸实施方面，FEAF还提供了一种结构，用于组织联邦政府资源以及描述和管理联邦企业架构的相关行为。在联邦企业架构框架的设计过程中，CIO委员会将企业架构的开发和维护过程以模型的形式进行表述，并且他们还将这一模型分成八个相互结合并互相作用的子部件：

1. 架构驱动力（Architecture Drivers）：架构驱动力是促使架构产生和演进的原动力，一般来说包含两种类型的来自于外界并对企业架构的变革产生刺激的推动力：业务驱动力和设计驱动力。其中，业务驱动力包括新的法规、新的管理举措、用于加强重点领域的预算增加以及市场力量等，而设计驱动力则会包括新的软件或硬件技术，以及新的针对软硬件系统的部署方式等。
2. 战略方向（Strategic Direction）：战略方向指导者目标架构的开发，包括愿景、原则和目标。
3. 当前架构（Current Architecture）：通过描述企业架构的当前状态，展示了企业当前的业务能力和技术能力。它包括企业当前的业务架构和设计架构（设计架构可以进一步分为应用、数据以及技术这些方面）两个部分。
4. 目标架构（Target Architecture）：描述了企业架构将要达到的目标状态，展示了企业未来的业务和技术能力。它包括企业的目标业务架构和设计架构两个部分。
5. 过渡过程（Transitional Process）：用于支持从当前架构到目标架构的迁移。联邦政府的重要过渡过程包括了资本的IT投资规划（capital IT investment planning）、迁移规划（migration planning）、配置管理（configuration management）以及工程变更控制（engineering change control）。
6. 架构片段（Architectural Segments）：如前所述，整个企业架构被分为若干部分，而每一部分对应一个架构片段。
7. 架构模型（Architectural Models）：定义了用于对各个架构片段进行描述的业务和设计模型。
8. 标准（Standards）：代表架构开发和维护过程中所涉及的所有标准（有些可能是强制性的要求）、导则和最佳实践。

将此八种部件组合在一起就形成了FEAF开发和维护企业架构的模型：

FEAF第一层粒度示意图

      由此图我们可以得出如下结论：

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

      上述模型表达了FEAF针对开发和维护企业架构的行为和流程在最高层次的抽象。为了进一步描述这一企业架构开发和维护过程，FEAF还通过四种粒度（上述模型为最粗粒度的描述）对其进行了更加详细的阐述。需要注意的是，在这四种描述粒度中前三种是针对整个企业架构开发和维护过程进行逐级深入的描述，而第四种粒度只是针对架构模型内容方面做了更加细致的种类划分。

。。。（待续）