大型2b系統複雜度很高，目前業界一般會被拆分成業務需求、技術實現兩部分加以討論。基於對大量失敗專案失敗原因的分析統計：導致大型2b專案失敗的因素，需求分析、邏輯設計相關問題佔到80%以上，而由純技術因素導致失敗的情況幾乎微乎其微。而需求分析經常遇到的乙個問題是，懂業務的人不懂技術，懂技術的人不懂業務，業務邏輯實現與技術實現混雜在一起導致雙方的溝通出現大量不確定因素，導致需求未必理解一致；實現規劃也未必一致。決策層需要在專案開始前做出決策，需要判斷乙個系統規劃是否具備可行性，其中無技術背景人員可能不清楚實施方案是否可行。通過一些深度分析，我們提出了「業務架構」這個概念來解決這個問題，那麼什麼是業務架構？乙個業務架構應該包括哪些內容？通過怎樣的路徑去完成乙個業務架構呢？ 以下是筆者對一段時間的業務架構工作的思考和總結。
本文試圖給出:
它是一種架構層面的」大圖「，，便於快速理解乙個複雜系統，核心需求如何實現，整個體系如何整合，滿足關鍵需求的關鍵機制是怎樣的？關鍵系統性的內部能力和支撐機制有哪些？它是對複雜系統的一種高度抽象。通過這樣的描述，完成了系統的問題定義和領域劃分。
同時業務架構也提供最基本的設計，
根據特點，可以看到它的優點是：
對比一下，先前的拆分，無技術背景的人是難以參與到實現討論中來的，管理層無法確認是否靠譜，而業務架構在關鍵點上對無技術背景人員實現了可見；抓住重點，對於非重點內容，無需通過這種方式去溝通；高度抽象，乙個具備通用性的元素可以在多個地方使用，從而提高了交付速度。
一般在解決方案文件或者分析設計文件中，包括了業務邏輯層設計，需要描述一下和業務架構的區別。
2.2.2.1 服務範圍
2.2.2.2 表達內容需求說明書和業務架構有不同的編寫目的，所以差別比較大。
\需求說明書
業務架構
內容功能性需求
功能性需求
非功能性需求
邏輯實現
形式詳細描述
抽象、彙總
範圍全部（需求）
重點（內容）
目的指導開發、檢查驗收等
描述重大架構元素，指導決策
總體來說，需求說明書，重在寫「需求」；業務架構，重在寫「實現「。在描述功能性需求的部分有一部分重疊的地方，但是對功能性需求的描述的目的和手段完全不一樣，功能性需求是需求說明書的主體和關鍵；而在業務架構中，只是整理典型功能性需求，存在是為了引出架構元素的設計和後續實現草案。
提供一種概念性的視角去觀察系統架構，用粗線條描述一種概念級別的重大設計。用來描述系統中最基本最重大的設計，幫助閱讀者快速理理解乙個複雜系統。一般來說業務架構實現為一系列業務架構圖和描述說明文字。
業務架構表述了乙個系統的關鍵架構元素和他們之間的關係，即描繪了該系統的輪廓，描述關鍵架構，表達了元素之間的關係，由此，讀者可以基本了解乙個複雜系統的構成與原理。
業務架構包括業務架構圖和架構元素描述兩部分內容。
用於對業務架構圖中包括的元素進行描述，一般採用固定格式
一般採用crc-r （component-responsibility-collaborator-rationale）格式描述關鍵架構元素,crc-r採用以下固定格式：項內容
元素名稱（comonent）
功能職責（responsibility）
協作關係（colaborators）
解釋說明（rationale）
2.4.2.1 元素名稱
元素的名稱，要求明確清晰易理解。
2.4.2.2 功能職責
描述該元素的角色、承擔的職責，要實現的特徵。
2.4.2.3 協作關係
2.4.2.4 解釋說明
分析為什麼抽象出這個元素、該元素的定位、以及關鍵功能的說明等，讓閱讀者清楚寫作者的意圖。
對一些通用機制，比如安全、效能等進行支撐的機制進行描述。架構機制和重大架構元素的區別在於，架構機制適用範圍更廣，幾乎涉及整個系統，或者主要機制。
架構元素的設計本質做出一些草稿性構思，要求能形成映像、能傳基本達觀念。一般來說要包括：
這部分內容要求不涉及技術，無技術背景者能看懂。
其中橙色表示業務架構文件需要包括的內容。
首先不能憑空寫業務架構，是從需求中來。
3.1.1 需求採集
重大需求只關注核心且屬於架構層面的需求。如果有需求文件、prd文件，那麼很大程度可以從中提煉；如果還沒有，可以自己找客戶或者真實需求方調查。一般來說，需要業務架構師加入需求分析團隊深入了解需求。
3.1.2 用例
整理用例圖或者用例，這部內容無需包括到業務架構中，便於理解。
整理一張圖，包括所有業務模型。
3.2.1 職責（responsibility）
描述該業務元件負責完成的功能。
3.2.2 關係（relationship）
描述該業務元件和其它業務元件之間的關係。
3.2.3 分析解讀（rationale）
分析該業務元件設計的原因
3.2.4 設計草案（可選）
在crc-r之後，提供一些方法對內容進行描述
除模型以外，還有一些基礎機制，都需要使用，也需要描述到文件中。
完成的業務架構需要進行討論、驗證。架構是平衡的藝術。
再談企業架構 業務架構
再談企業架構 業務架構 人月神話 前面已經談到過企業架構的層次和維度方面的問題，在這裡簡單談下企業架構中的業務架構和業務價值鏈方面的內容。隨著企業不斷的發展和演進，各個業務功能單元會逐步成熟，也會形成多個端到端的流程，這些流程涉及到工程專案管理，鏈，財務，人力資源，產品研發等多個方面的內容。我們再進...
業務 技術和架構
這兩天準備要接手天津商行的專案。但是在接手的過程中，對整個專案的理解卻是非常的困難。最大的問題，就是對業務的不理解。天津商行的這個專案不大，核心的業務就是日結，及其圍繞在日結之周圍的一些相關業務。其實也並不是特別的複雜，但是轉來轉去，開賬閉賬，憑證科目什麼的，的確對乙個財務的門外漢是異常的頭痛。雖然...
業務架構優化之路
im系統，例如qq或者微博，每個人都讀自己的資料 好友列表 群列表 個人資訊 微博系統，每個人讀你關注的人的資料，乙個人讀多個人的資料。秒殺系統，庫存只有乙份，所有人會在集中的時間讀和寫這些資料，多個人讀乙個資料。例如小公尺手機每週二的秒殺，可能手機只有1萬部，但瞬時進入的流量可能是幾百幾千萬。又例...