在中臺概念甚囂塵上的時候，無論大中小型企業(yè)都在加速建設(shè)自家的中臺系統(tǒng)。不過隨著這股熱潮冷靜下來后，有的企業(yè)開始發(fā)現(xiàn)：做中臺，沒有那么簡單！

《邯鄲學步》：戰(zhàn)國時期，有個燕國少年聽說趙國邯鄲人走路的姿勢特別美，于是不顧路途遙遠，到邯鄲當?shù)貙W人家走路。結(jié)果他不但沒學會人家走路的姿勢，還把自己原來走路的姿勢也忘記了，最后只好爬著回去。

這個例子同樣適用于某些盲目做中臺的企業(yè)們。

接下來，我就簡單跟大家聊聊我被問到的一些與中臺有關(guān)的問題：

第一次被問到中臺：

2017年，來自物流行業(yè)某科技公司：你對中臺怎么看？

我說：阿里巴巴快速發(fā)展期間建了很多重復的業(yè)務(wù)系統(tǒng)，后來的系統(tǒng)整合嗎？

對方正在負責中臺建設(shè)業(yè)務(wù)，作為顧問，這個回答未免太實在。

第二次：

2018年協(xié)助一家保險行業(yè)的客戶提升組織效能，逐步沉淀出清晰的前中后臺協(xié)同流程。

客戶認為，這些要做，但是不夠大，還要更大、更高屋建瓴的方案；于是又提議了客戶聚焦（Customer Fucus）的整體方案，重點優(yōu)化線上營銷端到端流程，面向高價值客戶快速上市產(chǎn)品組。

結(jié)果最后客戶提出，你能不能給我們培訓一下中臺。

最后一次：

2019年在某大會上遇到了某銀行的顧問同仁，問我：中臺團隊如何評價績效和價值？

我說：中臺當然按消費者（Consumer）調(diào)用的SLA來評價呀。

對方說：比如一個模塊，在做之前，如何通過價值評價來決策做或者不做？

我說這不是架構(gòu)師的職責嗎？中臺沒有架構(gòu)師嗎？那這個中臺是怎么做出來的？

對方：現(xiàn)在就是沒有人能評估這個事兒，所以做出來爭議很大，中臺團隊也感覺不到自己的存在感……

常言道B端決策緩慢又理性，為什么中臺卻如此迅速地席卷大江南北，從不斷升溫到碎片一地，中臺究竟給我們什么樣的啟示？企業(yè)在面臨新的技術(shù)概念時，如何更有條理地看待和采納？

1. 中臺本質(zhì)：企業(yè)架構(gòu)治理

盡管如今已經(jīng)步入了Microservices與Cloud Native階段了，但如果不是一家游戲類、照片類、音視頻類純數(shù)字化公司（據(jù)我觀察，這類公司是最早采用云計算技術(shù)的），我推崇還是搞清楚早期Microsoft的一篇架構(gòu)文檔中說明的三種架構(gòu)層次。

為什么？

就像早期熟悉云計算架構(gòu)必須看Amazon的技術(shù)白皮書一樣，作為企業(yè)服務(wù)領(lǐng)域的一哥，Microsoft的總結(jié)有極強的參考價值：

• 應用架構(gòu)（Application Architecture），即系統(tǒng)技術(shù)架構(gòu)，通常表現(xiàn)為帶有數(shù)據(jù)庫的三層/多層技術(shù)架構(gòu)體系。
• 產(chǎn)品/項目架構(gòu)（Product/Project Architecture），后期又稱之為解決方案架構(gòu)（Solution Architecture），解決方案層與應用層的區(qū)別在于，它是業(yè)務(wù)導向的，致力于提升應用系統(tǒng)的業(yè)務(wù)質(zhì)量。
• 企業(yè)架構(gòu)（Enterprise Architechture），它其實是一個規(guī)劃過程，識別企業(yè)IT未來應該達到的狀態(tài)，并實施一系列的計劃，使項目團隊通過交付達成。

