07 | 中台落地第二步：企業數字化全景規划（Define）
企業級架構方法
企業架構方法已經非常成熟了，應用最廣的是 TOGAF，它的基本思路是從企業最新的願景戰略以及運營模式出發，設計企業的 To-Be 業務架構，然后依次推導，一步一步推導數據架構、應用架構、技術架構。
在以中台為潛在預設目標的企業數字化全景規划中，參考 TOGAF 思路，基於 Discovery 發散收集來的各個維度的信息，在 Define 階段結合自上而下企業戰略分解的舉措和自下而上現有業務架構梳理和分析的問題及痛點，重新設計新的業務架構，並進一步推導出其它的相關的架構設計。
中台復用的能力類型到底有幾種？
總結下來基本上就是四類：業務數據、業務功能、業務流程以及通用的技術能力。
通過領域分析識別共性能力
對於已經梳理的業務，使用領域驅動設計結合事件風暴（EventStorming）這兩個工具，通過工作坊的形式來對業務流程背后的問題空間和解空間做進一步的分析，識別出關鍵聚合，再通過跨業務線的問題域疊加投影，找出大家共同關注的問題空間和聚合，從而繼續擴展來做共性場景和能力識別。
中台與微服務有什么區別和聯系?
業務中台要解決的是業務能力如何快速復用的問題，就算背后是一個大單體，只要暴露出來的 API 能夠滿足業務能力快速復用的目的也是可以的
微服務架構的關鍵點是“能夠被獨立地部署”，這是評判一個微服務架構是否能發揮其價值的關鍵因素。
業務中台與微服務架構並沒有直接關系，只是因為微服務架構運行時依賴的低耦合特性，通常被用於實現業務中台中不同能力單元的團隊分離、技術分離、交付周期分離等特性而已，只能算是一對好搭檔。
平台型企業架構設計概覽
- 業務架構上的改進與設計
- 使用領域驅動設計（DDD）的戰略部分，針對於每條業務線，做問題域和限界上下文分析，以及關鍵聚合的識別
- 對於各條業務線分析出來的領域分析視圖，做橫向比對和投影，從領域層識別不同的業務線中的問題域、限界上下文以及聚合的重合度
- 基於跨域的業務架構分析和跨域的領域分析，討論判斷多條業務線的業務重合度
- 分析當前現狀與 To-Be 的最終規划之間的差距，產出具體的機會點列表
08 | 中台落地第三步：中台的規划與設計（Design）
確定中台產品願景
推薦一個簡單好用的工具來幫我們發散和收斂產品的願景--電梯演講（Elevator Pitch）。
電梯演講假設的場景，就是我們在電梯上偶遇公司管理層，能否在有限的時間內給對方講清楚我們在做的事情，比如中台。
願景的價值和難點就在於充分收斂。很多企業的願景雖然也用了電梯演講的方式，但是結果滿滿地鋪了一面牆，看着雖然震撼，但是其實效果是大打折扣的，畢竟我們也沒法在一個電梯時間復述完一整面牆的內容。
確定業務梳理范圍
進行細粒度的業務架構梳理，抽取共性，識別中台產品的具體需求。
基於中台的建設願景，我們就可以在橫向端到端價值鏈和縱向的業務線上收斂到一個聚焦的區域。再在這個聚焦的區域中進行業務梳理和展開，就會更加有效率和聚焦。
細粒度業務梳理
在業務梳理過程中采用了基於設計思維，結合用戶體驗地圖（User Journey Map）和服務藍圖（Service Map）的方式。回到業務本身，從問題域出發，以用戶為中心，進行用戶體驗設計和業務服務藍圖的梳理，從效果上來看也是非常不錯的。
確定 MVP
在中台的建設過程中，引入了精益創業中的 MVP 原則（Minimum Viable Product，最小可用品），也實現了體原則中的 Start Small。
運營前置：制定迭代計划及接入計划
提前考量運營計划尤其是接入計划，盡量使用合理的接入計划來規避一些風險，對於中台產品的建設也非常關鍵。
度量前置：定義驗證指標
我們在之前講中台建設前需要想清楚的四個問題時，已經講到過了。具體為什么需要將度量指標設計前置到開發之前，之前已經闡述過了，在這里我就為你分享一些度量指標的設計思路。
對於中台來講，難就難在與市場和用戶之間還隔着一層前台，所以在度量上就不如直接接觸用戶的前台系統這么清晰。但是我們講中台是為前台業務賦能的，又不能脫離開業務，單純只在技術上做一些度量。
所以我們一般在考慮中台的度量指標的時候，還是把戰略價值和業務價值作為出發點，開始拆解和推導，並且按照干系人關注點的不同，用多維度、多層次的指標設計來審視中台建設的效果。
完整課程請掃碼學習哈！
本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。
歡迎轉載、使用、重新發布，但務必保留文章署名 鄭子銘 （包含鏈接： http://www.cnblogs.com/MingsonZheng/ ），不得用於商業目的，基於本文修改后的作品務必以相同的許可發布。
如有任何疑問，請與我聯系 (MingsonZheng@outlook.com) 。