【讀書筆記】一一部跨越百年的經營戰(zhàn)略理念集結之作推薦理由本書核心內容精彩摘要精彩摘要??第1章業(yè)務架構的發(fā)展歷程1.1Zachman模型1.2TOGAF1.3FEA和DODAF1.4沉吟至今1.5業(yè)務架構的定義?第2章業(yè)務架構的作用及與IT架構的關系2.1業(yè)務架構的作用2.2業(yè)務架構與IT架構的關系?第3章架構伴侶：業(yè)務模型3.1模型與業(yè)務模型3.2常見的建模方法3.3建模原則與模型思維的應用??第4章業(yè)務架構的設計起點4.1企業(yè)戰(zhàn)略分析4.2對標分析4.3組織結構的影響不容忽視?第5章業(yè)務架構的設計過程5.1價值鏈分析5.2行為分析：業(yè)務領域和業(yè)務流程5.3數據分析：企業(yè)級數據模型5.4組件分析：行為與數據的結合5.5業(yè)務架構的整體邏輯關系?第6章業(yè)務架構的設計難點6.1基本的標準化方法6.2避免“過度整合”6.3何以解憂，唯有“融合”?第7章虛擬案例：商業(yè)銀行業(yè)務架構設計7.1價值鏈設計7.2存款領域的模型設計7.3貸款領域的模型設計7.4跨領域的標準化7.5組件設計7.6案例總結??第8章從業(yè)務架構模型到業(yè)務架構方案8.1業(yè)務架構設計不是為了替代需求分析8.2制作業(yè)務架構方案8.3小團隊的應對之道8.4需要充分解釋架構方案8.5努力打造“通用語言”第9章基于業(yè)務架構方案的實施過程9.1基于業(yè)務架構的設計9.2基于業(yè)務架構的協(xié)調9.3處理架構調整的原則第10章建立轉型后的長期應用機制10.2促進深度融合的需求管理機制第11章這個“笨重”的過程與敏捷沾邊嗎？11.1傳說中和現(xiàn)實中的雙模開發(fā)11.2與正宗的敏捷對比11.3與非正宗的敏捷對比11.4且行且珍惜第12章企業(yè)級的“五難”12.1捷徑難尋12.2文化難建12.3預期難控12.4權責難定12.5長志難立第13章實戰(zhàn)：實現(xiàn)了快速設計的案例13.1項目背景及需求13.2設計思路和業(yè)務架構方案13.3案例總結企業(yè)級業(yè)務架構的主線業(yè)務架構的“知行合一”第一部分：業(yè)務架構基礎篇第第1章業(yè)務架構的發(fā)展歷程第第2章業(yè)務架構的作用及與IT架構的關系 1.1Zachman模型WhatWhatWhereWhoWhereWhoWhyWhen 1.1Zachman模型要求期業(yè)務模型括M:M關系、N-信息系統(tǒng)模型（流程結構）技術模型詳細展現(xiàn)功能系統(tǒng) 1.2TOGAF模型??A??AHBHB?????C????C?????GFDFD?E?E???? 1.2TOGAF模型 1.3FEA和DODAF模型（FEA模型） 1.3FEA和DODAF模型（DODAF模型）與結構）和發(fā)展預測）購系統(tǒng)程序之間的從屬關系） 1.3FEA和DODAF模型（DODAF模型）DODAF的核心——8個視圖與52個模型 1.4沉吟至今單體式或豎井式開發(fā)更為常用，這種開發(fā)沒有橫向視角，業(yè)務架構對戰(zhàn)略的分解、業(yè)務架構自身的整合和標準化，到IT設計的過渡都存在不少陷阱，業(yè)務越復雜就難以駕馭。施工期間由于客觀因素可能導致實施對業(yè)務架構的偏離，這種偏離度過了業(yè)務架構落地困難期，感受到維護架構的難度而心生放棄，從而降低了對業(yè)務架構的評價。 1.5業(yè)務架構的定義第2章業(yè)務機構的作用與IT 2.1業(yè)務架構的作用字化”先行者已經實字化”夠使用同一種“語言” 2.2業(yè)務架構與IT架構的關系IT架構是根據“靈魂”IT架構是根據“靈魂”注入，讓“靈魂”有個適宜的居所，則是有賴于對“靈魂” 2.2業(yè)務架構與IT架構的關系 3.1模型與業(yè)務模型 3.1模型與業(yè)務模型“大道至簡，衍化致繁”?企業(yè)準備組織哪些人進行生產、銷售，在什么樣的渠道上?對利潤實現(xiàn)情況的衡量、盈虧原因的分析等，都體現(xiàn)在管 3.2常見的建模方法（ISO9000模型）化組織質量管理和質量保證技術委員會）制定的所有國際標準。 3.2常見的建模方法（ISO9000模型） 3.2常見的建模方法（BPMN模型） 3.2常見的建模方法（BPMN模型） 3.2常見的建模方法（BPMN模型） 3.2常見建模方法（UML建模） 3.2常見建模方法（UML建模） 3.2常見建模方法（UML建模）例1業(yè)務邏輯類和對象示例例2用例“下單請求”的順序圖：主序列 3.2常見建模方法（UML建模）例3“驗證PIN碼”用戶的通訊圖：“有效PIN碼”的場景例4“驗證PIN碼”用例的順序圖：“有效PIN碼”的場景 3.3建模原則與思維模型的應用 3.3建模原則與思維模型的應用拼不上的大飛機第二部分：業(yè)務架構設計篇程?6.1基本的標準化方法?6.2避免“過度整合”?6.3何以解憂，唯有“融合”第第7章虛擬案例：商業(yè)銀行業(yè)務架構設計?7.2存款領域的模型設計?7.3貸款領域的模型設計 4交替上升的業(yè)務架構設計與IT實現(xiàn)首次企業(yè)級轉型工程首次企業(yè)級轉型工程長期企業(yè)級架構應用優(yōu)秀的業(yè)務架構實踐不能僅單純地停留在業(yè)務優(yōu)秀的業(yè)務架構實踐不能僅單純地停留在業(yè)務分析層面，也不能只滿足于業(yè)務能力的組件化聚類，而是要時刻關注新技術、新業(yè)態(tài)的變化，適時引入新理念、新方向，使之具備與時以前倡導“業(yè)務推動技術”，業(yè)務提需求，技術管實現(xiàn)，業(yè)務發(fā)展催生技術發(fā)展；而現(xiàn)在，隨著技術進步越來越快，“黑科技”也越來越多，“技術引領業(yè)務”的聲音逐漸增多。但是，所謂的“技術引領業(yè)務”并不是指由IT人員直接拋出新技術給業(yè)務人員去琢磨和研究，而是指將對新技術的理解首先通過業(yè)務架構設計引發(fā)業(yè)務變化，用新技術理念推動業(yè)務模式演變，再進行IT技術開發(fā)，這才是理想的“業(yè)務與技術融合”，由此可見，業(yè)務架構意義重大。 4.1企業(yè)戰(zhàn)略分析\BMGovernance公司設計的企業(yè)戰(zhàn)略分析模型 4.2對標分析（方法論） 4.2對標分析（方法論）?即便請咨詢公司出手相助，對領先實踐的研究也多是表象研究，?即便請咨詢公司出手相助，對領先實踐的研究也多是表象研究，很難充分了解其機理?企業(yè)的發(fā)展是有時間過程的，一個優(yōu)秀的表象是經過了什么樣的過程形成的，其實很少有人能說得清楚，而形成這個表象所依賴的企業(yè)內部各組成部分之間的聯(lián)系和“過往”就更少有人人知道了。畢竟，即便是企業(yè)內部人士，通常也只了解自己所負責的工作，清楚企業(yè)全景的人很少?簡單化地學習領先實踐，無異于照著別人的藥方抓藥給自己吃。領先實踐真的?企業(yè)對自己的認知其實是有限的，很多問題并沒有深入挖掘根本原?企業(yè)對自己的認知其實是有限的，很多問題并沒有深入挖掘根本原因和產生環(huán)境，而這兩點對于形成正確的對標分析結論卻是非常重要的。為了提升對標的針對性，首先還是要從自己身上下功夫，只有真正的在內部無法攻克的問題才值得去對標。?對業(yè)務架構設計中的企業(yè)戰(zhàn)略分析而言，對標是為了通過對比與模仿，?在企業(yè)戰(zhàn)略設計方面切不可簡單照搬、盲目引進，光在“別人家的事情”上下功夫，導致無效對標，甚至讓對標分析“帶偏”了自己。 4.3組織結構的影響不容忽視康威定律康威定律搞折中會讓企業(yè)級架構失去核心架構影響其內部溝通效率對業(yè)務模型整體性的作用 4.3組織結構的影響不容忽視相輔相成相輔相成 5.1價值鏈分析ll波特所定義的價值鏈主要是針對垂直一體化公司業(yè)務提出的，強調的是單個企業(yè)的競爭優(yōu)勢。l后來出現(xiàn)的全球價值鏈的概念提供了一種基于網絡、用于分析國際性生產的地理和組織特征的分析方法，揭示了去全球產業(yè)的動l價值鏈主要包括基本活動和支持性活動，基本活動指的是主要生產過程，支持性活動則是指對基本活動起輔助作用和維持企業(yè)基本運轉的各類活動。l價值鏈主要描述企業(yè)價值的創(chuàng)造過程，引入價值鏈分析主要是為企業(yè)橫向審視自身的業(yè)務能力提供分析框架。 5.2行為分析：業(yè)務領域和業(yè)務流程務企業(yè)金融服務 5.2行為分析：業(yè)務領域和業(yè)務流程 5.3數據分析：企業(yè)級數據模型 5.3數據分析：企業(yè)級數據模型AR產品是為客戶提供的、以換取利潤的產品和服務，產品也包括合例如存款、提款、付款、信用/借記卡年費、利息和費用、投指銀行有形或無形的有價值的資源項目，是銀行擁有、管理、使用的，或支持特 5.3數據分析：企業(yè)級數據模型守對業(yè)務數據對生產嚴格對歷史數據 5.4組件分析：行為與數據的結合發(fā)改 5.4組件分析：行為與數據的結合一個主題域主題域的數據實體對數據實體進行增刪查 5.5業(yè)務架構的整體邏輯關系業(yè)務流程即業(yè)務活動，由不同的角色分別完成若干任務組成，任務執(zhí)行過程中必然與業(yè)務數據發(fā)與數據關系緊密的行為（任務聚類）形成包含行為和數據的業(yè)務組件。組件代表了企業(yè)的某一類業(yè)務流程即業(yè)務活動，由不同的角色分別完成若干任務組成，任務執(zhí)行過程中必然與業(yè)務數據發(fā)與數據關系緊密的行為（任務聚類）形成包含行為和數據的業(yè)務組件。組件代表了企業(yè)的某一類價值鏈代表了構建企業(yè)能力統(tǒng)一視圖的“橫向”結構，每個價值鏈環(huán)節(jié)中均包含了若干個業(yè)務流程數據主題域可以將關系緊密的數向”結構，描述了各類業(yè)務流程應如何通過組合實現(xiàn)領域級的業(yè)務目標 5.5業(yè)務架構的整體邏輯關系業(yè)務組件1業(yè)務組件2業(yè)務組件S 6.1基本的標準化方法企業(yè)級轉型工程的目標企業(yè)級轉型工程的目標 6.1基本的標準化方法 6.2避免“過度整合”務務度整合”度整合” 6.3何以解憂，唯有“融合”建模者經驗完善的業(yè)務資料經驗豐富的業(yè)務需要一套清晰的業(yè)務與IT的架構映射關系做指導建模者經驗完善的業(yè)務資料經驗豐富的業(yè)務需要一套清晰的業(yè)務與IT的架構映射關系做指導這個階段的調整代價最低，如不合理的設計一旦傳導到開發(fā)生，將會產生高昂的糾錯成本 7.1價值鏈設計隊隊EQ\*jc3\*hps52\o\al(\s\up26(項目),施經)EQ\*jc3\*hps52\o\al(\s\up26(計),EQ\*jc3\*hps52\o\al(\s\up26(項目),施經)EQ\*jc3\*hps52\o\al(\s\up26(計),豐)EQ\*jc3\*hps52\o\al(\s\up26(實),人)》 7.2存款領域的模型設計客戶營銷產品設計運營管理風險控制客戶營銷產品設計運營管理設計產品客戶經理IT人員業(yè)務人員設計產品客戶經理IT人員業(yè)務人員上架產品上架產品 7.2存款領域的模型設計存款領域產品設計客戶營銷運營管理風險控制統(tǒng)計分析錄入客戶信息入客戶經理客戶經理客戶經理會計柜員維護客戶信息維護客戶信息存入款項存入款項 7.3貸款領域的模型設計客戶營銷產品設計運營管理風險控制客戶營銷產品設計運營管理設計產品客戶經理IT人員業(yè)務人員設計產品客戶經理IT人員業(yè)務人員上架產品上架產品 7.3貸款領域的模型設計產品設計客戶營銷運營管理風險控制統(tǒng)計分析產品設計客戶營銷運營管理風險控制統(tǒng)計分析錄入客戶信息入客戶經理客戶經理客戶經理會計柜員維護客戶信息發(fā)放貸款發(fā)放貸款 7.4跨領域的標準化<<產品需求產品模塊代售產品 7.4跨領域的標準化 7.4跨領域的標準化11產品設計客戶營銷運營管理風險控制產品設計客戶營銷運營管理風險控制里需要增加一個“角色信息”錄入客戶信息客戶經理錄入客戶信息客戶經理客戶經理維護客戶信息客戶經理維護客戶信息會計柜員會計柜員發(fā)放貸款約發(fā)放貸款約VVVVVVVVVVVVV 7.5組件設計客戶營銷產品設計運營管理風險控制統(tǒng)計分析客戶營銷產品設計款項”“發(fā)放貸款”變動”放在“賬戶”合約”“擔保合約”合約”“擔保合約” 7.5組件設計賬務1122 7.5組件設計客戶營銷運營管理風險控制統(tǒng)計分析產品設計客戶營銷運營管理風險控制統(tǒng)計分析產品設計戶戶戶戶 7.5組件設計在2個垂直業(yè)務領域中共用的3個業(yè)務活動：設計上架產品、獲取在2個垂直業(yè)務領域中共用的5個任務：設計產品、上架 7.6案例總結212144計并沒有簡單的衡量標要反復進行迭代，雖然這不是我們但是實際操作中這是不可以減少反復次數，尤其是關鍵設計的反復迭要反復進行迭代，雖然這不是我們但是實際操作中這是不可以減少反復次數，尤其是關鍵設計的反復迭關注點對架構方案有很架構設計是一個不斷精煉和確認的過程，需要架構人員、技術人員在設計過程中努力“培養(yǎng)”客戶，創(chuàng)造一架構設計是一個不斷精煉和確認的過程，需要架構人員、技術人員在設計過程中努力“培養(yǎng)”客戶，創(chuàng)造一個深度融合的機會。而且上述設計思路對于業(yè)務人員日常分析自己的工作環(huán)境、設計工作方案、改進工作流程都有幫助，是一種可以跨越IT邊界的工作方法。對于這一過程的投入，業(yè)務與技術是雙贏的。第三部分：業(yè)務架構落地篇第第8章從業(yè)務架構模型到業(yè)務架構方案?8.5努力打造“通用語言”第第9章基于業(yè)務架構方案的實施過程第第10章建立轉型后的長期應用機制第第12章企業(yè)級的“五難”第第13章實戰(zhàn)：實現(xiàn)了快速設計的案例 8.1業(yè)務架構設計不是為了代替需求分析直接出IT直接出IT設計 8.2制作業(yè)務架構方案企業(yè)級業(yè)務架構方案的分領域企業(yè)級業(yè)務架構方案的分領域紹述圖業(yè)務組件描述紹企業(yè)級架構方案的整體描述紹紹 8.3需要充分解釋架構方案減” 8.4努力打造“通用語言”?模型化、結構化思維方式?每個條線、每個領域對企業(yè)架構都有所了解?用同一種建模方式，打造企業(yè)級項目的“通用語言”?模型化、結構化思維方式?每個條線、每個領域對企業(yè)架構都有所了解?用同一種建模方式，打造企業(yè)級項目的“通用語言”?堅持選用具有足夠能力的?堅持讓其跟進項目而非只做架構設計 9.1基于業(yè)務架構的設計業(yè)務架構是將業(yè)務能力經過企業(yè)級規(guī)劃后傳導給業(yè)務架構是將業(yè)務能力經過企業(yè)級規(guī)劃后傳導給IT端，并不會限制IT的實現(xiàn)方式IT需要適配業(yè)務架構的規(guī)劃，基于企業(yè)級業(yè)務架構的實施過程，其實IT需要適配業(yè)務架構的規(guī)劃，基于企業(yè)級業(yè)務架構的實施過程，其實是IT細化企業(yè)級業(yè)務架構設計，并基于企業(yè)級業(yè)務架構進行實施協(xié)調與管控的軟件過程 9.1基于業(yè)務架構的設計對公客戶經理錄入客戶信息時，很可能對方還只是潛在客戶，或對公客戶經理錄入客戶信息時，很可能對方還只是潛在客戶，或進行開戶操作，而是隔了一段時間之后才開戶，這時客戶信息可獲取新客戶代售產品產品編號業(yè)務領域使用客群基本信息是 標簽信息是存款獲取新客戶代售產品產品編號業(yè)務領域使用客群基本信息是 標簽信息是存款如果客戶直接去了柜臺，柜員就會首先檢查客如果客戶直接去了柜臺，柜員就會首先檢查客 9.1基于業(yè)務架構的設計2.2.處理“新發(fā)現(xiàn)”原本沒有“檢查客戶信息”這個任務，在最初的建模過程中，該任務是可以合并在開立賬戶這個任務中的，但是在細化流程階段，則可以考慮是不是應該將其獨立出來。是否獨立取決于整體的架構判斷，如果其他流程中也涉及了這種拆分，則確實可以調整企業(yè)級業(yè)務架構模型；如果不涉及或者很少有領域涉及，則可以將其標記為“開立賬戶”任務的衍生。這種細化可能會產生新的數據需求，設計新的數據實體，或者在原有的數據實體下產生根據某種維度細分的子實體。上述過程已經代表了對原有業(yè)務架構的一次迭原本在“開立賬戶”任務中獨立出來標記為“開立賬戶”任務的衍生獨立出來標記為“開立賬戶”任務的衍生 9.1基于業(yè)務架構的設計基于業(yè)務架構的企業(yè)級項目很重要的一點是要建立各階段工作成果之間明確的銜接關系，尤其是設計元素之間的聯(lián)系，應建立“戰(zhàn)略一戰(zhàn)略能力一需求一活動與任務一細化活動與任務-用例-交易或服務”這樣明確的關聯(lián)關系，形成一個完整的、分層級的企業(yè)能力視圖。企業(yè)能力視圖不能僅局限于業(yè)務側或者僅到組件層級，而是應該延伸到最終的實現(xiàn)，業(yè)務與技術的深度融合是今后企業(yè)發(fā)展的大趨勢。業(yè)務就是技術，技術也是業(yè)務，企業(yè)未來的作戰(zhàn)地圖必須是基于業(yè)務技術一體化的視圖，而非分裂的視角。細化活動細化活動任務細化任務細化任務任務細化任務細化任務 9.1基于業(yè)務架構的設計構設計的落地并非要有一種特殊的開發(fā)過程與之配套，其后對接的IT設計與分析方式可沉降過程，產生中臺業(yè)務規(guī)劃只是一個必然的結果。每個企業(yè)都能找到符合自己特點的業(yè)務中臺，而果本身。從企業(yè)級視角出發(fā)，也許能夠找到比中臺模式更適合企業(yè)自身特點的 9.2基于業(yè)務架構的協(xié)調 9.2基于業(yè)務架構的協(xié)調 9.3處理架構調整的原則 賬 1、別做“一錘子買賣”①企業(yè)級轉型，或者稱為中臺，都不是“一錘子買賣”，并不是項目上線后就萬事大吉了。會慢慢崩壞，更何況架構自身也必須與時俱進。任何領先都③做企業(yè)級轉型時，為了保證項目的順利進行，企業(yè)可④但項目結束之后跨部門的項目管理組織，即便形式上可以固化，也很難長計等計等適當規(guī)模的仲裁團隊業(yè)務架構人散到項目或者組件開發(fā)團隊中去，因為時間久了，會淡化業(yè)業(yè)務架構人員進入業(yè)務條線工作，繼續(xù)承擔推動業(yè)務與技術模型工具作戰(zhàn)地圖模型工具作戰(zhàn)地圖按圖索驥 10.2促進深度融合的需求管理機制1、什么是深度融合？深度交融和滲透領袖” 10.2促進深度融合的需求管理機制2、業(yè)務架構師的工作模式業(yè)務架構師非常適合作為與業(yè)務架構師非常適合作為與業(yè)務人員接觸的“技術第一師可以及時調動需求分析人員、產品經理、開發(fā)人員提早參加到需求的形成過程中，將需求管理直接轉變?yōu)闃I(yè)務規(guī)劃，這才是各方都希望實現(xiàn)的融合與快速反應。 10.2促進深度融合的需求管理機制2、業(yè)務架構師的工作模式可以根據需要，要求組件開發(fā)團隊的需求分析人員、產品經理或者開發(fā)人員提前介人分析可以根據需要，要求組件開發(fā)團隊的需求分析人員、產品經理或者開發(fā)人員提前介人分析業(yè)務架構師分散駐扎在各個業(yè)務部門需求產生時即采用模型工具與業(yè)務人員共同討論而是要有多個，要有“替補”與開發(fā)團隊共同工作一段時間；項目組若出現(xiàn)業(yè)務架構師不能處理好的協(xié)調問題時，則會提交給企業(yè)與開發(fā)團隊共同工作一段時間；項目組若出現(xiàn)業(yè)務架構師不能處理好的協(xié)調問題時，則會提交給企業(yè)架構進行溝通需求成型后即進入實施過程，業(yè)務架構師可以代表業(yè)務人員進入項目組必要的時候還會進行仲裁。 10.2促進深度融合的需求管理機制是“少數派”數派” 將業(yè)務整體拉入 是“少數派”數派” 將業(yè)務整體拉入 11.1傳說中和現(xiàn)實中的雙模開發(fā)開發(fā)定義 11.2與正宗的敏捷對比檔檔刺刺具具能在項目之外等著按“流程” 11.3與非正宗的敏捷對比架構師切實參與到項目中，給出架構設計建議，還要給出影響分析和事后重構“搏命”之后回歸正途，以免架構遭到有些項目形勢逼人，不上線毋寧死如果成本不允許，要把這一塊“飛地”標識清楚，盡可能成為以后架構設計可以利用的“輪子”，而不是“陷阱”。“搏命”之后回歸正途，以免架構遭到有些項目形勢逼人，不上線毋寧死如果成本不允許，要把這一塊“飛地”標識清楚，盡可能成為以后架構設計可以利用的“輪子”，而不是“陷阱”。體現(xiàn)職業(yè)操守，申明立場，給出認真詳盡的分析意見純粹特事特辦必須在文檔中保留分析意見。為未來真的需要調整時做參考使用。 11.4且行且珍惜第12章企業(yè)級的“五難” 12.1捷徑難尋金融是一個很不“專業(yè)”復制別人成功經驗很難金融是一個很不“專業(yè)”復制別人成功經驗很難似都在同一個領域，實際 12.2文化難建業(yè)務上需要做的調整不亞于技術上要做的調整，而對于業(yè)務上需要做的調整不亞于技術上要做的調整，而對于企業(yè)文化的調整則彼得彼得·德魯克曾說“文化能將戰(zhàn)略當午餐吃掉”，這的確是一個難題。引人新方法、新思引人新方法、新思維產生的沖擊也需要大量的時間去消化，這將是一個徹頭徹尾的大轉身 建立企業(yè)級不于一對部門邊界、協(xié)同關系的重新界定。建立企業(yè)級不于一對部門邊界、協(xié)同關系的重新界定。 12.3預期難建如果真的發(fā)生了改變，那至少可以說明太多不該戴的“高帽”太多不該戴的“高帽”現(xiàn)實做出的妥協(xié)，會讓很多美好的“理想” 12.4權責難定阿里智能云事業(yè)群總裁張建鋒（花名“行顛”）先生在接受外部采訪時表示，“大部分企業(yè)都缺少非常好的業(yè)務架構，這個業(yè)務架構你沒法招聘，只能自己培養(yǎng)”驗 12.5長志難立?愛美之心，人皆有之，人們都知道體型好代表既漂亮又健康，因此花錢、花時間減肥的大有人在，但是真正堅持到底、后期不反彈?未必是將架構組織撤銷、機制停掉這類激烈的動作?而是各種“畏難情緒”“客觀原因”導致的緩慢的無序，是由一個個需求的分配、落地的偏離堆積而來的?企業(yè)級維護工作很難與個體、局部的利益有明確的結合，很多時候需要依靠員工自覺去維護企業(yè)級?除了所謂的制度、機制之外，還會繞回到戰(zhàn)略和文化的問題上，即人們常說的如何打造一個“偉?對于大型傳統(tǒng)企業(yè)，自始至終，非技術因素的作用與技術因素相比，至少是等量齊觀的 13.1項目背景及需求項目背景及需求本案例中的需求是某企業(yè)與某互聯(lián)網公司合作進行的實物貴金屬產品在線銷售的業(yè)務。當時，其競爭對手與另一家互聯(lián)網公司剛剛合作了此類項目，受市場形勢所迫，該項目必須快馬加鞭，緊急施工，特事特辦。?需求產生時，該企業(yè)正在企業(yè)級轉型期間，但已經完成了企業(yè)整體戰(zhàn)略設計、高階能力需求分解，實現(xiàn)了企業(yè)級的業(yè)務架構設計和業(yè)務模型建設，并已應用模型驅動企業(yè)級開發(fā)了數年時間，工具使用已經比較熟練。?在轉型項目期間，該企業(yè)平均每年都有幾十個大型項目同時開展。所有業(yè)務需求都要經過業(yè)務架構分析，出具業(yè)務架構方案，再落實到具體項目組，可以說，企業(yè)級分析是項目的先導和開發(fā)任務分工的依據。?業(yè)務部門為配合快速開發(fā)，已經連夜寫出了業(yè)務需求。需求共計15頁，將近9000字，涉及11個大的需求項，需要業(yè)務架構師馬上根據需求文檔形成業(yè)務架構方案，以推動快速立項、快速進入開發(fā)階段。?需求的主要內容包括：為客戶建立虛擬賬戶，用于記錄客戶買賣交易、持倉等；支持使用該互聯(lián)網公司的黃金發(fā)送紅包（黃金份額）；紅包的賬務性處理、紅包資金的支付結算及劃轉；支持黃金實物兌換；支持黃金轉贈；銷售數據提取、報表統(tǒng)計、實物提取配送數據交互以及相應的核算規(guī)則等。 13.2項目思路和業(yè)務架構方案?識別新業(yè)務流程與原有業(yè)務流程的差異?判斷所涉及的模型范圍，識別出需要使用的活動、任務、涉及的組件?識別需要新增的內容，新增的內容應該歸屬于哪個任務和組件等。?為項目組指派具體承接的需求，這不是簡單地對號入座，架構設計最重要的就是理清結構和關系，說清各部分的具體分工和協(xié)作，給出明確的設計理由?包含了大量的業(yè)務組件和領域級業(yè)務應用?涉及多個核心組件及公共類支持組件包）”“對賬”“結算費用”這幾個主要的工作流程， 13.2項目思路和業(yè)務架構方案面 13.2項目思路和業(yè)務架構方案該過程的處理，由企業(yè)新增的渠道負責信息傳輸，“新增客戶，并記錄客戶在互聯(lián)網公司的該過程的處理，由企業(yè)新增的渠道負責信息傳輸，“新增客戶，并記錄客戶在互聯(lián)網公司的PID信息，與產品查詢對賬清算和手報表產品查詢對賬清算和手報表 13.3案例總結第四部分：業(yè)務架構落地篇?14.3構件模型的設計方式?14.4建立構件模型的虛擬案例?14.5構件模型的技術設計建議?15.1構件模型的抽象要素及邏輯關系?15.2輕量級架構管理工具的設計原理?15.3采集項目信息的價值?15.4輕量級架構管理工具的優(yōu)缺點?15.5應用輕量級架構管理工具管理新需求?16.1信息傳導：打造信息傳遞高速公路?16.2信息分析：創(chuàng)造高維數據?16.3創(chuàng)新平臺：擴展構件模型?16.4構件模型及其應用設想的不足 14.1“樂高積木”式的軟件設計“樂高積木”準 14.2“顆粒度”問題?構件開發(fā)并不是服務之間可以互相通信、互相調用就萬事大吉了，這樣的邏輯對于技術人員而言好像還可以接受，但是卻無法傳遞給業(yè)務人員，這種邏輯成了單純的技術組裝。?如果服務“顆粒度”劃分過細，那么這樣的構件開發(fā)將會拖累死通信機制，最后形成一個混亂的網狀通信，使得迭代、升級變得異常復雜。?“顆粒度”若處理不好，那么業(yè)務人員將無法明白IT到底在做什么，IT人員也無法讓自己得到?不關心業(yè)務人員是否理解，只在乎技術“自由度”的設計方式將使技術人員也難以確認自己的“組裝”到底是不是業(yè)務人員期待的“組裝”現(xiàn)有架構設計方式的不足現(xiàn)有架構設計方式的不足現(xiàn)有架構設計方式的不足現(xiàn)有架構設計方式的不足?SOA的缺點是在實際操作中并不真正關心“顆粒度”問題，一個遺留系統(tǒng)既可以直接被封裝成一個服務，也可以將很小的功能服務化，二者的地位是一樣的。所以，經常有人說，SOA本質上是一個集成架構，它能有效地解決異構系統(tǒng)的集成問題，統(tǒng)一內部的通信方式，重擔一般會直接壓給企業(yè)總線。?微服務雖然很關心“顆粒度”的問題，但是卻很難判斷服務的合適大小。若服務太大了，則內聚性不好；若服務太小了，則通信會過于復雜，從而降低效率。目前微服務領域也只存在一些參考性的原則，并沒有通用的標準。?DDD方法指導微服務設計，并取得了一些成果。但是DDD方法本身的學習門檻比較高，不容 14.3構建模型的設計方式就成了產品，產品的“零件”“零件”就是可用于“組裝”一個有結構的裝配模板，用于“組裝” 14.3構建模型的設計方式VVΛVVΛVVΛVVΛVV 14.4建立構件模型的虛擬案例價格VV 14.4建立構件模型的虛擬案例V加面向業(yè)務對“組裝”向操作實現(xiàn)的、較“細”V加面向業(yè)務對“組裝”向操作實現(xiàn)的、較“細”V價格 14.4建立構件模型的虛擬案例價格價格 14.4建立構件模型的虛擬案例??構件模型的思路非常符合企業(yè)級業(yè)務?構件模型也會因此打破原來流程模型中的任務邊界，產生新的模型表述方式，這種情況下，可以選擇是否將其視為流程模型的一次新?構件模型帶來新的業(yè)務模型表達方式構件模型的思路非常符合企業(yè)級業(yè)務架構的設計目標，其本身相較于流程模型來說更貼近IT設價格 14.5構件模型的技術設計建議實例化的結果中還包含構件清單，構件清單可以用于服務編排。構件的執(zhí)行順序可以串成對于流程明確的情況，但其實流程是否發(fā)生變化并沒有 15.1構件模型的抽象要素及邏輯關系?每個業(yè)務領域下都可能有一到多個模板用于設計業(yè)務實例或產品；模板可以包含若干個構件，組裝式開發(fā)可以表達為業(yè)務實例或產品與模板、模板與構件間的對應關系。?構件中可以記錄復用推薦度，以方便業(yè)務人員后續(xù)做設計時使用；構件中還會包含多個參數，參數應盡量使用數據模型中的數據項，但是實際操作中也可能需要列入一些與業(yè)務無關的技術字段。此外，應該為每個參數注明是否可供業(yè)務人員直接配置，若是不可直接配置的參數則不提供面向業(yè)務人員的配置界面。業(yè)務實例或產品?一個構件可以對應一到多個實現(xiàn)上的服務，構件此時代表的是一個服務集合。對構件的復用并不是指去任意復用SOA中的服務，而是構件對應的服務整體對外提供一種能力，這才是“零件”的含義，否則，構件就不是一個真實的存在。如果原有構件中的一部分服務又被集合成了新的能力，則應再增加一個構件與之進行對應，這樣的構件才真正具有部署的含義。?由于服務可以被調用，因此服務會對應報文，報文既包括請求報文，也包括響應報文。報文中又會包含與構件對應的參數，二者既可以合二為一，也可以分開表達。?模板在生產中會派生為業(yè)務實例或產品，在產品銷售前及銷售過程中，所有的參數都將?每個業(yè)務實例或產品都會有描述性的標簽信息，這些信息通過集合形成產品目錄。 15.2輕量級架構管理工具的設計原理隊隊-- 15.3采集項目信息的價值信息采集會帶來一定的工作量考慮設計一套邏輯進行項目信息的有效收集和分析 15.4輕量級架構管理工具的優(yōu)缺點 15.5應用輕量級架構管理工具管理新需求構件模型是基于系統(tǒng)結構和關系的，其通過一條順序流構件模型是基于系統(tǒng)結構和關系的，其通過一條順序流如果是原先沒有的業(yè)務環(huán)節(jié)或者是全新產品（這種情況其實較如果是原先沒有的業(yè)務環(huán)節(jié)或者是全新產品（這種情況其實較），在這種分析模式下，可以讓業(yè)務用戶以更為專業(yè)的方式高效應用輕量級架構管理工具管理新需求應用輕量級架構管理工具管理新需求 16創(chuàng)新管理三要素品信息傳遞高速公路”品信息傳遞高速公路” 16.1信息傳導：打造信息傳遞高速公路----可以包含設計者、管理者、銷售方、合作方、產品特征、適用客戶群體等各類描述信息，也就是“標簽”。產品目錄產品目錄--產品目錄能夠連通公司內外，連通業(yè)務和技術，將市場信息、客戶信息、銷售信息、伙伴信息等各種信息通過高維數據結構組織起來，讓海量信息分門別類地流向信息需求方，成為一個高效的信息傳輸渠道-- 16.2信息分析：創(chuàng)造高維數據用標簽打造高維數據 視角VV視角品批發(fā)視角XX視角>用標簽打造高維數據 視角VV