有價值的東西是才值得我們投入時間和精力的，企業架構為什麽就值得我們投入時間和精力來學習呢？主要由以下兩方面原因：
1、 對公司而言，企業架構可以輔助企業完成業務及IT戰略規劃。在 業務戰略 方面，它定義企業的願景/使命、目標/目的/驅動力、組織架構、職能和角色。在 IT戰略 方面，定義業務架構、數據架構、應用架構和技術架構，是IT戰略規劃的最佳實踐的指引。企業架構是承接企業業務戰略與IT戰略之間的橋梁與標準接口，是企業信息化規劃的核心。
2、對個人而言，有助於職業的健康長遠發展，比如成為CIO，首席信息官通過指導對信息技術的利用來支持公司的目標，具備 技術和業務 過程兩方面的知識，常常是將組織的技術調配戰略與業務戰略緊密結合在壹起的最佳人選。
企業架構包含了四部分，BA（Business Architecture，業務架構）、DA（Data Architecture，數據架構）、AA（Applications Architecture，應用架構）、TA（Technology Architecture,技術架構）。企業架構由全局戰略規劃驅動，我們來看下戰略、BA、DA、AA、TA五者之間的關系。
如圖所示，戰略、BA、DA、AA、TA實際位於以下三個層次上：
這五者的核心關系，可以概況為以下幾點：
l 環環相扣，上層驅動下層，下層支撐上層。
通過上面的內容，我們知道了戰略，業務架構，方案架構的關系。下面我們看下實際工作中架構路線圖和實施規劃環節是如何操作的。
執行的要點是釘到崗位（左側），落到文檔（右側），細到機構調整、技術采購、項目研發等工作包。主要有以下環節：
這裏需要補充說明的壹點是，實施計劃不僅僅是從“架構藍圖到研發”的計劃，也是從“架構藍圖到IT與非IT的方方面面”。
對於業務架構，OMG業務架構組給了如下定義：
業務架構是企業治理結構、商業能力與價值流的正式藍圖。業務架構明確定義企業的治理結構、業務能力、業務流程、業務數據。其中，業務能力定義了企業做什麽，業務流程定義企業怎麽做。具體而言，就是：
我們分別從國外國內來了解壹下，業務架構出現的背景，便於我們更好的理解業務架構的使用場景， 業務架構是跨部門跨組織的業務需求，單個小系統的生命周期，根本就沒有業務架構環節。
跨系統規劃--業務架構在全球出現的背景
國外軟件系統經過長期發展，在經過多年實踐後，1962年，發表於哈佛商業雜誌的的《信息系統總規劃》這篇文章，拉開了跨部門、跨組織需求規劃的序幕。此後多年，IBM等企業進行了很多實踐。
1982年，IBM公布了業務系統規劃（Business System Planning,BSP）方法論。這是個重要事件，對業界產生了大而持久的影響。
此後多年，業務架構快速發展，如Togaf、FEAF等。
以上歷史告訴我們，業務架構脫胎於跨系統、重視跨系統需求。站在開發者的角度，業務架構就是跨部門、跨組織的業務需求。
信息孤島—業務架構在國內“火”起來的契機
國內有個現象，壹提到業務架構，就會大談信息孤島。這是為什麽呢？因為國內真正開始重視業務架構設計，就是從解決信息孤島的痛點開始的。
21世紀初，國內的信息化進程從部門信息化推進到了企業信息化。企業部門間的（集團子公司間的）協同聯動需求，帶動了IT信息系統間的信息***享和協同聯動需求—同時產生了信息孤島問題（財務、人力資源、采購、銷售、OA、CRM各自為戰）。
因為信息孤島所具備的三大弊端，促使業務架構在國內火了起來，以下是三大弊端：
那如何解決信息孤島的問題呢？
在壹系列系統分頭建設之前，先設計業務架構，定義統壹藍圖，這是根本。數據壹張圖、數據***享、流程打通、服務編排，都是圍繞統壹藍圖具體展開。
業務架構是跨系統的，那麽它和子系統的關系是什麽樣的呢？
圖中的大V、小V分別表示什麽呢？
大V部分，是總體方案的生命周期。在大V的需求階段，必須研究和定義清楚跨部門、跨組織的業務需求，這些需求往往是跨系統的。例如，客戶報修業務功能明顯需要呼叫中心系統、CRM系統、工單系統協同聯動，才能支持客服接聽電話、確認客戶資料、記錄報修內容、派遣維修工程師上門這壹連串操作。
小V部分，是某壹個系統的生命周期。在小V的需求階段，必須分析和定義清楚這壹個系統的需求，這些需求往往是系統內的。例如，CRM系統負責客戶資料管理。
綜上所述，方案級、子系統級這兩級生命周期是同時存在的。舉個典型的例子，某公司要做壹個ERP系統，他會怎麽做呢？
由於方案涉及的範圍廣、部門多，所以有必要做業務架構設計。這時，由業務架構師擔綱業務架構設計，並提交《業務架構書》。
假設主要涉及系統A的需求、開發、測試等。
這時需求分析員沖上去，負責《系統A需求說明書》，當然需求分析員要參考上遊的《業務架構書》整體約定。
註：這裏只所以說是假設，是因為實際操作中可能是實現某個業務功能需要同時開發系統A、系統B、系統C的部分功能， 並不是說壹期工程的所有功能必須隸屬於同壹個系統 。
假設主要涉及系統B的需求、開發、測試等。
這時這時需求分析員沖上去，負責《系統B需求說明書》，當然需求分析員要參考上遊的《業務架構書》整體約定。
業務架構要想成功，首當其沖的是，架構師要做正確的事，即在業務架構的實際工作內容上有充足的經驗，不能遺漏。
相反，業務架構師分析環節的缺失，意味著業務架構藍圖規劃項的缺失，影響從投資角色到方案設計，到實施規劃，在到IT工作包和非IT工作包識別等所有後續工作。
業務架構 = 業務功能 + 組織結構 + 業務流程 +業務數據
業務架構的實際工作內容有哪些呢？
業務架構的前身是1982年IBM發布BSP等跨系統規劃方法。所以，業務架構本質上是跨系統規劃。
但是，業務架構的內容遠遠超過了跨系統需求分析這個範圍，覆蓋跨系統業務架構藍圖規劃這個更大的範圍。究其原因，是業務架構必須發揮從戰略向實施過渡的橋梁作用—上街公司戰略， 下接IT實施和非IT實施 。
不錯，業務架構也涵蓋了非IT部分的藍圖！
我們來看下細化的業務架構實際工作模型。
就大的方面而言， 業務功能定義企業做什麽，組織結構定義誰來做，業務流程定義怎麽做，業務數據提供必要的支撐，因此，業務功能、組織結構、業務流程、業務數據四者，構成了業務架構藍圖的核心。
同時，商業模式揭示的是企業產品、企業核心資源、客戶、夥伴、渠道、成本、利潤之間的本質關系。商業模式這個現代工具，也是業務架構藍圖的必須規劃項。
就小的方面而言， 第壹，業務渠道在哪裏？組織結構是圍繞部門、角色、職能展開的，而組織結構、業務渠道、合作夥伴是緊密相關的。所以，業務架構師在梳理組織結構的同時，應結合渠道戰略和合作夥伴戰略，定義業務渠道規劃，定義合作夥伴規劃，這些都是業務架構藍圖的“壹等公民”。
第二，價值鏈在哪裏？價值鏈模型是對壹個企業所有生成經營活動的總體描述，是規劃業務架構藍圖時的必做項目。可以對業務功能進行三級劃分、層層分解：
第三，業務流程 = “主幹流程 + 分支流程 + 業務規則”：
例如：買火車票時，“選票-搶票-支付”這個流程是穩定的。、
例如，選座分支流程，靠窗、不靠窗、坐票、臥鋪（上下中鋪）。
例如，買兒童票、成人票、學生票要進入分支流程。
所以建議壹邊定義業務流程，壹邊定義相應的業務規則。
綜上，業務架構藍圖的內容應該明確！全面！直觀！詳細！
上面我們學習了業務架構包含的內容，可能不夠直觀，我們通過案例來加深我們對每個模塊的理解。
舉例業務架構藍圖五要素
我們借助業務架構藍圖五要素，管窺壹下中國鐵路12306平臺的業務架構。
目標業務功能—線上購票、線上支付、線上退票等；
目標組織結構—在原組織結構基礎上，新建IT運維中心；
目標業務流程—先登錄、後搶票、再支付、超時未支付則釋放票源；
目標商業模式—線上購票，省事省力（這個僅是價值主張）；
目標業務數據—用戶賬戶、列車時刻表、坐席數據、訂單、支付記錄等。
舉例業務渠道、合作夥伴、價值鏈
下圖分析了證券公司的業務功能與相對應的業務渠道
價值鏈包括核心業務層和支撐層，這裏的核心業務層屬於價值鏈對業務功能和服務的頂級分解。
在做規劃時我們常采用GAP分析法，先確定當前現狀，然後給出我們的期望，分析目標和期望的差距。如果有人和壹個新手這樣說，可能是不夠的，妳至少需要回答以下幾個疑問：
疑問壹，業務架構師具體要分析什麽？怎麽才算是戰略驅動？
--能否具體到政策文件？戰略方針？市場調研？友商對標？
疑問二，從戰略到藍圖，中間的邏輯是什麽？
--能否具體到小目標分解？小策略制定？
疑問三，我們首先應該怎麽做？
--就連壹個小的進銷存系統，也要先進行業務調研，不是嗎？
落地設計步驟
我們看下作者分享的戰略驅動的業務架構（BA）設計三步法。
圖中的三大步很明確，也非常貼近實際。
優點1：明確的戰略驅動起點。方法中明確了三種戰略驅動因素（Drvier）的類型，因為實際中就是國家政策、企業戰略、對標友商者三者之壹觸發了後續的調研、規劃與實施。
優點2：明確的調研環節。在第壹步中，包含了調研環節。
優點3：強調了從戰略到藍圖的過渡邏輯。在第2大步中，紮紮實實地規劃好業務架構目標/策略，才能確保藍圖充分支撐戰略。這壹步屬於高層級業務架構設計。
優點4：目標藍圖與Gap分析並重。在第3大步。
設計BA目標藍圖這壹步屬於低層級業務架構設計，其中Gap環節是必須環節，我們必須識別出業務架構的增量有哪些，給出對應的實施措施。
Gap分析的價值在於，它是持續進行架構治理所必需的，除了BA規劃環節應用，在AA、DA、TA設計環節也均有應用。
要點明確Driver，做好調研
業務架構設計必需做好的第壹件事，就是100%明確戰略驅動因素是什麽。
業務架構設計必需做好的第二件事，就是調研。 通過調研，廣度上理解企業的宏觀環境、行業趨勢，縱深上理解戰略的前因後果、來龍去脈、橫向上理解企業的競爭格局、友商動向。
粗看，調研範圍很廣，讓人理不清頭緒。細看卻有規律，主要三條線，分別是管理層訪談、戰略的來龍去脈、可借鑒案例。
要點從戰略到藍圖的內在邏輯
從戰略到藍圖的內在邏輯，由四個概念支撐起的骨架：
Driver—戰略驅動因素
Goal—業務架構目標
Strategy—業務架構策略
Blueprint—業務架構藍圖
這是壹個大型企業，推進數字化采購轉型如何從戰略到藍圖的構建邏輯，相信它有助於我們的理解以下幾點。
綜上所述，從戰略到藍圖的內在邏輯主線是： 確定Driver—目標分解—策略設計—藍圖定義 。邏輯明確，創新有據。
只有業務架構師真正洞悉了戰略意圖、準確領會了戰略動機，之後的業務架構設計工作都是有跡可循的，工作量再大，也不可怕。
工具GAP分析
推進確定Driver
項目假定為：某鐵路數字化服務轉型工程。
業務架構師（張三）知道業務架構的Driver是整個業務的起點，必須找準、吃透。
張三了解到，數字化轉型工程的Driver是公司剛制定的《公司戰略規劃》。
《公司戰略規劃》中闡述了數字化服務轉型的背景：近年來，互聯網技術的發展，提高了各行各業的服務水平，極大方便了人們群眾的衣、食、住、行、醫、學、玩等方面。從企業的角度而言，借助互聯網、大數據等技術，積極推動數字化轉型，擁抱以客戶為中心的服務模式，能搞提高客戶滿意度和企業競爭力。
《公司戰略規劃》中和數字化轉型戰略的核心表述是：樹立以人為本、客戶至上的服務理念，創新服務方式，完善服務標準，推動數字化服務轉型，提高服務水平。
推進做好調研之管理層訪談
管理層訪談： 不是讓業務架構師去了解行業，而是要領會管理層的關註點、主要看法。
通過訪談，業務架構師應了解：
推進做好調研之可借鑒案例研究
研究可借鑒的最佳實踐、最佳案例，也是調研的必做內容。
究其原因，業界每個階段的最佳實踐、最佳案例，都反映了業界當時的實踐水平。所以，如果業務架構師收集並分了業界當前最佳實踐案例，就可以在自己負責的架構設計中更好的把握設計方向、制定設計標準。
業務架構目標和策略包含以下兩方面：
推進差距分析
Baseline Business Architecture
Target Business Architecture
上述案列，我們通過GAP分析，識別了業務能力差距和IT能力短板，從而識別業務架構目標與策略，這是采用自底向上的方法。為我們後續環節做準備，比如我們識別出了核心業務需要增強的包括銷售、客運、貨運、清算、售後，新增的包括增值業務，在制定在業務功能、業務流程、業務數據、組織結構、商業模式模塊給出對應的策略。
如：從上圖價值鏈分析中看到，我們新增的業務需求是增值業務，通過電商業務、旅遊代理可以實現，再進壹步想壹下，就會知道我們的目標是增收，接著可以自頂向下思考，增收除了電商業務、旅遊代理，我們還可以做保險代理，通過服務門戶這個渠道觸達用戶。
推進確定目標與策略
只有紮紮實實地規劃好業務架構目標與策略，才能確保後續業務架構藍圖定義充分支撐戰略。
確定業務目標與策略環節，是業務架構設計的高層部分。後續的業務架構藍圖定義，是業務架構設計的低層部分。前者引領者後者的發展方向。由此可見“確定業務架構目標與策略”這壹環節的重要性。
這壹步，有三種做法。
1)自頂向下：將Driver分解為子目標，將子目標映射到業務架構策略。
2)自底向上：通過Gap分析，找到能力短板，從能識別業務架構目標與策略。
3)上述兩種做法相結合，循環展開，互為驗證。
鐵路系統數字化轉型，提高服務水平是Driver，如何才能達到這個終極目標。
答案是：
組織結構視圖包括三個模塊，組織結構、業務渠道、合作夥伴。
組織結構及改進主要描述部門設置、崗位設置、崗位職責等；合作夥伴及改進主要描述加強與供應鏈上下遊的合作夥伴之間的關系。業務渠道創新也是業務架構設計的常見策略，下面會舉例說明。
組織結構 下圖是運用GAP分析的方法，畫出當前組織結構和目標組織結構，並表示出變動點。
新手業務架構師往往認為組織結構沒啥好設計的。其實恰恰相反，壹旦組織結構需要變革，必然影響重大。
從上圖，我們可以看出來，之前企業自己做IT開發，目前公司計劃在做開發的同時，自己也做IT運維。相應的，企業組織結構新增了IT運維中心。
業務架構師應盡早明確組織結構的可能變化。因為無論是新建部門，還是部門增強、人員能力增強，都屬於TOGAF中的能力增量，是需要後續非IT工作包實現的。
不僅如此，組織結構的變化還影響整個企業的治理結構，從經營管理，到制約監督，再到績效考核。
總之，業務架構師雖然經常被當做跨系統軟件需求分析師降級使用，但真正承擔業務架構藍圖規劃任務的業務架構師，是必須能扛得起很多“非IT”規劃的。
渠道：在百度百科上的解釋是“比喻達到某種目的的途徑“，業務渠道就是用戶為了達成業務目的的途徑。如下圖，列車長通過補票終端這個渠道幫助用戶完成補票，客運公司通過大屏幕告知乘客車次信息。
業務渠道 業務渠道創新示例
網站、手機APP、補票終端、大屏實現了購票、補票、查看車次信息線上線下聯動，提升了用戶體驗和公司內部效率。
感悟 ：由上圖可知，業務渠道不是完全孤立的業務架構藍圖規劃項。它和業務流程、業務功能、組織結構是相互呼應的。因此，我們規劃業務渠道時，也應考慮這些。
關於渠道聯動，有同行這樣總結：
企業是由壹系列為顧客制造價值的活動和功能組成的。我們的業務功能就源自於可以為顧客制造價值的活動和功能。
企業的價值鏈展示了企業的設計、生產、營銷、運輸等為顧客創造價值的壹系列活動、功能以及業務流程之間的連接情況。價值鏈有兩個主要的組成部分：
核心業務（創造主要的顧客價值）
支持活動（為核心業務提供支持服務）
繼續來看運輸公司數字化服務的案例，業務架構師，面對運輸企業數字化服務轉型的任務，經過潛心研究，給出了下圖的價值鏈劃分結構。
有的同學可能會有疑問，為什麽會在核心業務模塊同時存在客運和貨運兩個區別較大的業務類型？在實際工作中可能只負責客運、貨運其中壹個模塊。前面我們業務架構出現的背景也有提到在國內業務架構是為了解決信息孤島發展起來的。業務架構師就是要在全局做規劃，而不是梳理單個系統。
以上我們已經整理了價值鏈，現在我們要分解功能域了。下圖是壹級功能域分解圖。
接下來，做業務能力Gap分析，我們可以看到新增的壹級功能域有4個，增強的壹級功能域有13個。
通過價值鏈分析到壹級功能域劃分的轉變，我們會有以下收獲：
第壹， 價值鏈分析模型為後續功能域劃分奠定了基礎。管理支持+核心業務這個業務功能呢域劃分框架確實很好用。並且廣受業界認同，在溝通的過程中自然也容易被其他人接受。
第二，類似“上車前、上車中、下車後”時間軸思維，是業務架構師必備的分析技能，同時，是甲方企業領域專家們經常使用的分析習慣。
業務架構設計不僅要定義出目標架構，還要使用GAP分析法，識別出需要增強的架構能力，為後續實施做準備。具體包括業務功能變化與增量、組織結構變化與增量、業務流程變化與增量、業務數據變化與增量。
商業模式揭示的是企業產品、企業核心資源、客戶、夥伴、渠道、成本、利潤之間的本質關系。簡單說，就是為什麽同樣的事，有的企業行，有的企業不行。
制定商業模式時並不是說全局只有壹個商業模式，我們可以根據我們的目標分別制定商業模式 ，比如上述案例中，該鐵路運輸公司的目標有三個：便民、增收、增效。我們就可以設計三個商業模式。
就鐵路企業的數字化服務轉型而言，要便民，應支持隨時通過網絡、電話、手機App獲取企業服務。
就鐵路企業的數字化服務轉型而言，要增效，可以借助硬件設備和智能控制系統，促進取消、檢票等環節的數字化轉型，提升效率。
感悟商業畫布，借助九個小格子，構建了簡介高效的系統化思維環境，是個了不起的發明。
從上述例子可以看出，商業模式有如下優勢：
個人認為，商業模式融合了BRD和MRD的內容：
BRD：商業需求文檔，關註為誰（客戶細分）、解決什麽問題（價值主張）、需要做什麽（關鍵活動）、花費什麽資源（關鍵資源）、性價比（成本/收入）如何。
MRD:市場需求文檔，關註消費者怎麽觸達（渠道通路）、怎麽獲得合作夥伴。
業務流程視圖是應用架構的輸入，也是業務架構中最落地、篇幅最大的章節。
作者在文章中對業務流程的協作方法進行了論述，結論是簡單的業務流程可以采用流程圖的方式繪制，業務流程分支較多且復雜的強烈建議使用文本化描述。
業務流程定義規範
要點是“1個主幹+N個分支”方式的流程分解
要點是“階段化+步驟化”，並附每步業務或數據模型規則
要點是“註明在主幹流程的分叉位置”，並附每步的業務或數據模型規則
這部分為可選
這部分很重要，上面也有提到，業務流程視圖是應用架構的輸入，所以對這塊再總結壹下。
我們發現，分支流程和業務場景有完美的對應關系。識別分支流程，就是場景化思維。相反，如果不區分主幹流程、分支流程，後續業務需求變更會波及壹大片，而不是改壹個分支流程這麽簡單了。這太不專業。
業務功能很多，業務場景更多，業務流程定義了什麽呢？業務流程定義壹個業務功能，其中包括多個業務場景。比如購票包括了多人購票、購買兒童票等。
業務規則多如牛毛，如何避免業務規則碎片化？圍繞業務步驟定義業務規則，業務步驟可以是主幹流程步驟，分支流程步驟。
關於是否使用業務流程圖：越是核心的業務流程，越是分支多、業務規則多，此時建議采用文本化規範，這樣呈現的信息更加全面。不復雜的業務流程，可以沿用流程圖的方式。
這篇文章對企業架構進行了概述，詳細講述了業務架構出現的背景及實際攻略，並通過實際案例加深我們對業務架構的理解。
我們來壹起回顧壹下文章中涉及到的概念之間的關系。
戰略驅動的業務腳骨設計實戰步驟，精華在於，從戰略到業務架構藍圖的跨度太大，邏輯鏈條接不上氣，所以分兩步走
如果讀完之後感覺通過企業架構可以提升自我、有利於公司發展，就行動起來吧！