摘要：通過這個系列，讓大家對中台的價值、針對的問題痛點、中台規划的方法思路和技巧、一些中台業務實踐有個基本的認識，讓客戶清楚的意識到企業中台的業務價值，進而通過企業中台規划牽引客戶IT基礎設施投資。
今年“中台”一詞異常火爆，百度搜索指數已經遠超“數字化轉型”。中台的產生並非完全自上而下的戰略設計，也並非是為了追風，而是隨着企業業務的高速發展、組織架構不斷膨脹的過程中暴露出的各種問題急需解決。此時，中台的概念恰有其聲，大家在經過不斷實踐論證后欣然接受了中台。
企業中台作為現在的市場熱點，幾乎每一個客戶都會在建設的過程中遇到一系列的問題。借此，希望通過這個系列，讓大家對中台的價值、針對的業務問題痛點、中台規划設計的方法思路和技巧、一些中台業務模式實踐有個基本的認識，讓客戶清楚的意識到企業中台的業務價值，尤其是通過中台幫助傳統行業的各家企業構建差異化業務服務競爭優勢，提升客戶滿意度，進而創造更多的經濟效益，基於企業中台的實際業務價值有效引導IT投資。
點擊標題，可查看往期1-17篇文章
（一）：前中后台基本定義
前台：由各類前台系統組成的前端平台。每個前台系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機App，微信公眾號等都屬於前台范疇。
后台：由后台系統組成的后端平台。每個后台系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的后台。基礎設施和計算平台作為企業的核心計算資源，也屬於后台的一部分。
中台：套用經濟學中對於服務的定義，中台就是要協調/調度資源，滿足前台與用戶互動的需求。業務中台（SOD-System of Differentiation）本質上就是要解決“業務供需矛盾”，即解決創新驅動快速變化的前台（SOI-System of Innovation）和穩定可靠驅動變化周期相對較慢后台（SOR-System of Record）之間的矛盾。（相關概念轉自Gartner Pace-Layered）
業務中台建設的根本目的是要滿足前台與用戶的互動，中台的模式取決於互動的模式（Interoperability Mode），包括：中台和后台（服務組織）支配的高效互動模式；前台支配的人性化互動模式；用戶支配的個性化互動模式。相對於互聯網行業而言，傳統行業的商業模式、業務模式較穩定，決策鏈、價值流、業務流很長，高效協同的迫切性往往會高於個性化和人性化，這也是華為一直在追求的服務化轉型要兼顧“做生意更簡單高效”和“ROADS體驗驅動、客戶滿意”。
（二）：中台的價值
現有的軟件系統不符合客戶的業務應用場景。ISV關注的是自己的軟件產品應用場景，並非客戶實際的業務應用場景。
客戶的實際業務應用場景應該是“端到端高效協同的”、“可以根據新商業模式定制的”、“可以根據作戰場景DIY的”，ISV的軟件產品迭代總是跟不上客戶的業務應用場景變化，因為ISV只是軟件產品的Owner，而非客戶業務場景的Owner。
中台規划的核心理念可以總結為：客戶業務場景驅動的服務化IT架構規划（含前中后台規划）。
我們幫助客戶規划設計業務中台的根本目的是要撬動IT基礎設施轉型升級的機會。
我們幫助客戶基於客戶自身業務場景規划設計的業務中台，某種意義上可以說是“獨一無二”的、只適合於客戶的，因此業務中台是買不來的，只能整合各個ISV的軟件功能進行“篩選”、“拼裝”和“組合”，尤其要打破各個ISV軟件包之間的“牆”。
（三）：業務場景驅動的服務化IT架構規划
基本套路：1）快速地將客戶知道的業務場景變成顧問自己的；2）基於業務場景推導出服務化IT架構（前中后台規划）。
快速地將客戶知道的業務場景變成顧問自己的本質上就是要做好場景剖析的工作，而場景剖析的關鍵在於快速地利用一些有效的工具將客戶對業務場景的非結構化表述變成結構化的咨詢交付件。對於場景剖析而言，推薦采用3PM模型來做結構化描述（Purpose、Principle、Process、Method），我們可以將客戶描述的場景轉換成3PM。
將客戶描述的場景轉換成3PM結構化表述，按照高效、人性化、個性化三種互動模式，通過4A集成方法系統性地考慮服務化IT架構對客戶業務場景的有效支撐。
（四）：業務場景驅動的前中后台架構規划
“中台和后台（服務組織）支配的高效互動模式”下的業務場景驅動的服務化IT架構規划。
“信息化投入能夠幫助客戶提升人員單位產出”，因為信息化可以避免“人拉肩扛”式的業務運作，避免業務人員從事低價值的工作，能夠讓業務盡可能自動化、自運營、免人工干預。CIO應該聚焦IT架構和以業務場景為中心的解決方案能力的提升，打造橫向端到端業務高效協同、縱向前中后用戶體驗驅動的一體化IT應用服務平台，IT團隊的新陣型、新打法、新導向都應對准業務場景的IT解決方案所創造的價值。
IT使能高效協同的業務場景：1）業務端到端協同場景驅動的中台規划，服務組織需要協調好環境、設施/設備、數據資源等，以滿足前台和用戶的交互；2）在中台構建的高效協同場景下，抽象出面向用戶的交互場景，以用戶體驗驅動前台規划；3）單業務域場景可以看成是單個業務部門或單個系統的場景，由其驅動的后台規划作為資源和能力的來源供中台調用。
（五）：整體規划方法和業務場景驅動的端到端架構規划
在中台和后台（服務組織）支配的高效互動模式下，中台承擔了更多的業務集成拉通的任務，中台也承載了端到端協同的業務模式，例如對於傳統制造業來說，研發、交易和交付、生產供應、計划、采購、財務等業務集成的模式直接決定了前台的交互模式。換句話說，在這種情況下是由中台來決定前台的不同用戶之間能夠做些什么，由中台來決定如何調度資源、如何組織這些資源以及如何使用資源，前台用戶更多地是圍着中台構建的業務模式來進行互動。
整體規划方法：1）對客戶業務場景的了解和分析；2）對客戶業務場景的剖析；3）基於客戶業務場景規划前台交互模式、中台協同模式和后台資源。
對客戶業務場景的了解和分析可以通過調研和訪談等方式，充分獲取客戶對業務價值流、業務模式、業務場景的非結構化描述（自然語言），並輔助一些結構化分析手段進行總結和記錄。對客戶業務場景的剖析則是站在IT架構師的角度對業務場景所包含的關鍵要素進行進一步的細分和定義，可以通過信息鏈、EBIM和應用集成關系對業務場景進行結構化剖析，識別業務活動之間的數據演進關系和應用之間的數據集成關系，以支撐業務端到端協同場景下的用戶交互設計。
（六）：從端到端架構規划到領域級架構規划
端到端是業務運作視角，領域划分是業務管理視角，兩者缺一不可。業務運作關注的是把事情做好，而業務管理關注的是把資源准備好、把能力建好以滿足端到端業務運作的需求。
領域級架構規划的目的是要系統性地管理業務能力所包含的關鍵要素，包括：
1) BPA中的流程要素：以流程目錄的方式管理好各業務管理域中的標准流程、活動和任務；
2) IA中的數據要素：以數據資產目錄的方式管理好各業務管理域中的標准業務對象、數據實體和屬性；
3) AA中的應用要素：以應用功能目錄的方式管理好各業務管理域中的標准應用和模塊；
業務場景的剖析有兩種方式，分別為端到端架構規划和領域級架構規划，其中，端到端架構規划是基於業務端到端協同場景的中台規划和基於用戶交互場景的前台規划的重要輸入，領域級架構規划是業務管理支配的后台資源、能力服務化的重要輸入。
1） 對於業務場景驅動的架構規划來說，可以“自上而下”，先有業務集成場景來驅動端到端架構規划，進而按照業務領域划分分解為領域級架構規划；
2） 對於軟件包驅動的架構規划來說，可以“自下而上”，先梳理單個業務領域對應的軟件包的架構資產，進而將軟件包架構資產集成起來並與業務場景相適配，形成端到端架構規划。
（七）：Design Thinking使能用戶體驗驅動的前台規划
中台和后台（服務組織）支配的高效互動模式，“優先考慮協同的效率，並滿足用戶一站式接入的期望”，其前台規划可分解為4個過程：
- 1） 運用Design Thinking方法，基於業務端到端高效協同場景，完成面向用戶的交互場景設計；
- 2） 運用用戶體驗之旅（Journey Map）工具，對面向用戶的交互場景進行剖析，識別並定義用戶交互觸點（Touch Point），參考用戶體驗標准（如ROADS）識別用戶交互體驗的痛點和改進機會；
- 3） 按照一定的原則，識別用戶交互觸點需要調用的業務應用服務和數據服務，並作為對中台應用服務市場的需求；
- 4） 基於用戶交互觸點、需要調用的業務應用服務和數據服務組合成一站式APP（輕應用），完成面向用戶一站式服務的前台應用規划。
參考華為公司服務化IT架構的元模型 – V模型，用戶服務觸點/業務活動和業務應用服務均應圍繞業務對象來定義，均可視為針對業務對象的在不同上下文中（業務上下文、IT上下文）的一系列動作/操作。
前台為了滿足面向用戶的交互需求（人機交互），需要中台調度資源並提供應用服務供前台調用，這就是“大中台，小前端”的理念，即前台是沒有資源的，需要中台平衡前台交互需求與后台資源供給之間的關系。服務對象、前台、中台和后台的邊界：
1）外部互動線用以划分服務對象行為和與服務對象互動的服務前台行為的邊界。
2）服務可視線用於划分與服務對象互動的服務前台行為和調度資源以滿足前台服務需求的服務中台行為的邊界，一旦跨過服務可視線，服務對象就無感了。
3）內部互動線用於划分調度資源以滿足前台服務需求的服務中台行為和后台資源准備行為的邊界。
（八）：業務對象的內涵和建模方法
業務對象是業務領域重要的人、事、物，用來統一業務領域的重要業務概念，是業務人員之間以及業務人員與系統人員之間溝通的橋梁，是識別變革項目涉及的信息范圍和關鍵信息的依據，明確信息定義和關聯關系的基礎。
對象屬於物理數據設計的范疇，概念屬於邏輯數據設計的范疇，我們通常所說的人事物，都有其物理性的一面，還有其邏輯性的一面。
物理數據設計針對的是對象，每一個對象都有其狀態，而對象所屬的類決定了對象可能存在的狀態。對象可以抽象為變量，一組變量也稱為實體，每個變量都會有其賦值，變量或實體所屬的類型指定了賦值所要表達意思的集合，邏輯數據設計針對的是變量或實體。
從物理數據設計到邏輯數據設計，本質上是從對象的客觀狀態變化到邏輯變量或實體的主觀意識變化，這種轉變需要基於主體對客體到本體轉變的約定。某種意義上，這個約定也是元數據的來由，即基於業務狀態改變對相關變量的數據取值規則進行約定，以實現主體對客體對應本體的一致性認知。
概念模型、邏輯模型和物理模型是承接邏輯數據設計的，且其語境從Outside the computer轉變為Inside the computer。
1） 物理數據設計：以客體為中心，描述對象的狀態變化，對象所屬的類決定了對象可能存在的狀態。
2） 邏輯數據設計：以本體為中心，對象可以抽象為變量，一組變量也稱為實體，每個變量都會有其賦值，變量或實體所屬的類型指定了賦值所要表達意思的集合。
從Physical和Logical、Outside the computer和Inside the computer兩個方面&四個象限明確業務對象的完整上下文定義。
（九）：識別業務對象的流程、方法和原則
識別業務對象可以大體上分成5個階段：分析和識別業務對象、整理業務對象初稿、業務對象開發和驗證、更新業務對象定義和描述、刷新業務對象。
在分析和識別業務對象階段，可以有4種主要的工作模式：架構驅動模式、參考架構驅動模式、軟件包驅動模式、業務需求驅動模式。自上而下和自下而上的業務對象分析和識別更多體現在組織方式的不同以及側重點的不同，前者更加注重支撐業務戰略目標的業務對象完整程度，后者則側重於業務場景與業務對象的匹配度。
在整理業務對象初稿階段，重點是梳理候選的業務對象，並對候選的業務對象進行初步的合並和抽象，以初步輸出業務對象清單。人工完成這個過程的方式和機器學習一樣，包括“分類”和“聚類”，或者也可稱之為“有監督學習”和“無監督學習”。
在業務對象開發驗證階段，主要針對前一階段輸出的業務對象初稿，按照合規性、完整性、合理性、集成性等原則進行審核、驗證、優化。
在更新業務對象定義和描述、刷新業務對象階段，重點是要明確業務對象的業務責任人（Owner），由業務責任人來負責業務對象的演進、管理和發布，而這也與第七節中提到的基於業務對象定義的業務應用服務管理有着密切聯系。
（十）：基於DDD的業務對象顆粒度定義
在實際識別和定義業務對象過程中，業務對象的顆粒度卻是最難以確定“好”和“壞”標准，而這又會影響到以業務對象為宿主的業務應用服務的拆分顆粒度。拆分業務應用服務的目的都是為了實現業務對象的“高聚合、松耦合”，其本質是“業務對象的處理邏輯能更加集中”與“業務對象本身能更加分散”之間的矛盾，從業務視角來看，前者代表着集中管控類的訴求，后者代表着快速發展、構建、演進類的訴求。
對於集中管控來說，希望管轄范圍內的每一個個體都是符合管控邏輯的，也即是對業務對象有很強的一致性要求，要求業務對象內部遵循統一的一致性原則。對於快速發展、構建、演進來說，則是希望可復用、去中心化和分布式，要求業務對象對外提供的服務盡可能單一、簡單，彼此之間有很清晰的邊界。這個本質上可以說是強一致性和柔性一致的矛盾，對於任何業務對象來說，都需要考慮到這兩方面的訴求，相關要求可以參考數據庫技術中的ACID和BASE策略。
對於DDD領域驅動設計（Domain-driven design）來說，最核心的就是要建立一個領域模型，通過定義對象之間清晰的所屬關系和邊界來實現領域模型的內聚，聚合定義了一組具有內聚關系的相關對象的集合。這種聚合間的邊界本質上就是一致性邊界，即聚合不可再分，否則就很難保證其業務強一致性要求；聚合也不可再合並，否則對聚合之間的弱一致性業務規則要求也會造成損害。如果將聚合作為領域模型中一個個較為獨立的“高聚合”和“松耦合”業務對象的話，恰好能夠在“業務集中管控”和“業務高可復用”之間取得平衡，將其作為對業務對象顆粒度定義的基本要求是非常合適的。
（十一）：協同、共享、自助、感知模式下的中台規划
華為全場景驅動的4種中台規划模式，包括“協同、共享、自助、感知”。
協同模式：服務組織支配的高效互動場景。對於傳統行業而言，業務中台更加強調基於標准化流程的端到端高效協同，在此基礎上通過前台給用戶帶來標准一致的服務體驗。
共享模式：前台支配的人性化互動場景。對於共享經濟而言，業務中台是一個個整合資源后形成的能力共享中心，前台通過對能力的組合、編排，快速重構並搭建一個個新的業務模式。
自助模式：用戶支配的個性化互動場景。用戶可以自助調取中台的能力來構建自己想要的前台，某種意義上是基於前台支配的人性化互動模式的更進一步發展。
感知模式：IoT驅動環境感知場景。任何人都可以借助各種傳感器、IoT感知外部環境，獲得環境反饋並作出相應改變，加快與現實世界間的信息流動。
（十二）：協同模式下的中台規划
協同模式下的中台規划，其最大的價值是要面向前台和用戶提供業務協同服務，讓數據多跑腿，讓人少跑腿。
首先需要考慮的是協同業務流的設計。在前面的章節中介紹過端到端業務場景梳理和剖析的方法，協同業務流的設計則是要將業務場景集成起來，並進行適當的划分。
端到端的業務流視角看的是業務事件的演進，端到端數據流視角看的是各類數據的集成拉通。將業務流轉換為數據流的過程中，重點需遵循的原則是“高聚合、松耦合”，業務流可以是發散的，但數據流一定得按照數據的定義進行收斂，不同的業務流對同一類數據的處理和傳遞應盡可能歸一化，有益於數據的同源管控，避免數據不一致和IT重復建設。
基於“高聚合、松耦合”原則對業務流的數據流進行重構，支撐集成業務場景以及前台用戶的交互場景。數據流的定義確定了中台的業務協同服務的顆粒度，通過對業務協同服務的靈活組合，可以支撐不同業務協同模式下的業務流。
業務協同服務可以包括3個部分的內容：
1、 提供數據流橫向、縱向集成服務。數據流橫向集成服務指的是單個數據流的不同業務對象之間的集成服務，數據流的縱向集成服務指的是不同數據流之間的集成服務。
2、 滿足前台構建面向用戶一站式Portal的業務應用服務需求。包括數據流橫向、縱向集成服務，以及針對業務對象的各種處理和訪問邏輯，可以將這些功能封裝成業務應用服務，在統一的服務市場中注冊、發布，並供前台用戶訂閱和調用。
3、 基於數據流的業務協同服務還需要調用共享模式下的中台提供的業務應用服務，這也可以作為業務協同服務的一個關鍵組成部分。
協同模式下的中台規划，本質上是由協同業務流驅動的數據流重構，以及基於數據流的業務應用服務規划，以滿足業務集成拉通、前台用戶一站式交互、對共享中心的調用等訴求。
（十三）：共享模式下的中台規划
共享模式下的業務中台是一個個整合資源后形成的能力共享中心，前台通過對能力的組合、編排，快速重構並搭建一個個新的業務模式。業務能力共享中心的重點在於業務能力、業務活動、業務數據的“被集成”。
共享模式下的業務中台提供的業務應用服務的復用性非常高，基本上任何一個前台的構建都不可避免的會用到中台提供的服務，這樣也能有效避免公共服務的重復建設。
共享模式下的業務前台的自主性非常的高，前台通過集成中台提供的共享服務，可以快速構建面向用戶的APP，以支撐新商業模式的快速搭建和推廣。不同的前台之間的交互是非常少的，前台業務之間並沒有太多的協同訴求，前台更多地通過共享的中台服務來實現統一和暢通。
互聯網企業將核心業務中公共的、通用的業務以服務的方式沉淀到共享業務事業部，整個集團的核心業務能力均建立在這樣一套共享服務體系之上，這樣就能發揮服務化架構的核心價值，即“服務重用”。對於傳統企業來說，將現有的業務平台中可以統一共享的業務能力剝離出來，構建共享的業務中台，確實有利於傳統企業新業務的快速構建和發展。
共享業務服務中台因其統一、共享、高復用性等特點，決定了共享服務的成熟是需要經過海量業務洗禮的，互聯網企業的業務中台支撐的業務流量是非常巨大的，這也是為什么互聯網企業普遍拋棄了傳統的集中式或聯邦式SOA架構，轉而發展分布式微服務架構的根本原因。
共享服務的業務對象的特點基本上就是跨領域統一、共享和復用，包括基礎數據、主數據、關鍵事務數據、原子指標數據、公共的非結構化數據、統一元數據。
在構建共享的業務中台時，除了考慮到基於跨領域統一、共享和復用的業務數據對象外，還包括相應的業務處理能力，因此可以說是數據+業務處理能力共同構成了業務應用服務核心要素，包括基於主數據、基礎數據和關鍵事務數據等的公共業務服務和基礎服務；基於公共辦公數據（非結構化數據）的公共辦公服務；基於統一元數據的公共數據服務。
共享模式的業務中台相對於協同模式的業務中台（平台）具有更好的業務靈活性和服務復用性，兩者並非是“非此即彼”的關系，可以是不同業務階段的選擇，可以平滑演進，也可以同時存在互為補充。
（十四）：自助模式下的中台規划
在用戶支配的個性化互動模式下，用戶可以自助調取中台的能力來構建自己想要的前台，某種意義上是基於前台支配的人性化互動模式的更進一步發展。用戶的體驗用戶自己說了算，就像自助分析廠商Tableau說的那樣“自己做的報表才是體驗最好的報表”。用戶支配的個性化互動模式較常用於業務數據中台的規划和搭建，基於數據中台的自助數據分析和洞察是其典型應用。
業務中台支撐的是更好的業務運作，而數據中台則聚焦於通過數據洞察驅動業務變革，即在“掌握數據或信息”的基礎上“獲取洞察”，進而采取“行動”，優化決策策划以提升業務績效。除此之外，還需要不斷地“學習”，從每一次業務結果中獲得反饋，改善基於信息的決策流程，從而實現“數字化轉型”。
數據中台的內涵：數據產品的自動化生產線、供應鏈。
數據中台的外延：與傳統“物”的供應鏈類似，數據供應鏈包含“原始數據產生->數據獲取（采購）->數據存儲（倉儲）->數據增值加工->數據應用（消費）”全過程。數據中台基於數據供應鏈的相關能力，協調好環境、設施/設備、數據資源，給服務對象提供“可使用、可感知”的服務，與服務對象全程互動，滿足不同服務對象差異化的探索數據並創造價值的需求。
（十五）：感知模式下的中台規划
在我們實際的服務化架構中，除了用戶、前台、中台、后台之外，還應考慮到對服務環境的改造，使其更加有利於服務交互的過程。通過IoT使能的環境感知場景可以驅動“感知”模式的中台規划和構建，任何人都可以借助各種傳感器、IoT感知外部環境，獲得環境反饋並作出相應改變，加快與現實世界間的信息流動。“感知”模式的中台可以面向用戶或“協同、共享、自助”模式的中台提供“環境感知服務”。
環境感知服務的價值不外乎是線上線下或AB世界（Atomic & Bit World）的融合、讓數據流動更快、更實時的決策以及分析能力前移到一線等，並最終消除IT和OT之間的數字鴻溝。
感知模式的中台，就是要消除IT和OT之間的數字鴻溝，需要具備以下4種能力並提供“環境感知服務”：
1、工業大數據的融合：工業大數據的融合服務是個業務服務而非技術服務，這需要大量的不同專業領域的業務知識作為輸入，通過數據分析方法與工業機理知識的結合，打破“知識黑盒”的限制，對工業數據進行深度挖掘，方能提供更有價值的數據服務以滿足工業大數據需求。
2、雲計算和邊緣計算的融合：站在用戶的角度，用戶的計算需求是完整的，面向用戶的計算服務也應該是統一的，需要感知模式的中台整合雲計算和邊緣計算服務，面向用戶需求提供統一的計算服務。
3、IT和OT連接協議的融合：工業自動化市場上“一網到底的革命”就是將上層成熟度很高的商業以太網系統，直接接入到廠房設備的底層，但是距離實現統一的通訊協議與標准架構，還差得很遠，因為這里面涉及大量的IT和OT連接協議的融合工作。
4、統一應用軟件使能平台：工業互聯網應用的使能平台AEP（Application enable Platform）將L1到L5不同的軟件功能模塊統一到一個平台之上，並且輕松完成編譯、封裝和分發。
（十六）：中台的獨特技術要求
構建SaaS層的前中后台特別需要關注的技術能力或服務包括：
1、 前台應用需要統一UI組件。
2、 中台需要統一服務管理，滿足服務市場和服務編排的應用需求。
3、 SaaS層協同、共享、自助、感知的業務中台和數據中台需要調用PaaS層技術中台的統一、通用技術服務。
Contract First Design，CFD是一個很朴素的設計理念和方法，既然中台是以服務為中心滿足業務協同、共享、自助、感知的需求，那么中台業務應用服務的管理模式就應該與通用的業務服務管理模式一致（與GST的管理模式很類似），即基於契約的服務設計與運營管理。各類業務應用服務的技術實現，本質上是利用通信技術，把計算機里面承載的Bit資源，完整地共享出去，給應用系統瘦身，減少重復投資。這里的Bit資源，包括用於記錄業務狀態的Data和用於描述業務處理邏輯的Code，需要將Data和Code封裝成消息Message再傳輸。服務供給和消費方要有明確的服務責任邊界，並以契約化的方式約定好消息的標准格式，按照服務設計時和服務運營時的管理要求來協同。
我們在服務化技術架構和方案中經常提到的RESTful、SOAP、RPC等都可以視為按照CFD理念和方法形成的不同的服務風格，而SOA、微服務則更多地屬於不同的服務化軟件架構。
“業務協同、共享、自助、感知的中台規划和建設，需要華為雲平台的技術方案支撐”。
（十七）：中台實施路徑規划
中台實施路徑規划目的在於對准業務價值和發展方向，規划客戶IT2.0架構驅動的業務前台、中台自主知識產權的IT產品路標及項目。
- 1、 首先需要站在IT視角，對准業務發展目標的業務場景中的IT使能的標准化業務場景，即可以通過IT支撐自運營的確定性業務場景，其執行流程和規則是標准化、規范化、結構化的，不需要太多的人工干預。
- 2、 IT舉措源自於業務痛點的IT變革需求，我們需要認識到，要解決一個業務痛點問題，單單只是IT變革是不夠的，必須結合業務變革以形成完整的業務解決方案。
- 3、 IT項目封裝是業務痛點的IT變革需求以及IT2.0架構落地舉措交叉匯聚的結果，一方面要對准業務發展目標的業務場景中的IT使能的標准化業務場景，解決具體的業務痛點問題，另一方面需要按照IT2.0服務化IT架構的要求，按照前中后台來設計並建設IT系統。
- 4、 最后，封裝並定義好的中台實施項目，需要按照戰略匹配度、問題緊急程度、依賴因素的成熟度、能及時感知的收益等角度評估其優先級，綜合考慮並規划項目的實施路標，以及項目的投資匡算。
按照SaaS、PaaS、IaaS三層，加上運維和運營以及安全兩個公共能力，划分整個架構落地舉措，明確IT2.0架構落地需要做的事情有哪些。
- 1、 對於SaaS層來說，這是服務化IT架構落地的重點，包括了從傳統的IT1.0時代的基於軟件包的單體應用，向公司級前中后台演進的相關舉措。
- 2、 對於PaaS層來說，重要的是支持SaaS層前中后台應用的實施，包括應用的開發時和運行時，尤其是要滿足中台實施的特定技術要求。除此之外，通過對技術平台的服務化改造構建技術中台，支撐應用從“開發”走向“制作”，降低用戶有效利用IT專業技術的門檻。
- 3、 對於IaaS層來說，主要是基礎設施全面雲化建設和管理，目的是為了實現更好的IT資源共享。
- 4、 對於兩個公共能力來說，運維和運營、安全的落地舉措更多的依賴於雲化、服務化平台的整體方案，與中台的實施是松耦合的關系。
IT項目封裝是業務痛點的IT變革需求以及IT2.0架構落地舉措交叉匯聚的結果，通過對IT使能業務場景的洞察，對齊IT2.0架構落地的舉措，可以明確具體的階段任務，進而明確各階段性項目要達成的目標。最后按照多維度評估項目的優先級，綜合考慮並規划項目的實施路標，以及項目的投資匡算，完成整個中台及中台相關的實施路徑規划。
對於傳統行業來說，企業中台的建設一定是業務自己的事情，沒有哪家企業的中台是長得一摸一樣的，因為中台建設的出發點就是幫助企業構建業務服務競爭優勢，這一定是一個結合各家企業的業務實際特點，持續構建，持續優化，持續提升的過程。知易行難，行勝於言，只要對准業務價值，動起來了，持續優化，未來可期，一切皆有可能。
本文分享自華為雲社區《IT2.0業務中台規划牽引客戶IT基礎設施投資隨想 （十八）：收尾篇》，原文作者：APTX-486977 。