1.1 中臺如何應對來自以用戶為中心的業(yè)務(wù)挑戰(zhàn)

以用戶為中心（Customer-centric）意味著向消費驅(qū)動的轉(zhuǎn)變。企業(yè)產(chǎn)品與服務(wù)的推出不再內(nèi)部可控，而是需要快速捕獲外部用戶的變化并響應用戶的需求。

曾經(jīng)有客戶問：業(yè)務(wù)部門一年復一年人員都沒有增長，提需求的就是這些人，為啥我們的技術(shù)部門人員年年增長還不能完成需求？

原因就在于：提需求的人是沒有增長，但提需求的節(jié)奏、頻率、變化都大大提升了。

中臺大火，正是作為“包治百病”的神藥誕生。而對中臺一詞最不感冒的是電信業(yè)的小伙伴，“這些玩意不是電信業(yè)務(wù)軟件中早就實現(xiàn)過的？憑空造些概念出來?！?/p>

沒錯，中臺的很多概念，您都可以從Gabriel Morgan（前微軟企業(yè)戰(zhàn)略規(guī)劃部、現(xiàn)星巴克企業(yè)架構(gòu)部主管）在2007的這篇文章《Service Delivery Platform (SDP) for the Enterprise》中找到答案，其借鑒的正是電信業(yè)SDP（Service Delivery Platform）快速交付業(yè)務(wù)服務(wù)的思路。文中Morgan提出：

We all know that SOA is a powerful tool to enable an agile business but … Well, it turns out that the telecom industry has largely solved this and are working on the challenges of what comes next.

…SOA…Through continuous improvement and change in the business, we will continually modify our architecture to advance our business and be more competitive.

For example, based on the needs of faster delivery of services, there are higher levels of sophistication in how to do?Service Management with features like Service Naming, Registry and Location Services, Service Policy Management, Service Quality Management, Service Configuration Management, and Service Rating and Discounting Management.

Another example, is the sophistications in how an enterprise will handle supporting shared services.?Enterprise Architectures will need to support shared services and will require sophistications in Dev and Test environments, Governance process and team models, SDLC modifications, Customer Support and Service Consultation/On-boarding.

And finally, there are levels of sophistication how the enterprise architecture will look in S+S scenarios such as process, information and system integration with cloud services. Or, resolve how the architecture will handle partner collaboration and customer-centric challenges the business strive for.

2007年時還沒有Micoroservice架構(gòu)，后來由Netflix在整合移動多屏及個性化時被實現(xiàn)。

所以，粗體字充分展示了Morgan在技術(shù)概念上的準確定義，一旦概念被定義出來，它就可以被理解或不理解的人傳播了，因為無法通過“為每個服務(wù)定義一個唯一名稱變量，然后在調(diào)用時通過從數(shù)據(jù)庫查詢這個唯一名稱字段找到服務(wù)地址”這樣的描述來向不懂的業(yè)務(wù)領(lǐng)導介紹服務(wù)命名。

1.2 中臺成功核心在于業(yè)務(wù)治理

同時Morgan在另一篇文章《Adoption, rather than Architecture, is the high order bit for Architects》中指出，企業(yè)架構(gòu)最重要的是組織對齊?！皩R”是國內(nèi)某家企業(yè)跨部門溝通最愛用的詞，也充分體現(xiàn)了該企業(yè)強大的組織能力。

中臺與ESB的核心差異是什么？

在于業(yè)務(wù)服務(wù)能力（Capability）的下沉。

ESB是消息總線，解決系統(tǒng)異構(gòu)信息交換問題，而中臺集成的是各種服務(wù)提供方，解決業(yè)務(wù)能力共享的問題。

