企業架構

出自 MBA智库百科(https://wiki.mbalib.com/)

企業架構(Enterprise Architecture)

　　早在1987年，John Zachman就提出： “為了避免企業分崩離析，信息系統架構已經不再是一個可有可無的選擇，而是企業的必需”。 從那時起，Zachman的企業架構理論就開始逐漸發展起來， 它現已成為許多大公司用來理解、表述企業信息基礎設施的一個直觀模型， 為企業現在的以及未來的信息基礎設施建設提供了藍圖和架構。

　　Zachman的企業架構是一個全新的模型，為企業信息基礎設施提供一種可以理解的信息表述。

　　Zachman沒有把企業的流程簡單視作一系列步驟，而是綜合考慮不同角色的不同觀點，提出了一個多視角、多維度的企業架構。

　　1.企業擁有者。

　　2.業務管理者。

　　3.系統分析者。

　　4.系統設計者。

　　5.系統建設者。

　　6.系統本身。

　　下表的各行內容即反映了不同角色的不同關註點（角度）。

　　Zachman同時承認每個角色均關註相同的信息類別（維度），即下表各列內容。

	數據（什麼？）	功能（怎樣？）	網路（哪裡？）	角色（誰？）	時間（何時？）	動機（為何？）
目標範圍	列出對業務至關重要的元素	列出業務執行的流程	列出與業務運營有關的地域分佈要求	列出對業務重要的組織部門	列出對業務重要的事件及時間周期	列出企業目標、戰略
業務模型	實體關係圖（包括M: M關係、N-ary關係、歸因關係）	業務流程模型（物理數據流程圖）	物流網路（節點和鏈接）	基於角色的組織層次圖， 包括相關技能規定、 安全保障問題。	業務主進度表	業務計劃
信息系統模型	數據模型（聚合體、完全規格化）	關鍵數據流程圖、 應用架構	分佈系統架構	人機界面架構（角色、數據、入口）	相依關係圖、數據實體生命歷程（流程結構）	業務標準模型
技術模型	數據架構（資料庫中的表格列表及屬性）、 遺產數據圖	系統設計： 結構圖、偽代碼	系統架構（硬體、軟體類型）	用戶界面（系統如何工作）、 安全設計	“控制流”圖（控制結構）	業務標準設計
詳細展現	數據設計（反向規格化）、物理存儲器設計	詳細程式設計	網路架構	屏顯、安全機構（不同種類數據源的開放設定）	時間、周期定義	程式邏輯的角色說明
功能系統	轉化後的數據	可執行程式	通信設備	受訓的人員	企業業務	強制標準

• 數據（什麼？）

• 功能（怎樣？）

• 網路（哪裡？）

• 時間（何時？）

• 角色（誰？）

• 動機（為何？）

• “企業”（Enterprise）是指由一整套可識別的、互為作用的業務功能構成的商業組織。 它有能力作為獨立實體經營運作。 根據這一定義，就應該存在企業內的企業。 只要企業內部的事業部門能夠獨立運作，它或許就可以被當作一個企業。 在這裡，這一企業概念也可以被看作為“擴展企業”（Extended Enterprise），它意味著企業架構框架也包括了企業與外部實體的相互關係。 例如： 供應商、商業伙伴和客戶。

• “架構”（Architecture）提供基礎框架， 它定義和描述了企業實現經營目的和商業願景的平臺。 “架構”可以被具體定義為： 與企業經營戰略、信息需求緊密相連的一整套原則、方針、政策、模型、標準以及流程，它結合企業未來發展方向，為企業各項解決方案的設計、選擇和執行提供指導。

　　企業架構可以分為兩大部分：業務架構和IT架構，大部分企業架構方法都是從IT架構發展而來的。

• 業務架構：是把企業的業務戰略轉化為日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織結構、地域分佈等內容

• IT架構：指導IT投資和設計決策的IT框架，是建立企業信息系統的綜合藍圖，包括數據架構、應用架構和技術架構三部分。

　　對比 RUP 和其他主要關註於實現的規程，企業架構領域原則上的關註點是企業範圍內的業務需求的識別、規範，及優先順序劃分，感覺它也是一個做企業信息化規劃的方法。我認為，做工具型產品和企業級產品有個差別，那就是做企業級產品需要由工具型產品的產品型公司向咨詢類的服務型公司轉型。

　　1. 業務流程的組織邏輯(包含所有信息和技術服務，流程)和IT基礎設施，反映了該公司運作模式的整合和標準化的需求 (MIT Center for Information Systems Research)

　　2. 概念藍圖，定義了一個組織的結構和運作。企業架構的意圖是確定組織如何能夠最有效的實現其當前和未來的目的 (SearchCIO.com)

　　企業架構如同戰略規劃，可以幫助企業執行業務戰略規劃及IT戰略規劃。在業務戰略方面，可使用TOGAF及其架構開發方法論（ArchitectureDevelopmentMethod/ADM）來定義企業願景/使命，目標/目的/驅動力，組織架構，職能及角色。在IT戰略方面，TOGAF及ADM詳細描述瞭如何定義業務架構，數據架構，應用架構，和技術架構，是IT戰略規劃的最佳實踐指引。企業架構是承接企業業務戰略與 IT戰略之間的橋梁與標準介面，是企業信息化規劃的核心。

　　源於90年代美國的企業架構框架，到目前已經衍生出多種企業架構框架，如DoDAF（美國國防部體系架構框架 The Department of Defense Architecture Framework）、TOGAF等。

　　有些人可能會問為什麼要做要做架構，直接拿來需求就做不就行了，以前做些小任務都是這樣的。就像搭個簡易狗窩不需要請設計師來專門做個設計，但是建個大廈必須設計一樣，我想對於不複雜的東西，你怎麼做我都覺得很正常，但是一旦業務複雜、處理麻煩時，必須有一個清晰的架構才能保證做出來的東西是正確的。

　　中國的大多數企業在進行IT投資時都會跳過企業架構這個環節而直接進入了IT項目的建設，這樣就會導致重覆投資、信息孤島等必然現象的出現。有時缺少規劃，也會發現很多開發的功能被打入冷宮，這裡列一個簡單例子：如hr系統中的HR服務台的一個功能，我填寫了一個問題，但是沒有回覆，估計這個功能就被打入冷宮了，這樣滿意度也就會下降了。

　　通過企業架構，我們可以達到：

• 企業內不同的人要對企業現狀（as－is）和企業願景（to-be)有一個整體的的理解
• 業務、信息、技術人員的共同願景，是理解、溝通的基礎
• 如果沒有一個清晰的架構，就不能保證爭取的決策和好的實現，EA是理解和實現企業IT建設的保障

