美國聯邦政府可以說是企業架構應用的先行者和最大倡導者。通過企業架構的發展歷史我們可以看出，早在上世紀九十年代以來，美國軍方就對這種全域性性的資訊共享的理論開始了研究，並開發出符合其特色企業架構框架理論（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還通過四種粒度（上述模型為最粗粒度的描述）對其進行了更加詳細的闡述。需要注意的是，在這四種描述粒度中前三種是針對整個企業架構開發和維護過程進行逐級深入的描述，而第四種粒度只是針對架構模型內容方面做了更加細緻的種類劃分。