— 1—

指揮官體系建設(shè)中需要支持的平臺的分類

今天要講前面介紹的指揮官體系的作戰(zhàn)體系/能力視角、指揮體系/響應(yīng)視角、生產(chǎn)體系、穩(wěn)態(tài)視角、敏態(tài)視角如何具體落地。

— 2—

涉及的高階技術(shù)架構(gòu)

服務(wù)是業(yè)務(wù)和技術(shù)的二位一體

各個企業(yè)的指揮官體系的建設(shè)過程中，最終發(fā)揮價值的是產(chǎn)品，而IT技術(shù)團隊看到的產(chǎn)品是什么呢？是一個個服務(wù)。服務(wù)既是業(yè)務(wù)功能，也是技術(shù)上的實現(xiàn)接口。

企業(yè)的作戰(zhàn)體系體現(xiàn)企業(yè)的能力視角，這些能力是由服務(wù)來體現(xiàn)的。

指揮體系體現(xiàn)了企業(yè)的響應(yīng)視角，這個視角是由服務(wù)的關(guān)系來體現(xiàn)的。

我們引入一個術(shù)語：事件，這里事件就代表服務(wù)間發(fā)生了關(guān)系。所以企業(yè)里的基本關(guān)系就是：服務(wù)-事件-服務(wù)。這個構(gòu)成了事件驅(qū)動的架構(gòu)（EDA）。這個構(gòu)成了指揮官體系的敏態(tài)視角。

我們可以看到服務(wù)之間的關(guān)系可能是穩(wěn)定的，也可能是不那么穩(wěn)定、隨著時間動態(tài)變化的。如果服務(wù)間的關(guān)系是穩(wěn)定的，我們?nèi)サ簟胺?wù)-事件-服務(wù)”中的事件， 關(guān)系就變成了“服務(wù)-服務(wù)”，這個就變成了面向服務(wù)的架構(gòu)（SOA）。這個構(gòu)成了指揮官體系的穩(wěn)態(tài)視角。從這里可以看出，大多數(shù)企業(yè)整體的設(shè)計過去都基本是從穩(wěn)態(tài)視角出發(fā)的。

面向敏態(tài)視角的EDA架構(gòu)適應(yīng)性更強，但是設(shè)計耗費的人力成本也更大。在具體的設(shè)計過程中，要分析服務(wù)之間的關(guān)系是相對穩(wěn)定，還是變化頻繁。前者適合采用SOA架構(gòu)，后者適合EDA架構(gòu)。

企業(yè)會是EDA+SOA的架構(gòu)

過去的系統(tǒng)設(shè)計多采用SOA架構(gòu)，現(xiàn)在的指揮官體系中，采用EDA架構(gòu)的服務(wù)會越來越多。因為在這個VUCA時代，變化才是常態(tài)，但從整體的架構(gòu)看， 企業(yè)的架構(gòu)會是一個EDA+SOA的架構(gòu)。

兩個因素決定了EDA架構(gòu)比重會越來越大：一是VUCA時代的常態(tài)變化；二是團隊識別服務(wù)本質(zhì)的能力差距，也需要變化。為了隔離不斷調(diào)整服務(wù)所帶來的影響，最小化其影響，采用EDA架構(gòu)就會越來越多。

我自己的體會是：穩(wěn)在敏中求，沒有敏，很難出來理想的穩(wěn)；而穩(wěn)的固化，會讓企業(yè)更加的敏。敏中求穩(wěn)，穩(wěn)中得敏，此敏已非彼敏！穩(wěn)和敏不是對立關(guān)系，而是統(tǒng)一關(guān)系，對方的存在可以讓自己更好！

— 3—

作戰(zhàn)體系/能力視角

從業(yè)務(wù)流程到具體實現(xiàn)，在面向服務(wù)的建模方法論中，涉及服務(wù)的識別、確定和最后的實現(xiàn)。有了服務(wù)的基本單元后，服務(wù)交互的角色就出現(xiàn)了， 主要的角色包含服務(wù)提供方、服務(wù)消費方、服務(wù)管理方以及底層的服務(wù)集成框架。

服務(wù)各方的關(guān)系就構(gòu)成了一個面向服務(wù)的架構(gòu)（SOA）。SOA意味著應(yīng)用設(shè)計的最佳實踐的總結(jié)。

SOA的設(shè)計構(gòu)成包含兩部分工作，第一部分是應(yīng)用層級的工作，這涉及到服務(wù)的識別和確定。

