— 1—

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

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

— 2—

涉及的高階技術架構

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

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

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

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

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

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

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

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

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

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

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

— 3—

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

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

服務各方的關系就構成了一個面向服務的架構（SOA）。SOA意味著應用設計的最佳實踐的總結。

SOA的設計構成包含兩部分工作，第一部分是應用層級的工作，這涉及到服務的識別和確定。

這部分的方法有很多，比如IBM有一個五天的面向服務的建模方法論（SOMA），TOGAF的應用架構設計，領域驅動設計（DDD）等都大同小異，都可以幫助識別服務、定義服務。

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

沒有花拳繡腿的 服務分析V字法

這里我介紹一個分析服務、設計應用架構的非常簡單實用的方法，我總結為服務分析V字法。

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

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

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

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

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

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

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

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

— 4—

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

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

服務的交互構成了指揮官體系的響應視角

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

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

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

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

服務的調用要有契約精神

SOA的架構一定要管理好服務契約，架構設計、變更要有契約精神，否則會帶來很多問題。

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

所以我建議：

盡可能少用服務調用

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

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

解耦的服務的關系，EDA的架構定義了指揮官體系的敏態(tài)視角

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

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

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

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

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

數(shù)據(jù)標簽可以幫助應對數(shù)據(jù)的不確定性

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

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

— 5—

生產體系

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

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

生產體系需要具備的能力：

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

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

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

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

— 6—

對于公共技術平臺的要求

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

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

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

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

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

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

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

監(jiān)控一切

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

控制一切

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

決策一切

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

— 7—

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

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

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

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

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

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

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

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

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