業務架構這個詞大家時常聽到，但是能解釋得清楚的卻不多，撩撩度娘，你就會發現，不少人問及業務架構和應用架構的關係，聊天時，也常有人問起業務架構師和產品經理什麼區別？業務架構分析和需求分析什麼區別？其實為了寫這篇文章，我把《軟體工程》、《軟體系統架構》、《系統分析與設計》都翻了，這些經典教材確實沒講過業務架構這件事；我把《聊聊架構》也翻了，發現其中的討論有解釋到業務、架構和技術的關係，但是也沒有特別強調業務架構。
其實，業務架構這個詞並不新，它隱藏在企業架構（EA）中。企業架構是上世紀 80 年代的產物，其標誌就是 1987 年 Zachman 提出的企業架構模型，該模型按照“5W1H”，即 what（資料）、how（功能）、where（網路）、who（角色）、when（時間）、why（動機）六個維度，結合目標範圍、業務模型、資訊系統模型、技術模型、詳細展現、功能系統六個層次，將企業架構分成 36 個組成部分，描述了一個完整的企業架構要考慮的內容，詳圖如下：
Zachman 模型雖然沒有明確提出業務架構這個概念，但是已經包含了業務架構關注的一些主要內容：如流程模型、資料、角色組織等，既然沒有提出業務架構概念，自然也就沒有包含構建方法，所以，Zachman 模型應該算是業務架構的啟蒙，同時，它也表明了這一工具或者技術的最佳使用場景——面向複雜系統構建企業架構。
1995 年，大名鼎鼎的 TOGAF 登場了，這個在企業架構市場中據說（2009 年統計）佔了半壁江山的架構模型明確提出了業務架構的概念。TOGAF 將企業定義為有著共同目標集合的組織的聚集。例如，企業可能是政府部門、一個完整的公司、公司部門、單個處 / 科室，或通過共同擁有權連線在一起的地理上疏遠的組織鏈。TOGAF 進一步認為企業架構分為兩大部分：業務架構和 IT 架構，大部分企業架構方法都是從 IT 架構發展而來的。業務架構是把企業的業務戰略轉化為日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織結構、地域分佈等內容。TOGAF 強調基於業務導向和驅動的架構來理解、分析、設計、構建、整合、擴充套件、執行和管理資訊系統，複雜系統整合的關鍵，是基於架構（或體系）的整合，而不是基於部件（或元件）的整合。TOGAF 還提供了一個詳細的架構工件模型：
其中可以明確看到業務架構階段的交付物。相信很多對架構有興趣的朋友都認真學習過 TOGAF 模型，此處不再贅述。
TOGAF 之後，又先後誕生了 FEA（聯邦企業架構）和 DODAF（美國國防部體系架構框架）。前者的體系由五個參考模型組成：績效參考模型（PRM）、業務參考模型（BRM）、服務構件參考模型（FRM）、資料參考模型（DRM）、技術參考模型（TRM），該方法應用於美國電子政務領域，著眼於跨部門、跨機構提升業務效率，解決重複建設、資訊孤島等問題，很具有“企業級”理念，雖然沒有明確的業務架構定義，但是很好地應用了業務架構的思維。後者體系挺複雜的，8 個視點 52 個模型，但是實用性不錯，美國國防部和一些企業在用，詳細內容如下：
其中能力視點和作戰視點就是我們做企業時關注的業務部分。這兩個模型網上有相關資料，感興趣的話可以自行查閱。
通過尋根溯源，可以發現，即便從 TOGAF 算起，業務架構這個詞也有 20 多年的歷史了，但是在開發人員中，業務架構顯然沒有需求分析的概念明確，業務架構師也遠不如產品經理常見。作者所在單位曾經實施了一個長達數年的企業級轉型專案，其中有明確的業務架構組織，但是，每每與技術人員討論，他們也常覺得業務架構有點兒“虛”。細究其原因，可能有如下幾點：
1.用得少。原有的單體式或者豎井式開發依然是大家更經常採用的專案構建方法，而這種開發基本上沒有橫向視角，所以無需強調業務架構，通常的產品分析或者需求分析足以滿足開發需要；
2.難設計。業務架構，特別是大型企業這種錯綜複雜的業務架構，說起來容易做起來難，業務架構對戰略的分解、業務架構自身的整合與標準化、到 IT 設計的過渡都有不少坑，業務越複雜越寬泛就越難駕馭，因此，即便做過業務架構設計的企業，也有不少將業務架構設計保持在高階狀態，有點兒“虛”；
3.易跑偏。施工期間由於客觀因素可能導致實施對業務架構的偏離，這種偏離如果沒有及時糾正或者調整架構，累積久了會造成業務架構的失真，會變“虛”；
4.難維護。少數扛過了業務架構落地困難期的企業，也會由於感受到維護架構的難度而心生放棄，從而降低了對業務架構的評價。
其實，業務架構從誕生之初就很清楚地定義了自己的使命：面向複雜系統構建。也就是說，業務架構同其他架構一樣，目的也是要降低複雜度，更好地規劃系統，因此 TOGAF 是將業務架構歸屬於 IT 戰略部分。但是從本人的實踐經驗看，業務架構不僅具有上述作用，其更突出的影響是對參加過業務架構設計工作的業務人員的影響，他們的邏輯思維能力、結構化能力、企業級觀念和意識都有明顯的改變，所以，應當將業務架構從 IT 戰略中獨立出來，更多面向業務人員，以充當業務與技術之間的橋樑。當然，業務架構真正要承擔起這一職責，還需要改進、簡化業務架構設計方法，對業務人員更友好，並且堅持使用業務架構方法做企業級需求管控，否則，熵增一定會將已經建好架構秩序迴歸混沌狀態。
我本人邀約各大BATJ架構大牛共創Java架構師社群群，（群號：673043639）致力於免費提供Java架構行業交流平臺，通過這個平臺讓大家相互學習成長，提高技術，讓自己的水平進階一個檔次，成功通往Java架構技術大牛或架構師發展
為什麼某些人會一直比你優秀，是因為他本身就很優秀還一直在持續努力變得更優秀，而你是不是還在滿足於現狀內心在竊喜!
合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
希望此文能幫到大家的同時，也聽聽大家的觀點。歡迎留言討論，加關注，分享你的高見！持續更新！
To-陌霖Java架構
複製程式碼分享網際網路最新文章 關注網際網路最新發展