這部分的方法有很多，比如IBM有一個五天的面向服務(wù)的建模方法論（SOMA），TOGAF的應(yīng)用架構(gòu)設(shè)計，領(lǐng)域驅(qū)動設(shè)計（DDD）等都大同小異，都可以幫助識別服務(wù)、定義服務(wù)。

整體而言，這些方法都太重，實際分析設(shè)計中，研發(fā)團隊實際遵照執(zhí)行的很少。這里面有很多原因，例如研發(fā)進度緊張、團隊成員能力不足等。但據(jù)我觀察，大體還是因為方法論太重導(dǎo)致，團隊在使用前最好做一番裁剪。

沒有花拳繡腿的 服務(wù)分析V字法

這里我介紹一個分析服務(wù)、設(shè)計應(yīng)用架構(gòu)的非常簡單實用的方法，我總結(jié)為服務(wù)分析V字法。

上圖中左邊業(yè)務(wù)活動拆解構(gòu)成的模型就是BAM（業(yè)務(wù)活動圖），右邊的就是服務(wù)/服務(wù)組，或者也可以看作企業(yè)的應(yīng)用架構(gòu)。

將業(yè)務(wù)流程中包含的活動一層層分解， 最后分析出最小粒度的功能，然后再將這些功能按照相關(guān)度進行聚合，識別出服務(wù)、服務(wù)組，或者應(yīng)用架構(gòu)中的應(yīng)用。建設(shè)架構(gòu)視角的中臺時，避免重復(fù)建設(shè)的分析設(shè)計工作就是在這個環(huán)節(jié)做的。具體識別候選服務(wù)、確定服務(wù)的過程中，要根據(jù)服務(wù)的相關(guān)性確定服務(wù)是否合并，這里有操作數(shù)據(jù)是否相同、是否業(yè)務(wù)環(huán)節(jié)連續(xù)等判斷，最關(guān)鍵還是要看服務(wù)在業(yè)務(wù)上的相關(guān)性。

服務(wù)的設(shè)計要貼近業(yè)務(wù)，要進行差異化區(qū)分；服務(wù)組件的設(shè)計要多考慮重用，不同的服務(wù)可能是由一個服務(wù)組件提供的。服務(wù)組件會調(diào)用功能組件和技術(shù)組件，這樣，服務(wù)-服務(wù)組件-功能組件/技術(shù)組件的三個分層就體現(xiàn)出來了。

穩(wěn)定的服務(wù)的識別構(gòu)成了指揮官體系的能力視角

經(jīng)過這一層級的工作，服務(wù)、服務(wù)組就可以被識別出來，比如零售中的訂單中心、會員中心等就是在這部分工作中識別出來的。這里要說一下，一些穩(wěn)定的數(shù)據(jù)服務(wù)也是在這部分工作中識別出來的。

SOA的設(shè)計還包括支撐的技術(shù)平臺的支持，這里列出兩個直接相關(guān)的平臺，其他公共需要的技術(shù)平臺在最后章節(jié)講述。

第一個平臺是服務(wù)交互平臺，這個平臺有兩種類型：一種是分布式服務(wù)調(diào)用框架，最初這種框架適合企業(yè)技術(shù)標(biāo)準(zhǔn)統(tǒng)一，服務(wù)通過注冊都可以被服務(wù)管理平臺進行管理，現(xiàn)在已經(jīng)演變成為可以支持異構(gòu)系統(tǒng)；另一種是集中服務(wù)調(diào)用平臺，就是企業(yè)服務(wù)總線（ESB）。不管是哪種類型，基本都支持服務(wù)管理、服務(wù)監(jiān)控、服務(wù)熔斷、服務(wù)流控、服務(wù)版本化等共性能力。

第二個平臺是主數(shù)據(jù)管理平臺，其本質(zhì)是一種數(shù)據(jù)服務(wù)，主數(shù)據(jù)有這幾個特點：數(shù)據(jù)相對穩(wěn)定、多個應(yīng)用使用，相對頻繁訪問。所以設(shè)計通過數(shù)據(jù)分發(fā)來實現(xiàn)，其實這是一個技術(shù)設(shè)計的最優(yōu)實現(xiàn)。主數(shù)據(jù)管理平臺的主要能力是數(shù)據(jù)排重、數(shù)據(jù)分發(fā)實時、保證分發(fā)的數(shù)據(jù)的一致性。

— 4—