　　TOGAF在國外的認知度很高，目前企業架構方法有很多，但TOGAF是最主流的，已經有超過15年的歷史。不僅有80％的福布斯( Forbes)全球排名前50的公司在使用，而且支持開放、標準的SOA參考架構。目前已得到國際主流廠商的推動，德國有SAP在推動，美國IBM、 HP、SUN等公司在推動，中國在企業架構方面並不是很成熟，以前討論多半集中在軟體架構或是單獨的系統架構，在02年才有一個企業架構出現。金蝶在TOGAF 8.1成熟之後，引進9.0，因為它包含對SOA的支持，所以這個也是金蝶選擇在這個時期把它導入的原因之一。金蝶加入The Open Group，希望能夠提升中國企業信息系統及業務架構的水平，並率領國內軟體產業參與國際標準的制定。對金蝶而言，引進TOGAF和Open Group的SOA參考架構及治理原則，將推動金蝶集團產品，開發過程及治理的國際化與標準化。未來金蝶ERP產品EAS、BOS及金蝶中間件等產品都將遵循TOGAF企業架構框架，架構開發方法論及SOA參考架構，以提升產品質量及全面SOA服務化。在金蝶產品獲得成功後，將建議金蝶用戶採Open Group的TOGAF及SOA標準。在2009年11月份上海的金蝶年度客戶大會及中國管理模式傑出獎頒獎典禮中，金蝶發佈了EAS 7.0新版本，這是中國第一款使用TOGAF企業架構框架規劃及SOA的ERP產品。

• 架構原則
  • 基於標準方法來做架構，如使用TOGAF架構方法
  • 說不清的不做
  • 沒人上層持久推動的不做
  • 達不成一致意見的不做

• 業務原則
  • 業務持續性（對業務發展有長遠計劃，不能只考慮近期實現範圍）
  • 業務通用性（業務是否可以作為一個公用業務架構）
  • 業務一致性
  • 合法

• 數據原則
  • 數據價值性>數據正確性>數據完整性
  • 數據積累分析需要規範化數據
  • 數據是安全的
  • 數據不只是可以共用的數據，還包含業務規則和策略

• 應用原則
  • 技術獨立性，不綁定到特定廠商
  • 易用
  • 模塊化設計

• 技術原則
  • 響應變化
  • 可擴展

　　 開發人員對於架構這個詞一定不陌生，但是我們說的架構只是產品開發中的技術相關架構，真正要做好一個產品，在技術架構之上還有其他一些架構，本篇介紹一下三類主要的架構：解決方案架構、業務架構和企業架構。有時候我們把視野拓寬一些，多鍛煉自己的大局觀，對自己的思維和技能都會有很大的提高。在《TOGAF 或非 TOGAF：在 RUP 之上擴展企業架構》中對比幾個不同的架構框架，讓我對什麼是架構更清晰了。我覺得不錯，所以給大家分享一下。

• 解決方案架構

　　解決方案架構是“技術性的”，它們的範圍內包括各種技術元素，如軟體、數據和 IT 基礎架構，這些領域都是由技術人員來處理 。

• 業務架構

　　業務架構在 90 年代作為單獨的領域出現了，業務架構包含過程及信息、組織和績效等方面內容

• 企業架構領域

　　企業架構領域原則上的關註點是企業範圍內的業務需求的識別、規範，及優先順序劃分，EA 路線圖可能比單路線解決方案包含更多內容（如上圖所示），這可能會形成多個、同時的實現。

　　EA 環境是全局性的，其視點是組織化的，而解決方案架構是具體到實現的。EA 主要用於企業分析、計劃和架構治理。

　　註意：來自解決方案架構規程中的一些主題（低層次的）不含在 EA 的範圍內，而許多附加的（大部分是更高層次的）主題加入了。還要註意的是關鍵的業務架構主題完整地包含於 EA 規程之中了。