在中臺概念甚囂塵上的時候，無論大中小型企業都在加速建設自家的中臺系統。不過隨著這股熱潮冷靜下來後，有的企業開始發現：做中臺，沒有那麼簡單！
《邯鄲學步》：戰國時期，有個燕國少年聽說趙國邯鄲人走路的姿勢特別美，於是不顧路途遙遠，到邯鄲當地學人家走路。結果他不但沒學會人家走路的姿勢，還把自己原來走路的姿勢也忘記了，最後只好爬著回去。
這個例子同樣適用於某些盲目做中臺的企業們。
接下來，我就簡單跟大家聊聊我被問到的一些與中臺有關的問題：
第一次被問到中臺：
2017年，來自物流行業某科技公司：你對中臺怎麼看？
我說：阿里巴巴快速發展期間建了很多重複的業務系統，後來的系統整合嗎？
對方正在負責中臺建設業務，作為顧問，這個回答未免太實在。
第二次：
2018年協助一家保險行業的客戶提升組織效能，逐步沉澱出清晰的前中後臺協同流程。
客戶認為，這些要做，但是不夠大，還要更大、更高屋建瓴的方案；於是又提議了客戶聚焦（Customer Fucus）的整體方案，重點優化線上營銷端到端流程，面向高價值客戶快速上市產品組。
結果最後客戶提出，你能不能給我們培訓一下中臺。
最後一次：
2019年在某大會上遇到了某銀行的顧問同仁，問我：中臺團隊如何評價績效和價值？
我說：中臺當然按消費者（Consumer）調用的SLA來評價呀。
對方說：比如一個模塊，在做之前，如何通過價值評價來決策做或者不做？
我說這不是架構師的職責嗎？中臺沒有架構師嗎？那這個中臺是怎麼做出來的？
對方：現在就是沒有人能評估這個事兒，所以做出來爭議很大，中臺團隊也感覺不到自己的存在感……
常言道B端決策緩慢又理性，為什麼中臺卻如此迅速地席捲大江南北，從不斷升溫到碎片一地，中臺究竟給我們什麼樣的啟示？企業在面臨新的技術概念時，如何更有條理地看待和採納？
1. 中臺本質：企業架構治理
儘管如今已經步入了Microservices與Cloud Native階段了，但如果不是一家遊戲類、照片類、音視頻類純數位化公司（據我觀察，這類公司是最早採用雲計算技術的），我推崇還是搞清楚早期Microsoft的一篇架構文檔中說明的三種架構層次。
為什麼？
就像早期熟悉雲計算架構必須看Amazon的技術白皮書一樣，作為企業服務領域的一哥，Microsoft的總結有極強的參考價值：
應用架構（Application Architecture），即系統技術架構，通常表現為帶有資料庫的三層/多層技術架構體系。產品/項目架構（Product/Project Architecture），後期又稱之為解決方案架構（Solution Architecture），解決方案層與應用層的區別在於，它是業務導向的，致力於提升應用系統的業務質量。企業架構（Enterprise Architechture），它其實是一個規划過程，識別企業IT未來應該達到的狀態，並實施一系列的計劃，使項目團隊通過交付達成。
1.1 中臺如何應對來自以用戶為中心的業務挑戰
以用戶為中心（Customer-centric）意味著向消費驅動的轉變。企業產品與服務的推出不再內部可控，而是需要快速捕獲外部用戶的變化並響應用戶的需求。
曾經有客戶問：業務部門一年復一年人員都沒有增長，提需求的就是這些人，為啥我們的技術部門人員年年增長還不能完成需求？
原因就在於：提需求的人是沒有增長，但提需求的節奏、頻率、變化都大大提升了。
中臺大火，正是作為「包治百病」的神藥誕生。而對中臺一詞最不感冒的是電信業的小夥伴，「這些玩意不是電信業務軟體中早就實現過的？憑空造些概念出來。」
沒錯，中臺的很多概念，您都可以從Gabriel Morgan（前微軟企業戰略規劃部、現星巴克企業架構部主管）在2007的這篇文章《Service Delivery Platform (SDP) for the Enterprise》中找到答案，其借鑑的正是電信業SDP（Service Delivery Platform）快速交付業務服務的思路。文中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架構，後來由Netflix在整合移動多屏及個性化時被實現。
所以，粗體字充分展示了Morgan在技術概念上的準確定義，一旦概念被定義出來，它就可以被理解或不理解的人傳播了，因為無法通過「為每個服務定義一個唯一名稱變量，然後在調用時通過從資料庫查詢這個唯一名稱欄位找到服務地址」這樣的描述來向不懂的業務領導介紹服務命名。
1.2 中臺成功核心在於業務治理
同時Morgan在另一篇文章《Adoption, rather than Architecture, is the high order bit for Architects》中指出，企業架構最重要的是組織對齊。「對齊」是國內某家企業跨部門溝通最愛用的詞，也充分體現了該企業強大的組織能力。
中臺與ESB的核心差異是什麼？
在於業務服務能力（Capability）的下沉。
ESB是消息總線，解決系統異構信息交換問題，而中臺集成的是各種服務提供方，解決業務能力共享的問題。
中臺服務面向的顆粒度更細，更強調的是封裝完整的業務資源、邏輯和流程，每個服務有更強的自治性，而ESB的出現更單純地是為了解決系統層面的協作。
比如說，早年企業針對銷售部門有一個訂單管理系統，後來針對售後部門又開發了一個服務管理系統，最後發現，售後需要回溯銷售合同的條款，一開始通過批量同步，還行；後面量大了，批量處理已經延後了，就需要兩個系統更及時地同步。
如果作為中臺架構師，在業務資源識別時，最徹底的就是面向客戶建立全生命周期的產品管理服務體系。
早期的共享信息數據（SID）模型就是這樣的架構。
建設中臺或任何企業級中心化的系統，需要權衡的就是如何協調不同使用部門之間的利益點。
比如說，某些部門不希望花費過多精力在系統建設上，那麼組織提供的共享資源就很有用處；而某些部門希望能夠快速響應經常變化、個性化的需求，那麼組織級平臺就可能拖累他們的節奏；而還有一些部門根本就不想與其它系統有依賴，那這樣的共享服務對他們而言就沒有存在的必要。
中臺並不神秘，當企業想建設中臺時，首先應當考慮的是，業務部門的需求究竟是什麼，他們希望改進什麼方面？他們及涉及的利益相關者願意為這個改進作出多大業務上的對齊？誰能夠承擔企業架構師的角色？
很多架構師其實只是一個高級程式設計師，並不具備權衡（Tradeoffs）的能力和魄力。否則，這不應該成為中臺項目，更好的處理模式是在解決方案或應用層面尋找優化措施。
早期的Connected Services Framework，在許多國外大型機構中演進成為Shared Services架構。
2. 為什麼你無法複製中臺？
阿里巴巴業務本身就是平臺型、開放型，但僅僅因為業務形態，也不足說明非平臺型公司不能建中臺，畢竟建成後效率更高啊。但企業需要意識到，阿里巴巴成功建設中臺，原因有兩點：
是對現有資源的整合而不是新建由內部團隊驅動而不是外部公司承接
2.1 可重用的資源：你有服務資產來建設中臺嗎？
中臺普遍採用服務、API來集成提供業務能力，許多企業第一步就是欠缺的，沒有這些服務和API；通常我們說的「服務化」，意思是把現有的組件封裝為Web Service，以提供更強的復用能力，比如說，一個Java的組件，只有Java的程序能調用，但封裝為服務之後，PHP/Node.js/iOS/Android全都可以支持了，就極大地提升了後端程序的復用性。
但事實上去到企業一看，很多系統連組件邊界都不清晰，這個服務化，其實在幫助企業進行應用架構（Application Architecture）層面的模塊化梳理。許多企業連模塊化都不想做，就要一步上中臺，怎麼辦，請外部公司空降PPT畫大餅、做培訓、倉促上馬半成品，結果可想而知。
2.2 運行維護和保障：你有工程能力來建設中臺嗎？
比如最簡單的一個問題，中臺上一個服務有多個消費者，如何進行版本升級？內部組件如何做到灰度部署？如何回滾？
事實是，關於服務要不要有版本編號，版本編號到底是不是一個值得採納的工程實踐，業界都還在踩坑、爭論。
運轉中的中臺，複雜度超過一般的系統運行維護，沒有規範、沒有自動化、沒有雲平臺管理能力的企業，很難玩轉中臺。即使空降一個中臺系統，落後的管理方式也只能將高鐵按照大巴時刻發車。
3. 如何穩步走向服務化戰略
茅臺這張PPT問題在哪裡？
在於沒有給出路徑。
與「中臺」這個名詞相比，我還是更喜歡使用面向服務的戰略來表述以用戶為中心的未來IT架構轉變。
3.1 用戶驅動：顯性化你的中臺業務價值
更個性化、更快地響應最終用戶的請求，尤其是外部用戶的請求，應該是中臺構建的業務價值目標。如果中臺僅僅是優化內部業務，由於業務價值不明確，或難于衡量，將可能導致不及預期、難於協調一致多個部門，所以由外部用戶感知的業務價值驅動，更能有效地落地業務資源與流程的整合。
比如說，利用用戶旅程分析工具，將過去用戶需要面對多個業務人員的流程優化為一項自助式服務，並支持在移動端、PC端和終端多處完成。定義用戶服務請求的監控指標改進，包括業務處理時間、業務流量、交易量，等，即決定了此項優化的業務價值。
3.2 團隊自治：構建你的高效面向業務服務的基層文化
如果你的團隊並不能真正理解服務化/中臺的好處，如此龐大的工程不可能真正落地。因為中心化的系統建設涉及的範圍太廣了，一條規範不能被正確執行，都會留下後期調用的隱患。
讓過去涉及到多個業務協作的系統團隊進行合作，設計出新的解決方案，讓他們直接面向業務部門收集的反饋，或用戶使用的行為指標、報告作出響應。
如果發現在這個團隊中，他們依然還需要依賴第三方的人、系統來解決問題，那麼自治式還不夠好，需要進一步解除依賴。雖然這在許多金融機構聽起來不太可能，但如果這些問題都解決不了，誰又能真正承諾最終交付的中臺服務能夠高效響應呢？
3.3 服務管理：一步步加強你的中心團隊治理能力
隨著服務越來越多，需要有專門的服務管理團隊，接手服務基礎設施、目錄，並完善高可用、監控和運營治理。
可以為服務管理團隊設立服務規劃部門，一步一步為企業的服務化/中臺戰略進行未來狀態的導引。
總結
中臺不是一個新事物，也並不神秘。重視中臺，說明中國的企業開始意識到IT的重要性，以及企業架構帶來的巨大能效優勢。不應因「茅臺中臺事件」因噎廢食，前車之鑑，供我們制定更加合理的轉型提速節奏。
本文由 @陳加興 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議