指揮體系/響應(yīng)視角/穩(wěn)態(tài)視角/敏態(tài)視角

上面講了企業(yè)的作戰(zhàn)體系， 企業(yè)已經(jīng)清楚了自己具備的能力或者服務(wù)。這些服務(wù)如何響應(yīng)市場，取決于指揮體系如何響應(yīng)。

服務(wù)的交互構(gòu)成了指揮官體系的響應(yīng)視角

這種業(yè)務(wù)上的關(guān)系進入IT體系后， 就變成服務(wù)之間的關(guān)系。服務(wù)是由作戰(zhàn)體系提供的。任何一次和用戶的交互會觸發(fā)一系列服務(wù)的執(zhí)行，這些執(zhí)行本質(zhì)就是指揮體系在發(fā)揮作用，也是指揮官體系的響應(yīng)視角。

直接和用戶交互的服務(wù)，在企業(yè)內(nèi)部和其他服務(wù)如何進行交互，這是指揮體系要回答的問題。

穩(wěn)定的服務(wù)、穩(wěn)定的服務(wù)關(guān)系構(gòu)成了指揮官體系的穩(wěn)態(tài)視角

以下幾種情況可以采用服務(wù)直接調(diào)用的方式：服務(wù)間關(guān)系很穩(wěn)定，或者相對穩(wěn)定，或者必須等待服務(wù)提供方執(zhí)行完畢、服務(wù)消費方才能繼續(xù)。這個時候，服務(wù)消費方強依賴服務(wù)提供方，二者耦合關(guān)系比較緊。這種耦合關(guān)系是設(shè)計時確定的，二者形成了服務(wù)契約，如果要有變化，需要雙方溝通重新設(shè)計修改。

服務(wù)的調(diào)用要有契約精神

SOA的架構(gòu)一定要管理好服務(wù)契約，架構(gòu)設(shè)計、變更要有契約精神，否則會帶來很多問題。

這一過程中對用戶負責(zé)的是服務(wù)消費方，但能夠確定服務(wù)消費方和服務(wù)提供方服務(wù)契約的責(zé)任人是誰呢？很多企業(yè)沒有明確這樣的角色，其實這個角色是端到端產(chǎn)品經(jīng)理。SOA架構(gòu)帶來的另一個問題是：服務(wù)提供方的負責(zé)團隊的積極性很容易被打擊，因為 TA 被服務(wù)契約束縛著。團隊的感覺是：每次想做點什么，都要溝通、溝通，扯皮的事情太多。根本原因是被一個不好的架構(gòu)束縛著，每個人都是局中的受困者。

所以我建議：

盡可能少用服務(wù)調(diào)用

SOA架構(gòu)在VUCA時代是一個不太好的架構(gòu)，要盡量少用。

這個時候每個服務(wù)都屬于一個產(chǎn)品，屬于一個運營團隊，也屬于一個研發(fā)團隊。每個服務(wù)設(shè)計的時候，監(jiān)控事件，當(dāng)某個事件發(fā)生時，觸發(fā)服務(wù)執(zhí)行。服務(wù)到底如何做，是由服務(wù)提供方的團隊負責(zé)，團隊的主觀能動性就被激發(fā)了。

解耦的服務(wù)的關(guān)系，EDA的架構(gòu)定義了指揮官體系的敏態(tài)視角

整體設(shè)計時，大家定義拋出的事件、監(jiān)控的事件，從全局角度去定義這些事件。整體架構(gòu)是被事件驅(qū)動的，服務(wù)和服務(wù)的關(guān)系是被事件驅(qū)動的，事件是有業(yè)務(wù)含義的；另外最關(guān)鍵的是部門和部門間的關(guān)系變成協(xié)作關(guān)系，不是指揮關(guān)系。當(dāng)某個事件發(fā)生時，如何做出響應(yīng)是自己部門的職責(zé)，自己要思考，自己要和自己的業(yè)務(wù)目標(biāo)、產(chǎn)品目標(biāo)對齊。為了達到自己的目標(biāo)，要主動對事件關(guān)心，當(dāng)事件觸發(fā)時完成目標(biāo)。EDA架構(gòu)完美的解決了服務(wù)關(guān)系的不確定性問題。

另外EDA架構(gòu)也能支持企業(yè)對于及時響應(yīng)的更高要求，除非是統(tǒng)計意義上的數(shù)據(jù)處理，否則都是實時、準(zhǔn)實時進行了服務(wù)處理。所以從這個意義上來說，設(shè)計中也要：

