在APP開發中，業務架構這個詞大家時常提到，但是能解釋得清楚的卻不多，也常有人問起業務架構師和產品經理什么區別？業務架構分析和需求分析什么區別？在APP開發中如何做好業務架構。

其實，業務架構這個詞并不新，它隱藏在企業架構（EA）中。企業架構是上世紀 80 年代的產物，其標志就是 1987 年 Zachman 提出的企業架構模型，該模型按照“5W1H”，即 what（數據）、how（功能）、where（網絡）、who（角色）、when（時間）、why（動機）六個維度，結合目標范圍、業務模型、信息系統模型、技術模型、詳細展現、功能系統六個層次，將企業架構分成 36 個組成部分，描述了一個完整的企業架構要考慮的內容。

Zachman 模型雖然沒有明確提出業務架構這個概念，但是已經包含了業務架構關注的一些主要內容：如流程模型、數據、角色組織等，既然沒有提出業務架構概念，自然也就沒有包含構建方法，所以，Zachman 模型應該算是業務架構的啟蒙，同時，它也表明了這一工具或者技術的最佳使用場景——面向復雜系統構建企業架構。

TOGAF架構模型明確提出了業務架構的概念，TOGAF 將企業定義為有著共同目標集合的組織的聚集。例如，企業可能是政府部門、一個完整的公司、公司部門、單個處 / 科室，或通過共同擁有權連接在一起的地理上疏遠的組織鏈。TOGAF 進一步認為企業架構分為兩大部分：業務架構和 IT 架構，大部分企業架構方法都是從 IT 架構發展而來的。業務架構是把企業的業務戰略轉化為日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織結構、地域分布等內容。TOGAF 強調基于業務導向和驅動的架構來理解、分析、設計、構建、集成、擴展、運行和管理信息系統，復雜系統集成的關鍵，是基于架構（或體系）的集成，而不是基于部件（或組件）的集成。

TOGAF 之后，又先后誕生了 FEA（聯邦企業架構）和 DODAF（美國國防部體系架構框架）。前者的體系由五個參考模型組成：績效參考模型（PRM）、業務參考模型（BRM）、服務構件參考模型（FRM）、數據參考模型（DRM）、技術參考模型（TRM），該方法應用于美國電子政務領域，著眼于跨部門、跨機構提升業務效率，解決重復建設、信息孤島等問題，很具有“企業級”理念，雖然沒有明確的業務架構定義，但是很好地應用了業務架構的思維。后者體系挺復雜的，8 個視點 52 個模型，但是實用性不錯，美國國防部和一些企業在用。

業務架構這個詞也有 20 多年的歷史了，但是在開發人員中，業務架構顯然沒有需求分析的概念明確，業務架構師也遠不如產品經理常見。與APP開發人員討論，他們也常覺得業務架構有點兒“虛”。細究其原因，可能有如下幾點：
用得少。原有的單體式或者豎井式開發依然是大家更經常采用的項目構建方法，而這種開發基本上沒有橫向視角，所以無需強調業務架構，通常的產品分析或者需求分析足以滿足開發需要；
難設計。業務架構，特別是大型企業這種錯綜復雜的業務架構，說起來容易做起來難，業務架構對戰略的分解、業務架構自身的整合與標準化、到 IT 設計的過渡都有不少坑，業務越復雜越寬泛就越難駕馭，因此，即便做過業務架構設計的企業，也有不少將業務架構設計保持在高階狀態，有點兒“虛”；
易跑偏。施工期間由于客觀因素可能導致實施對業務架構的偏離，這種偏離如果沒有及時糾正或者調整架構，累積久了會造成業務架構的失真，會變“虛”；
難維護。少數扛過了業務架構落地困難期的企業，也會由于感受到維護架構的難度而心生放棄，從而降低了對業務架構的評價。

其實，業務架構從誕生之初就很清楚地定義了自己的使命：面向復雜系統構建。也就是說，業務架構同其他架構一樣，目的也是要降低復雜度，更好地規劃系統，因此 TOGAF 是將業務架構歸屬于 IT 戰略部分。應當將業務架構從 IT 戰略中獨立出來，更多面向業務人員，以充當業務與技術之間的橋梁。當然，業務架構真正要承擔起這一職責，還需要改進、簡化業務架構設計方法，對業務人員更友好，并且堅持使用業務架構方法做企業級需求管控。

未來，業務不再僅僅是業務，技術也不再僅僅是技術，誰先實現思維方式的改進，誰就能贏得轉型的先手，而業務架構能力可以在這方面發揮關鍵作用。