架構師書庫
企業級業務架構設計：
方法論與實踐
點選檢視第二章 點選檢視第三章
付曉岩 著
|第一部分|
業務架構基礎篇
業務架構并非軟體工程中新誕生的領域，但是提及的人卻很少。這個偶爾走進讀者視線的詞彙，經常帶着一種“花非花、霧非霧”的“朦胧感”，很多人對業務架構究竟在軟體設計中發揮了什麼作用、有什麼好處，以及業務架構和應用架構的關系、業務架構師和産品經理的差別等基本問題說不清、道不明。《軟體工程》《軟體系統架構》《系統分析與設計》等大家耳熟能詳的經典教材也很少提及業務架構這個概念，更不用說企業級業務架構了，目前市面上也幾乎沒有專門論述業務架構及其設計方法的書籍。本書作為一本企業級業務架構專述，将從業務架構的發展曆程、基本理念講起，讓讀者對業務架構有一個基本的了解。
|第1章|
業務架構的發展曆程
與軟體的發展曆史相比，業務架構的發展曆程其實并不算短，而且也具有幾個頗具影響力的架構設計理論。
1.1 Zachman模型
業務架構這個詞最初是隐藏在企業架構（Enterprise Architecture，EA）中的。企業架構是20世紀80年代的産物，其标志就是1987年Zachman提出的企業架構模型，該模型按照“5W1H”，即What（資料）、Where（網絡）、Who（角色）、When（時間）、Why（動機）、How（功能）6個次元，結合目标範圍、業務模型、資訊系統模型、技術模型、詳細展現、功能系統這6個層次，将企業架構分成36個組成部分，描述了一個完整的企業架構需要考慮的内容，如表1-1所示。
Zachman模型雖然沒有明确提出業務架構這個概念，但是已經包含了業務架構關注的一些主要内容：如流程模型、資料、角色組織等，既然沒有提出業務架構的概念，自然也就沒有包含建構方法，是以，Zachman模型應該算是業務架構的啟蒙，同時，它也表明了這一工具或技術的最佳使用場景—面向複雜系統建構企業架構。
1.2 TOGAF
1995年，大名鼎鼎的TOGAF登場了，這個在企業架構市場中占據了半壁江山的架構模型明确提出了業務架構的概念。TOGAF将企業定義為有着共同目标集合的組織的聚集。
例如，企業可能是政府部門、一個完整的公司、公司部門、單個處/科室，或者是通過共同擁有權連接配接在一起的地理上疏遠的組織鍊。TOGAF進一步定義企業架構分為兩大部分：業務架構和IT架構，大部分企業架構方法都是從IT架構發展而來的。業務架構是将企業的業務戰略轉化為日常運作的管道，業務戰略決定業務架構，其包括業務的營運模式、流程體系、組織結構、地域分布等内容。
TOGAF強調基于業務導向和驅動的架構來了解、分析、設計、建構、內建、擴充、運作和管理資訊系統，複雜系統內建的關鍵，是基于架構（或體系）的內建，而不是基于部件（或元件）的內建。TOGAF還提供了一個詳細的架構工件模型，如表1-2所示。
從表1-2中可以明确看到業務架構階段的傳遞物，這些内容也清楚地說明了業務架構在軟體工程中的位置。相信很多對架構有興趣的讀者都認真學習過TOGAF模型，此處不再贅述。
1.3 FEA和DODAF
在TOGAF之後，又先後誕生了FEA（聯邦企業架構）和DODAF（美國國防部體系架構架構）。前者的體系由5個參考模型組成：績效參考模型（PRM）、業務參考模型（BRM）、服務構件參考模型（FRM）、資料參考模型（DRM）和技術參考模型（TRM），該方法應用于美國電子政務領域，着眼于跨部門、跨機構提升業務效率，解決重複建設、資訊孤島等問題，相當具有“企業級”理念；雖然沒有明确的業務架構定義，但是很好地應用了業務架構的思維。後者體系比較複雜，共有8個視點52個模型，但是實用性不錯，據說美國國防部和一些相關企業都在使用，詳細内容如表1-3所示。
表1-3中的能力視點和作戰視點就是我們做企業架構時通常關注的業務部分。這兩個模型在網上都有相關資料，感興趣的讀者可以自行查閱。
1.4 沉吟至今
通過尋根溯源我們可以發現，即便是從TOGAF算起，業務架構這個詞也有20多年的曆史了，但是在開發人員中，業務架構顯然沒有需求分析的概念明确，業務架構師也遠不如産品經理常見。筆者曾就職的機關曾經實施了一個長達數年的、以企業級業務架構驅動的轉型項目，但是很多企業并沒有這樣的經曆，是以，每當與技術人員讨論至此，他們就會覺得業務架構有點兒虛，細究可能有如下幾點原因。
1.用得少
原有的單體式或豎井式開發依然是企業更常采用的項目建構方法，而這種開發基本上沒有橫向視角，是以無需強調業務架構，通常的産品分析或者需求分析即足以滿足其開發需要。
2.難設計
業務架構，特别是大型企業這種錯綜複雜的業務架構，說起來容易做起來難。業務架構對戰略的分解、業務架構自身的整合與标準化，到IT設計的過渡都存在不少陷阱，業務越複雜寬泛就越難駕馭。是以，即便是嘗試過業務架構設計的企業，也有不少是将業務架構設計保持在高階狀态，讓做過的人自己都覺得有點兒沒底氣。
3.易偏離
施工期間由于客觀因素可能會導緻實施對業務架構的偏離，這種偏離如果沒有得到及時糾正或架構調整，那麼累積久了就會造成業務架構的失真。
4.難維護
少數度過了業務架構落地困難期的企業，也會由于感受到維護架構的難度而心生放棄，進而降低了對業務架構的評價。
1.5 業務架構的定義
業務架構從誕生之初就很清楚地定義了自己的使命：面向複雜系統建構。也就是說，業務架構與其他架構一樣，其目的也是要降低複雜度，從更好地規劃和實作系統，是以TOGAF将業務架構歸屬于IT戰略部分。但是從筆者的實踐經驗來看，業務架構更突出的特點是影響了參加過企業級業務架構設計工作的業務人員，他們的邏輯思維能力、結構化能力、企業級觀念和意識都發生了明顯的改變，是以，應當将業務架構從IT戰略中獨立出來，更多地面向業務人員，以充當業務與技術之間的橋梁。當然，業務架構要想真正承擔起這一職責，還需要改進、簡化業務架構設計的方法，對業務人員更友好，并且堅持使用業務架構方法做企業級需求管控，否則，“熵增”一定會将已經建好的架構秩序回歸到混沌狀态。
說到這裡，本書也嘗試為業務架構提供一個簡單的定義：以實作企業戰略為目标，建構企業整體業務能力規劃并将其傳導給技術實作端的結構化企業能力分析方法。業務架構就其方法本身而言，既可以用于單個産品線或業務種類的領域級分析，也可以用于跨越産品線、業務領域的企業級分析；就價值而言，後一種顯然對企業具有更高的價值，更值得企業去嘗試、推廣。是以，本書如無特殊說明，使用“業務架構”一詞時多是指“企業級業務架構”。不同于一般基于業務訴求的需求分析或産品設計，業務架構的首要責任在于實作業務與技術的深度融合，在于打造能夠讓企業整體，尤其是業務與技術之間有效溝通的“通用語言”。
如今大熱的“中台”概念，說到底也是一種業務架構設計結果，是對企業能力的一種規劃，隻不過阿裡的實踐代表的是自下而上的積累方式，而業務架構設計通常是自上而下的規劃與演變。如果認真回顧軟體設計的發展曆程，那麼你一定可以發現，所謂的“中台”絕非是一種超越了“企業架構”這個概念的存在。是以，若想要深入了解“中台”，那麼多學習業務架構、軟體架構的曆史還是很有必要的。