盡可能減少對于作業(yè)/job，批處理/batch的使用

這些事件中，有一種共性的事件，就是服務(wù)契約沒有達到企業(yè)要求，這些事件都會被指揮體系捕獲，有專門的監(jiān)控服務(wù)進行處理。

另一個就是針對數(shù)據(jù)實體的不確定性的處理，過去都基于數(shù)據(jù)實體設(shè)計屬性進行處理，如果涉及到數(shù)據(jù)實體的結(jié)構(gòu)變化，需要從底層改起，影響很大。

數(shù)據(jù)標(biāo)簽可以幫助應(yīng)對數(shù)據(jù)的不確定性

今天類似于服務(wù)的交互設(shè)計，針對相對靜態(tài)的數(shù)據(jù)，設(shè)計為數(shù)據(jù)實體的屬性；針對相對動態(tài)的數(shù)據(jù)，設(shè)計為數(shù)據(jù)實體的標(biāo)簽，所以針對數(shù)據(jù)實體的標(biāo)簽平臺會在系統(tǒng)中占有一席之地，用來應(yīng)對企業(yè)處理的數(shù)據(jù)的不確定性，從面向數(shù)據(jù)實體屬性向面向數(shù)據(jù)實體屬性和標(biāo)簽進行演變。屬性處理數(shù)據(jù)實體的靜態(tài)特征，標(biāo)簽處理數(shù)據(jù)實體的動態(tài)特征。

指揮體系在明確了作戰(zhàn)體系的各自服務(wù)/產(chǎn)品職責(zé)后，協(xié)作通過事件來進行，持續(xù)監(jiān)控服務(wù)/產(chǎn)品契約，確保達到契約承諾，可以看出打贏戰(zhàn)爭的最終保障在指揮體系，指揮體系是指揮官體系的神經(jīng)中樞。

— 5—

生產(chǎn)體系

生產(chǎn)體系保證作戰(zhàn)體系、指揮體系需要的產(chǎn)品/服務(wù)快速、穩(wěn)定的交付到生產(chǎn)環(huán)境。

包含持續(xù)集成（CI），持續(xù)部署（CD），持續(xù)運行（CO）。在這方面業(yè)界已經(jīng)很多商業(yè)化產(chǎn)品，也有散著的很多開源的產(chǎn)品。

生產(chǎn)體系需要具備的能力：

1. 快速集成，快速部署，比如一個單一的發(fā)布 ，是否能在1S發(fā)布完成。

2. 為失敗設(shè)計，灰度發(fā)布，秒級回退，A/B測試等，就是任何的發(fā)布包都可能有技術(shù)、業(yè)務(wù)上的問題，缺省假設(shè)是出問題。

3. 規(guī)?；⑿屑伞⒉渴?/strong>，一個大的項目，涉及10個產(chǎn)品、300個服務(wù)，能否支持各自相對獨立集成測試、發(fā)布，但整體目標(biāo)統(tǒng)一，形散而神不散，整體目標(biāo)可視，各自相對獨立。

4. 一切兼資產(chǎn)，所有的產(chǎn)品、服務(wù)、系統(tǒng)等都是數(shù)字化資產(chǎn)，都被管理、監(jiān)控起來。

— 6—

對于公共技術(shù)平臺的要求

IaaS平臺一定要達到公有云的水平

一句話：不要自己做，對公司不好，對自己也不好。對于中國大部分公司，自己做這部分沒有意義，純粹是給自己找個學(xué)習(xí)機會和造第一百個輪子。兩個基本的考核點：1 、申請資源除去審批環(huán)節(jié)的耗費時間是否能在分鐘內(nèi)獲得？ 2 、是否和研發(fā)環(huán)節(jié)無縫集成？如果這兩個沒有做到，就不要吹牛了；如果做到了，還可以和廠商談商務(wù)，用自己的投入和廠家談，云廠家一定可以做到比你便宜。

海量交易高并發(fā)一定是公共平臺/組件

比如一般的數(shù)據(jù)庫分庫分表、緩存服務(wù)、集成服務(wù)，都要采用技術(shù)平臺解決掉海量交易高并發(fā)的問題。

另外一條路就是serverless，這個一定是方向，合適的時機切入，可以獲得技術(shù)紅利。

事務(wù)一致性處理是很多企業(yè)技術(shù)管理薄弱的地方