中臺服務(wù)面向的顆粒度更細，更強調(diào)的是封裝完整的業(yè)務(wù)資源、邏輯和流程，每個服務(wù)有更強的自治性，而ESB的出現(xiàn)更單純地是為了解決系統(tǒng)層面的協(xié)作。

比如說，早年企業(yè)針對銷售部門有一個訂單管理系統(tǒng)，后來針對售后部門又開發(fā)了一個服務(wù)管理系統(tǒng)，最后發(fā)現(xiàn)，售后需要回溯銷售合同的條款，一開始通過批量同步，還行；后面量大了，批量處理已經(jīng)延后了，就需要兩個系統(tǒng)更及時地同步。

如果作為中臺架構(gòu)師，在業(yè)務(wù)資源識別時，最徹底的就是面向客戶建立全生命周期的產(chǎn)品管理服務(wù)體系。

早期的共享信息數(shù)據(jù)（SID）模型就是這樣的架構(gòu)。

建設(shè)中臺或任何企業(yè)級中心化的系統(tǒng)，需要權(quán)衡的就是如何協(xié)調(diào)不同使用部門之間的利益點。

比如說，某些部門不希望花費過多精力在系統(tǒng)建設(shè)上，那么組織提供的共享資源就很有用處；而某些部門希望能夠快速響應經(jīng)常變化、個性化的需求，那么組織級平臺就可能拖累他們的節(jié)奏；而還有一些部門根本就不想與其它系統(tǒng)有依賴，那這樣的共享服務(wù)對他們而言就沒有存在的必要。

中臺并不神秘，當企業(yè)想建設(shè)中臺時，首先應當考慮的是，業(yè)務(wù)部門的需求究竟是什么，他們希望改進什么方面？他們及涉及的利益相關(guān)者愿意為這個改進作出多大業(yè)務(wù)上的對齊？誰能夠承擔企業(yè)架構(gòu)師的角色？

很多架構(gòu)師其實只是一個高級程序員，并不具備權(quán)衡（Tradeoffs）的能力和魄力。否則，這不應該成為中臺項目，更好的處理模式是在解決方案或應用層面尋找優(yōu)化措施。

早期的Connected Services Framework，在許多國外大型機構(gòu)中演進成為Shared Services架構(gòu)。

2. 為什么你無法復制中臺？

阿里巴巴業(yè)務(wù)本身就是平臺型、開放型，但僅僅因為業(yè)務(wù)形態(tài)，也不足說明非平臺型公司不能建中臺，畢竟建成后效率更高啊。但企業(yè)需要意識到，阿里巴巴成功建設(shè)中臺，原因有兩點：

1. 是對現(xiàn)有資源的整合而不是新建
2. 由內(nèi)部團隊驅(qū)動而不是外部公司承接

2.1 可重用的資源：你有服務(wù)資產(chǎn)來建設(shè)中臺嗎？

中臺普遍采用服務(wù)、API來集成提供業(yè)務(wù)能力，許多企業(yè)第一步就是欠缺的，沒有這些服務(wù)和API；通常我們說的“服務(wù)化”，意思是把現(xiàn)有的組件封裝為Web Service，以提供更強的復用能力，比如說，一個Java的組件，只有Java的程序能調(diào)用，但封裝為服務(wù)之后，PHP/Node.js/iOS/Android全都可以支持了，就極大地提升了后端程序的復用性。

但事實上去到企業(yè)一看，很多系統(tǒng)連組件邊界都不清晰，這個服務(wù)化，其實在幫助企業(yè)進行應用架構(gòu)（Application Architecture）層面的模塊化梳理。許多企業(yè)連模塊化都不想做，就要一步上中臺，怎么辦，請外部公司空降PPT畫大餅、做培訓、倉促上馬半成品，結(jié)果可想而知。

2.2 運行維護和保障：你有工程能力來建設(shè)中臺嗎？

比如最簡單的一個問題，中臺上一個服務(wù)有多個消費者，如何進行版本升級？內(nèi)部組件如何做到灰度部署？如何回滾？

