數字中臺建設的整體策略，核心思想是從業務抽象到領域建模，再到架構設計。因此業務中臺的架構思路和整體策略保持一致，並進行必要的補充。以下，Enjoy：
01 業務抽象
在業務抽象階段，通過業務調研和業務分析，設計業務藍圖和抽象業務元素，爲下一階段的中心建模階段準備頂層思想和業務素材。這一階段，根據企業不同的實際情況，可輕可重。比如企業已經做過諮詢調研和流程梳理工作了，那就可以在以往工作成果基礎上進行短期的業務理解和業務設計工作了。如果企業對以往的諮詢工作並不滿意或者上一次諮詢時間久遠，競爭環境發生了巨大的變化，這就需要做仔細完整的業務諮詢了。
02 高階設計
1)中心規劃
經過業務的調研和分析，技術架構師理解並熟悉了業務。基於上階段輸出的主題域，技術架構師按照中心的多個劃分標準，進行中心的規劃。
2)0級架構設計
業務中臺的0級架構本質上是應用架構，它以中心爲最小單位進行設計，因此也稱爲整體架構設計。0級架構包括了功能層級的架構和技術層級的架構。
功能層級的架構需要描述業務中臺在整個數字平臺中所處的位置，業務中臺由哪些中心組成，以及中心與應用、中心與後臺的交互關係。功能層級的0級架構承接了企業的應用藍圖規劃，指導企業各IT系統的職責劃分和定位。
下圖所示爲一個企業功能層級的0級架構示意圖。
功能層級的0級架構示意圖
從上圖中我們可以看到，企業整體功能架構從下往上分爲IaaS層、PaaS層、基礎組件層、數字中臺層(包括業務中臺和數據中臺)和業務應用層。每一層的具體功能如下：
l IaaS層：完成硬件資源的虛擬化管理，爲用戶提供對資源的使用服務。
l PaaS層：爲應用軟件提供部署平臺和運行環境。
l 基礎組件層：介於業務服務和技術中間件之間，提供通用的業務功能和技術功能，並解耦業務應用和技術中間件。
l 數字中臺層：分爲業務中臺和數據中臺，實現企業業務活動的核心機制，並通過數據中臺對業務運營提供指導。
l 業務應用層：通過調用和組合中臺能力，實現應用邏輯。
技術層級的0級架構需要說明各系統、各中心分別使用什麼技術來實現，以及整個體系的技術分層，如下圖所示。
技術層級的0級架構示意圖
技術架構總體上分爲展現層、服務層、接口系統、運營管理和運維支撐。
展現層與服務層相分離，展現層採用當下主流的前端框架，分別對移動端、PC端進行支撐。通過合理的技術搭配人性化的設計滿足用戶感官體驗需要。
服務層的架構採用分佈式的微服務架構，微服務架構去中心化加強終端的特點，讓服務免去雪崩效應等容災上的風險。同時，整體技術架構具備易於擴展、組合、部署，可支持動態伸縮、精準監控，並且可以提供灰度發佈等優點。服務層包含應用服務、中臺服務、技術服務。應用服務與中臺服務都以微服務架構實現。技術服務又分爲PaaS層和IaaS層：PaaS層通過各項基礎中間件的能力向上層輸送搜索引擎、分佈式文件存儲、分佈式數據庫、分佈式緩存等能力;IaaS層向用戶提供基礎資源服務。
運營管理通過埋點技術、A/B測試技術、大數據技術來進行數據採集分析和業務試錯，並通過計算結果來指導業務工作。
運維支撐將從底層對所有服務做支撐。運維體系通過對基礎設施的監控、服務升降級等措施來確保系統的容災能力與穩定性。
3)中臺核心數據流規劃
爲了簡化業務流程，根據前期的業務分析，結合0級架構的設計，我們可規劃出企業的業務數據流(以房屋租賃行業爲例，多業態)，如下圖所示。
基於中臺的業務數據流
客戶中心承接前臺應用租房、買房客戶的註冊信息;對於集團多業態的業務特點而言，經紀人、物管人員、企業員工都是企業客戶，都應該進行精細化管理。客戶中心爲統一認證提供賬號、密碼的驗證，爲各應用提供客戶的全局唯一標識。
產品中心接收來自ERP的工程域樓盤信息、員工錄入或經紀人提供的可租樓盤營銷信息，形成每一間房的完整且統一的檔案。爲前臺各應用提供全方位的樓盤信息，包括工程信息、營銷文案信息和房間信息。
交易中心接收來自WMS的庫存信息，完成購房訂單的生成、在線租房的交易等業務活動。訂單生成後，根據訂單中的商品向WMS發起發貨指令。
03 組件建模
1)產品設計
產品設計是在業務頂層設計的指導下，逐層往下抽象的過程，主要是將業務調研的成果轉化爲產品原型和需求規格說明書(主要由業務場景、業務流程構成)。如何做應用的原型和畫出業務場景不是本節的重點，詳細內容可參看相關專業書籍，這裏需要強調兩點：
l 中臺產品的詳細設計需要以面向中心爲指導思想。不僅需要設計出應用需要實現的功能，更重要的是要將需要中心支撐的功能明確標識出來，歸到中心的待實現列表裏。這樣技術工程師在領域建模階段纔有具體和明確的輸入。
l 建設中臺的核心目的不是爲了共享，共享只是中臺的特性。中臺是爲了完成業務的核心運行機制，爲前臺提供業務能力基礎的系統。確立了這個原則後，產品經理才能放開手腳，自主推動中心的建設。
2)組件模型設計
組件模型設計承接0級架構設計，是對中心內容的展開。通過對中心功能的分析和對中心業務實體的抽象，將具有較強依賴關係的業務實體聚合爲一個組件，或者將具有相同主題的業務功能聚合爲一個業務組件。最後以結構化的形式聚合這些組件，構成中心。
如何判斷組件模型是否合理呢?是否很好地支持業務流程、業務場景、複雜的業務規則是衡量組件模型優劣的標準。我們可以通過窮舉邊界業務場景的方法，來反證組件模型設計是否合理。
最後需要強調一點，組件是可以獨立爲微服務的，只要符合微服務的條件，就可以獨立。但是在實踐過程中，我們發現如果微服務承載的業務規模不大，獨立帶來的業務價值不高，反而會增加運維成本。
3)1級架構設計
組件模型設計完成後，需要將模型轉化爲應用架構。這裏的應用架構是指中心內部的應用架構，我們稱爲1級架構。1級架構是以組件爲最小單位設計的功能層級的架構。1級的功能架構是必不可少的，它指導着我們的設計和開發;技術層級的1級架構可視情況而定，如果技術內容比較複雜則需要輸出。下圖所示爲某企業功能層級的交易中心1級架構。
某企業功能層級的交易中心1級架構
4)關鍵交互圖設計
前面已經完成了0級和1級的架構設計，有什麼方法能證明設計是否可以滿足實際業務場景的需要嗎?我們可以通過實現業務場景的動態交互圖，來反向論證設計的合理性。如何判斷動態交互圖是否合理呢?根據業務邏輯是否清晰、流程是否簡潔、客戶交互是否高效來判斷。
如果設計出的交互圖不合理，那就說明0級或1級架構存在設計不合理的問題。另外，通過交互圖還可以較好地將設計思想傳遞給開發團隊。
04 開發交付
我們主張採用敏捷的方法進行開發交付，將最終目標拆解爲多個小目標，逐個完成。同時又將每個小目標拆爲多個子項目，每個小團隊各自負責一個子項目，所有團隊並行開發，協同向前推進。一般流程包括迭代規劃、需求反講開發、持續集成交付和回顧總結調整。
05 持續運營
項目上線後，只是產出業務價值的開始。數字中臺需要在持續不斷的運營中，包括業務運營、內容運營、技術運營和數據運營，不斷沉澱和發展。能力會逐步增強和擴展，模型會逐步調整和完善。
關於作者：作者團隊阿里系雲徙科技是國內領先的數字商業雲服務提供商，核心團隊來自阿里、用友等企業，以“業務+數據”雙中臺爲核心技術，驅動企業數字化轉型，賦能新零售商業創新，助力業務持續增長。