企業架構如何實施的簡介（TOGAF深度好文）

時間 2019-11-05

原文原文鏈接

IT不只是開展業務的手段，並且正在迅速演變爲業務，IT績效會直接影響企業的盈利能力，但不少企業並無適時或充分的讓IT組織參與業務的規劃和決策過程，沒有給予在規劃和IT決策過程當中考慮的安全性、可擴展性、集成問題等IT問題足夠的重視。數據庫

複雜性驅動改變

傳統的應用集成方式存在諸多弊端，僅僅依靠在兩個數據庫中傳遞數據或者相互之間調用接口的模式很難解決企業的總體集成問題。不管是在理論上或是實際中，這樣的集成方式註定意味着項目的失敗。安全

僅僅從技術角度去思考集成系統只能是說是技術實現手段，但要真正發揮 IT 的價值，技術人員必須從技術架構視角提高到業務架構視角，從企業架構規劃開始考慮 IT 和架構的融合，不只解決集成問題，更能能從根本上改善 IT 帶來的價值。架構

企業架構是承接企業業務戰略規劃與信息化建設之間的橋樑，是企業信息化的核心。企業架構中 97%是業務，3%是 IT 技術，那麼企業架構究竟是由哪幾部分組成的呢？如今又有哪些企業架構方法？咱們又應該選擇哪一個企業架構方法？選擇以後又該具體如何去作呢？框架

下面我簡要說明一下企業架構實施落地的幾個步驟。工具

企業架構理念和知識工具的導入

IT系統若是不能知足商業需求，那將是大大的浪費，而業務過程沒有相應的IT支持，效率很難提升。企業架構的目標是經過IT投資獲取最大的商業價值，它是一種高層次的企業視野，聚焦與組織的IT架構和業務架構之間。post

首先咱們會給客戶進行四天的企業架構培訓，快速準確的導入企業架構理念和知識工具，讓架構工做組全部人員對企業架構有一個統一的認識，保證架構工做開展前的準備工做有效。學習

那架構工做組須要包含哪些人呢？不一樣企業架構工做組成員組成可能不同：翻譯

摘自《BangEA實踐公開課》講義設計

架構實施範圍不一樣也會形成工做組成員的不一樣，例如只是對車間管理進行EA設計，那所涉及的成員和整個企業的EA設計是不同的。

架構現狀分析

摘自《BangEA實踐公開課》講義

不少企業沒有進行過統一的企業架構，即便有的話，也是各類架構獨立存在，不能達到統一規劃，加上各子業務部門本身進行信息化工做形成了企業應用豎井，致使集成性差而不能有高效的信息化，以及變動能力差而IT不能跟上業務的腳步等衆多IT和業務不能對齊的問題。

摘自《BangEA實踐公開課》講義

若是你常常和軟件系統打交道，那麼你可能會發現軟件開發過程當中其實存在幾個重要的斷溝（GAP）。

1. 業務架構到技術架構的不一致

a.業務架構是一撥人作，技術架構師另外一撥人作，結果作業務架構時缺乏技術架構的考慮，而技術架構缺乏服務於業務的意識，最終沒有爲業務服務。弄到最後業務架構和技術架構並不能很好的結合起來，致使還須要不少適配或反覆工做。

b.還有一種狀況是，業務架構作完以後扔給技術架構來實現，可是業務架構提供的東西並不全面，不能提供技術架構的輸入，致使溝通效率極其低下。

2. 業務架構到業務需求的不一致

a. 有些公司雖然崗位分的清楚，可是方法並不清楚。業務架構是一套方法，需求分析是一套方法，甚至於沒有方法，而是靠着我的能力去作，結果致使架構和需求交付物是獨立的，業務架構的東西不能順利轉移到需求階段

b. 還有時候一我的就負責產品的業務，架構和需求一塊兒作，這時候沒有方法的指導，其實很容易迷失在業務細節。過早的進入業務細節對於產品來講是及其危害的，由於產品架構還未明晰時進入細節只會浪費時間致使重心偏離方向。

3. 業務架構和實現的不一致

開發產品時，開發問一句，」作這個對系統有什麼價值？」結果發現需求根本沒法追溯回系統的價值點上，有時連需求人員都不知道爲何作了這個功能。若是產品生命週期較長，中間換了好幾撥人來作這個產品了，那麼不只是需求文檔不能追溯，就是靠口頭講也講不清。

a. 業務架構採用的是業務語言，而技術實現採用的技術語言，二者不是同一個語言，很難作到順利過渡，還須要再一次翻譯，有時候甚至在實現階段根本不看業務架構出來的東西

b. 不多有開發人員清楚產品的業務架構，那麼如何可以作出好的產品來？

其實業務架構和業務需求自己就不衝突，二者只是處在一個事物在不一樣層次的東西。架構關注的是更全面、歸納、組織方面的東西，而需求關注的是用戶關心的業務細節，業務需求是業務架構的進一步分析。可是不少企業在進行企業架構規劃時，殊不知道如何區分這些，致使業務人員叫苦不迭。

這些差距還不是最重要的，還有更大更重要的一個差距，就是戰略與IT的差距，這個能夠看以前我寫的一篇《企業戰略和企業架構的關係？》