如果網(wǎng)絡(luò)不抖動，如果機器不宕機，程序一切正常；事實是網(wǎng)絡(luò)一定會抖動，機器一定會宕機，所以很多企業(yè)的程序整天有問題。這個的原因很簡單，沒有處理好事務(wù)。這個時候企業(yè)要制定自己的事務(wù)處理規(guī)范，確定事務(wù)處理技術(shù)平臺，任何一個服務(wù)都要遵守該事務(wù)規(guī)范，采用該事務(wù)處理平臺，這個問題就解決了。

監(jiān)控一切

無數(shù)據(jù)不管理，無監(jiān)控不研發(fā)。制定業(yè)務(wù)監(jiān)控、系統(tǒng)監(jiān)控規(guī)范，根據(jù)監(jiān)控規(guī)范確定監(jiān)控平臺，一切的產(chǎn)品、服務(wù)、系統(tǒng)都要被監(jiān)控，監(jiān)控是指揮體系的眼睛。

控制一切

任何的異常，一種是轉(zhuǎn)生產(chǎn)體系，一種是轉(zhuǎn)作戰(zhàn)體系。不管是哪一種，都要有控制手段。

決策一切

今天決策由人工+智能構(gòu)成，不斷的將人工的部分持續(xù)的轉(zhuǎn)智能，第一步是將規(guī)則系統(tǒng)化，交由系統(tǒng)根據(jù)規(guī)則決策；第二步是學(xué)習(xí)人的決策數(shù)據(jù)，交由系統(tǒng)通過機器學(xué)習(xí)、深度學(xué)習(xí)智能決策。在這個環(huán)節(jié)利用的技術(shù)目前主要有RPA機器人+AI技術(shù)+數(shù)據(jù)湖。

— 7—

作戰(zhàn)指揮室（決策系統(tǒng)）是企業(yè)的指揮中樞

指揮官體系是一個充分授權(quán)的體系，各個產(chǎn)品獨立進化，各個組織持續(xù)改進。怎么保證整體為共同目標(biāo)一起努力呢？

第一是設(shè)計階段，整體目標(biāo)對齊，要有整體規(guī)劃，這里可以借用類似CBM、EA等方法論做整體規(guī)劃，利用OKR/KPI等手段賦予做這些事情的意義，激發(fā)人的主觀能動性。

第二是運行階段，能夠在整體看到全局，公司的高層持續(xù)在全局進行關(guān)注，持續(xù)優(yōu)化。有整體視角，在每個季度都做對全局最優(yōu)的工作，進而贏得這場商業(yè)戰(zhàn)爭。

在IT系統(tǒng)里面，什么元素承擔(dān)這一職責(zé)呢？業(yè)務(wù)活動圖（BAM）。

大家要注意到， 我說的是BAM，不是流程。為什么不是流程呢？ 流程太細了，很難維護設(shè)計態(tài)和運行態(tài)的一致性，如果采用了類似BPM等平臺， 又束縛了一些團隊的主觀能動性。

如何用好BAM呢？第一設(shè)計階段，明確企業(yè)的業(yè)務(wù)活動以及業(yè)務(wù)活動的關(guān)系，識別出服務(wù)。

運行階段，能根據(jù)服務(wù)間的交互關(guān)系，生產(chǎn)一個動態(tài)的BAM視圖，供企業(yè)高層、研發(fā)團隊二次迭代使用，這里最關(guān)鍵是可視化，直觀形象的展示企業(yè)能力-業(yè)務(wù)活動-服務(wù)的關(guān)系，是哪些服務(wù)在阻礙企業(yè)的核心能力落地。

作者：喬新亮 曾任蘇寧科技集團副總裁，全程參與了蘇寧的數(shù)字化轉(zhuǎn)型之路，親歷蘇寧技術(shù)部門從上千人到10,000+的團隊搭建，全面負責(zé)技術(shù)團隊的產(chǎn)品管理、技術(shù)管理、項目管理。IBM GBS副合伙人，主要負責(zé)企業(yè)架構(gòu)和云計算咨詢、設(shè)計、實施 落地工作。 TGO 鯤鵬會導(dǎo)師，GITC 全球互聯(lián)網(wǎng)技術(shù)大會主席團成員，IBM 認證 架構(gòu)師，全球技術(shù)學(xué)院成員。擁有超過17年 IT 行業(yè)架構(gòu)設(shè)計、研發(fā)管理和運營經(jīng)驗。