事實是，關(guān)于服務(wù)要不要有版本編號，版本編號到底是不是一個值得采納的工程實踐，業(yè)界都還在踩坑、爭論。

運轉(zhuǎn)中的中臺，復雜度超過一般的系統(tǒng)運行維護，沒有規(guī)范、沒有自動化、沒有云平臺管理能力的企業(yè)，很難玩轉(zhuǎn)中臺。即使空降一個中臺系統(tǒng)，落后的管理方式也只能將高鐵按照大巴時刻發(fā)車。

3. 如何穩(wěn)步走向服務(wù)化戰(zhàn)略

茅臺這張PPT問題在哪里？

在于沒有給出路徑。

與“中臺”這個名詞相比，我還是更喜歡使用面向服務(wù)的戰(zhàn)略來表述以用戶為中心的未來IT架構(gòu)轉(zhuǎn)變。

3.1 用戶驅(qū)動：顯性化你的中臺業(yè)務(wù)價值

更個性化、更快地響應最終用戶的請求，尤其是外部用戶的請求，應該是中臺構(gòu)建的業(yè)務(wù)價值目標。如果中臺僅僅是優(yōu)化內(nèi)部業(yè)務(wù)，由于業(yè)務(wù)價值不明確，或難于衡量，將可能導致不及預期、難于協(xié)調(diào)一致多個部門，所以由外部用戶感知的業(yè)務(wù)價值驅(qū)動，更能有效地落地業(yè)務(wù)資源與流程的整合。

比如說，利用用戶旅程分析工具，將過去用戶需要面對多個業(yè)務(wù)人員的流程優(yōu)化為一項自助式服務(wù)，并支持在移動端、PC端和終端多處完成。定義用戶服務(wù)請求的監(jiān)控指標改進，包括業(yè)務(wù)處理時間、業(yè)務(wù)流量、交易量，等，即決定了此項優(yōu)化的業(yè)務(wù)價值。

3.2 團隊自治：構(gòu)建你的高效面向業(yè)務(wù)服務(wù)的基層文化

如果你的團隊并不能真正理解服務(wù)化/中臺的好處，如此龐大的工程不可能真正落地。因為中心化的系統(tǒng)建設(shè)涉及的范圍太廣了，一條規(guī)范不能被正確執(zhí)行，都會留下后期調(diào)用的隱患。

讓過去涉及到多個業(yè)務(wù)協(xié)作的系統(tǒng)團隊進行合作，設(shè)計出新的解決方案，讓他們直接面向業(yè)務(wù)部門收集的反饋，或用戶使用的行為指標、報告作出響應。

如果發(fā)現(xiàn)在這個團隊中，他們依然還需要依賴第三方的人、系統(tǒng)來解決問題，那么自治式還不夠好，需要進一步解除依賴。雖然這在許多金融機構(gòu)聽起來不太可能，但如果這些問題都解決不了，誰又能真正承諾最終交付的中臺服務(wù)能夠高效響應呢？

3.3 服務(wù)管理：一步步加強你的中心團隊治理能力

隨著服務(wù)越來越多，需要有專門的服務(wù)管理團隊，接手服務(wù)基礎(chǔ)設(shè)施、目錄，并完善高可用、監(jiān)控和運營治理。

可以為服務(wù)管理團隊設(shè)立服務(wù)規(guī)劃部門，一步一步為企業(yè)的服務(wù)化/中臺戰(zhàn)略進行未來狀態(tài)的導引。

總結(jié)

中臺不是一個新事物，也并不神秘。重視中臺，說明中國的企業(yè)開始意識到IT的重要性，以及企業(yè)架構(gòu)帶來的巨大能效優(yōu)勢。不應因“茅臺中臺事件”因噎廢食，前車之鑒，供我們制定更加合理的轉(zhuǎn)型提速節(jié)奏。

本文由 @陳加興 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議