從上面說明能夠看出主要問題，現實中產品開發存在的隱性問題其實還有更多而且很嚴重的，我也都經歷過。而解決這些問題就必須作到如下幾點：

找到一個指導頂層架構的方法和框架
結構化架構交付物纔有可能把架構知識轉移到架構遷移實施階段
有一個業務開發平臺來集成業務架構、技術架構和開發框架

而這個也正是企業架構的意義。爲了解決IT與業務一致性問題，企業架構的導入和落地須要三個方面的支撐：指導企業架構工做的方法論、進行企業架構描述的架構語言，以及企業架構落地到應用開發的平滑過渡。

摘自《BangEA實踐公開課》講義

企業架構框架和方法

有不少不一樣類型的企業架構框架方法，由於TOGAF通用性較強，近幾年發展也不錯，應用也逐漸普遍，其完整性和實用性都比較高，因此咱們在諮詢中使用TOGAF爲客戶進行架構規劃。

TOGAF有一個ADM架構開發方法，它是一個可靠的、行之有效的方法，是TOGAF的關鍵。

摘自《BangEA實踐公開課》講義

TOGAF還提供了一個詳細的架構工件模型，包括交付物、交付物的工件和架構構建塊，能夠給予咱們更多指導。

摘自《BangEA實踐公開課》講義

雖然TOGAF9已經提供了內容框架，但框架自己並無告訴你太多如何具體去作架構的細節，大多時候咱們要借鑑已有的一些模型或者方法，例如PCF、SCOR、CBM等。具體設計方法等也須要本身去拓展學習，你們也能夠去學習咱們IT幫的BangEA方法，更多內容能夠購買EA2020講義。EA2020講義中聚集了以前只會在內訓課中講到的內容，能夠說是知識+實踐的一個大合集。

摘自《BangEA實踐公開課》講義

企業架構語言

企業架構是頂層設計，因此咱們不能沿用開發階段的UML等語言來描述，也不能簡單的使用Viso隨便拖放一些圖例，在諮詢中，咱們給企業導入企業架構語言ArchiMate，固然每一個企業也可在此基礎上擴展本身的模型。

咱們以某保險公司爲例，看看使用ArchiMate作出的一個分層視圖：

摘自《BangEA實踐公開課》講義

這是應用組件視圖：

摘自《BangEA實踐公開課》講義

業務開發平臺

這個在諮詢過程當中只作建議，更多須要結合企業的開發能力而定如何實施。

過程交付物示例和簡要說明

企業架構適用於大型企業，也一樣試用去中小型企業，關鍵點不在於組織大小，而是系統是否複雜，企業是否須要敏捷，是否須要使用IT來幫助你構建企業將來的能力。

基於不一樣規模的企業，業務複雜度天然不同，因此諮詢過程也是都不同的，可是一些方法和步驟仍是相同的，下面咱們簡單來看看其中一些過程交付物和簡要說明，以便對未接觸過企業架構的推進者有一個初步的認識。

在企業架構預備階段，核心之一是肯定企業的範圍：

摘自《BangEA實踐公開課》講義

以及肯定各架構原則

摘自《BangEA實踐公開課》講義

願景階段需肯定企業核心能力

摘自《BangEA實踐公開課》講義

並在核心能力上進行熱點分析

摘自《BangEA實踐公開課》講義

以及改進分析

還須要肯定績效衡量指標

摘自《BangEA實踐公開課》講義

在業務架構階段的流程設計時，制定統一的流程層級和流程分類十分重要

摘自《BangEA實踐公開課》講義

在業務架構階段，核心是要作高階流程分析

摘自《BangEA實踐公開課》講義

通過業務流程分析以後，就能夠去作信息系統架構了。信息系統架構主要作實體模型以及應用組件設計。

摘自《BangEA實踐公開課》講義

技術架構除了部署設計以外，還有技術架構選型，以外還有一個重要的是須要進行核心技術梳理

摘自《BangEA實踐公開課》講義

架構完成以後，開始進入項目組合管理

摘自《IT項目管理》講義

到這一步，一個充分支持業務的架構纔算初見雛形。

不要誇大IT的做用

IT信息化是幫助企業運營的，而運營執行的是戰略，從這個前後順序來看，那就是IT是在戰略規劃以後，並且這是由兩撥不通技能要求的團隊來完成。咱們不能把IT過高估了，他們並非無所不能的，我倒不是說軟件企業沒有這種能力，只是術業有專攻，企業不能把一個管理上的問題直接簡單轉換成一個IT問題來解決，不然獲得的解決方案也必定是一個IT方案，而不是解決管理的方案。我認爲管理問題仍是經過管理的方式來解決更好些，該作企業戰略諮詢的還得作諮詢，該本身思考業務的還得本身規劃，IT相對這些來講，更向是一個戰略執行的工具而已，不能本末倒置，IT工做的輸出絕對不會是戰略，不然容易出漏子的。戰略管理必定要由富有經驗的企業戰略專家團隊來完成，而IT系統完成也必定須要專業的團隊來完成，軟件開發商不能幫你作這些事，你須要能對企業IT信息化作總體規劃的人。