美国联邦政府可以说是企业架构应用的先行者和最大倡导者。通过企业架构的发展历史我们可以看出，早在上世纪九十年代以来，美国军方就对这种全局性的信息共享的理论开始了研究，并开发出符合其特色企业架构框架理论（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委员会将企业架构的开发和维护过程以模型的形式进行表述，并且他们还将这一模型分成八个相互结合并互相作用的子部件：
- 架构驱动力（Architecture Drivers）：架构驱动力是促使架构产生和演进的原动力，一般来说包含两种类型的来自于外界并对企业架构的变革产生刺激的推动力：业务驱动力和设计驱动力。其中，业务驱动力包括新的法规、新的管理举措、用于加强重点领域的预算增加以及市场力量等，而设计驱动力则会包括新的软件或硬件技术，以及新的针对软硬件系统的部署方式等。
- 战略方向（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的世界里企业架构的出现和变更都是在一系列的架构驱动力的刺激之下来进行的。由于外界的刺激以及环境的变化总是绝对的，因而FEAF是站在一个适应变化的角度上阐述企业架构的开发和维护过程，并将其定义为一个循环往复的过程，这是非常客观的。
- 在架构驱动力的推动之下，企业的战略方向也会跟随演进，并且目标架构的制定是需要与企业的战略方向相一致的。由此可见，FEAF将外界推动、企业战略结合了起来，并将企业战略细化为更加具体的目标架构描述，从而使企业战略即符合现实需要，又在整个组织范围内得到了一致认同。
- 当前架构和目标架构需要使用相同的方式和语言（架构模型）进行描述，从而可以分析出现实和目标的差距，并将这些差距具体化为一系列的过渡过程，从而指导企业和企业架构的同步演进。并且在演进过程中，所需要遵循的各项标准，以及所采用的导则和最佳实践等工具也被明确了出来，从而达成在实施过程中的无障碍沟通性和标准性。
- 架构片段的划分大大降低了开发联邦企业架构的复杂性，并且也可以按照增量的方式对联邦企业架构进行循序渐进的开发和维护。
- 采用相同的架构模型对各个架构片段进行描述可以提高各个架构片段开发的标准性，并且不同架构片段之间的沟通也更加通畅，例如通用性架构片段对各个具体业务领域架构片段的支持和融入将变得非常容易。
上述模型表达了FEAF针对开发和维护企业架构的行为和流程在最高层次的抽象。为了进一步描述这一企业架构开发和维护过程，FEAF还通过四种粒度（上述模型为最粗粒度的描述）对其进行了更加详细的阐述。需要注意的是，在这四种描述粒度中前三种是针对整个企业架构开发和维护过程进行逐级深入的描述，而第四种粒度只是针对架构模型内容方面做了更加细致的种类划分。
基于前述关于FEAF第一粒度层次的描述，在第二粒度层次中原来模型中的架构驱动力、当前架构、目标架构以及架构模型的内容被进一步从业务和设计两个方面进行了细化：
FEAF第二层粒度示意图
在第二粒度层次的细化中，业务方面代表着企业业务能力方面的内容，而设计方面则代表用于实现企业业务能力的技术方面的内容：
- 架构驱动力细化为业务驱动力和设计驱动力两个方面：
- 业务驱动力代表着联邦政府的核心业务需求，例如公众访问需求、Clinger-Cohen法案对架构开发的要求、其他新法案要求电子化访问或者电子签名的使用，以及关于政府行为的各种创新。
- 设计驱动力代表用于实现联邦政府业务需求的各种革新方法，例如使用Internet。
- 当前架构的内容也被从业务和设计两个层面进行了划分：
- 当前架构的业务层面代表了在当前技术能力支持下企业目前的业务需求。
- 当前架构的设计层面代表了用于实现当前业务需求的数据、应用和技术方面的内容。
- 目标架构的内容也被从业务和设计两个层面进行了划分：
- 目标架构的业务层面代表了在未来技术能力支持下的企业未来的业务需求。
- 目标架构的设计层面代表了用于支持未来业务需求的数据、应用和技术方面的内容。
- 架构模型包含了用于描述架构内容的各种架构制品。在第二粒度层次的细化中，架构模型的内容也被分为业务模型和设计模型：
- 业务模型为在架构驱动力推动下出现的各种业务需求进行建模。
- 设计模型为支持业务需求而必须的数据、应用和技术进行建模。
接下来，FEAF采用了第三粒度层次对企业架构的开发和维护过程模型进行了最后一个层次的细化。经过这个层次的细化，FEAF表现如下：
FEAF第三层粒度示意图
在第三粒度层次的细化中，组成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）：应用于各种操作系统、平台以及硬件系统等信息技术基础设施上的各项标准。
与上面的三个细化粒度不同，FEAF在最后一个粒度层次的细化中仅是针对架构模型的内容来进行的。在这个细化层次中，FEAF通过借鉴Zachman框架的内容将架构模型的内容进一步细分如下：
| 视角 | 数据架构 | 应用架构 | 技术架构 |
| |
| 规划者 （目标和范围） | 业务对象列表 | 业务流程列表 | 业务地点列表 | 业务架构模型 | |
| 拥有者 （企业模型） | 语义模型 | 业务流程模型 | 业务物流系统 | ||
| 设计师 （信息系统模型） | 逻辑数据模型 | 应用架构 | 系统空间部署架构 | 设计架构模型 | |
| 建造者 （技术模型） | 物理数据模型 | 系统设计 | 技术架构 | ||
| 分包商 （详细规范说明） | 数据定义、字典 | 执行方案 | 网络架构 | ||
|
| 数据架构模型 | 应用架构模型 | 技术架构模型 | ||
与Zachman框架不太一样，FEAF只采用了Zachman框架中的前三列的内容，将在第三个层次中细化出来的业务架构模型、数据架构模型、应用架构模型和技术架构模型分别按照不同参与者的视角进行了更加详细定义。在上面的架构模型定义表格中：
- 业务架构模型被进一步细化，包括了规划者视角下的业务对象列表、业务流程列表、业务地点列表，以及拥有者视角下的语义模型、业务流程模型和业务物流系统。
- 数据架构模型的内容被细化为逻辑数据模型、物理数据模型，以及数据定义和字典。
- 应用架构模型的内容被细化为应用架构、系统设计和执行方案。
- 技术架构模型的内容被细化为系统空间部署架构、技术架构和网络架构。
由此可见，作为用于描述组织核心任务的业务架构模型，其主要关注者就是承担规划者和业务拥有者角色各个干系人，他们所关注的范围包含了数据、应用和技术等所有方面，只不过相对于下面用于支持业务的参与者来说，他们对于这三方面的描述角度是站在业务相关的立场上的，因而业务架构模型与从属于设计架构模型的数据、应用和技术架构模型并不是一个平行的层次关系，而是不同角色的干系人针对相同事物在不同角度的所看到的不同视图。相对于业务架构模型与设计架构模型这两者根据视角的不同而采取的水平划分方法，对于设计架构模型的细化采取的就是垂直划分了，即从数据、应用和技术这三个方面对设计架构模型进行划分，并且在每个划分出来的模型区域中又根据设计师、建造者以及分包商所具备的视角分别制定更加详细的模型制品。
除了对架构模型内容的细化，FEAF还通过借鉴企业架构规划技术（EAP，Enterprise Architecture Planning）为业务架构模型的建立提供了方法。企业架构规划是指为利用信息支持业务而定义架构的过程，以及用来实现这些架构的规划。（原文：EAP is the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures）。EAP可以看作是关于数据、应用和技术的一张高层次（业务和管理视角）蓝图，并借此保证他们之间的协调发展（alignment）。具体到FEAF，EAP为上面的FEAF架构模型中的业务架构模型（第一和第二行内容）提供了一套实现方法。在CIO委员会的 FEAF文档中，EAP的作用表现如下：
EAP在架构模型中的作用
与Zachman框架将关注点放在架构内容描述上不一样，EAP所关心的是对信息技术与业务的相互校准过程进行规划和管理，因而EAP所采用的是不同于具体设计和实现的高层次的视角。
6128
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
