IT2.0業務中臺規劃牽引客戶IT基礎設施投資隨想 （十八）：收尾篇

歷經18篇，終于算是完成了這個中臺系列了。

從一開始只是想結合一個實際交付的業務中臺規劃咨詢項目，講講協同和共享模式的業務中臺架構規劃的一點體會，逐步擴大到整個企業中臺規劃隨想，計劃趕不上心里的變化，只能是想到哪兒寫到哪兒了，可能有部分內容講的還不夠細致，例如數據中臺、物聯中臺和技術中臺，還需要在后續進一步完善，請大家多多包涵。企業中臺規劃是現在的市場熱點，幾乎每一個客戶都會提出中臺規劃相關的問題，都需要我們來正確引導，希望能通過這個系列，讓大家對中臺的價值、針對的問題痛點、中臺規劃的方法思路和技巧、一些中臺業務實踐有個基本的認識，讓客戶清楚的意識到企業中臺的業務價值，進而通過企業中臺規劃牽引客戶IT基礎設施投資。

接下來想對前面的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架構落地的舉措，可以明確具體的階段任務，進而明確各階段性項目要達成的目標。最后按照多維度評估項目的優先級，綜合考慮并規劃項目的實施路標，以及項目的投資匡算，完成整個中臺及中臺相關的實施路徑規劃。

項目管理 ProjectMan

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。