文章目錄

• 一、FEAF
• • 1、FEAF的出現
  • 2、FEAF構成
  • • （1）Level 1
    • （2）Level 2
    • （3）Level 3——架構模型細化
    • （4）Level 4——業務架構模型細化（EAP方法）
• 二、企業架構實施指南
• • 1、企業生命周期
  • 2、企業架構過程
  • • （1）取得上層主管的認同和支持
    • （2）建立管理結構和控制
    • （3）定義架構過程和方法
    • （4）開發基線企業架構
    • （5）開發目標企業架構
    • （6）開發序列計劃
    • （7）使用企業架構
    • （8）維護企業架構
    • （9）控制與監督
• 三、淺談概念

現狀：隨著各個政府部門建立符合各自特點的企業架構框架并逐步實現各自企業架構，例如財政部（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等有名的企業架構框架標準并非強制讓人硬性照搬，相反鼓勵使用者根據自己企業或組織的需要對框架理論進行定制和裁剪，因而強行照搬從某一方面倒違反了標準的精神，并且采用這種強搬的方式進行企業架構建設，也往往會讓小企業望而卻步，其實不然。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的企业架构（三）——联邦企业架构框架（FEAF）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。