引子

Supercell是一家典型的以小團隊模式進行游戲開發(fā)的公司。在公司里，一般來說5個員工、最多不超過7個員工組成獨立的開發(fā)團隊，稱之為Cell（細胞），這也是公司名字Supercell（超級細胞）的由來。我們耳熟能詳?shù)牡挠螒颉恫柯鋺?zhàn)爭》、《海盜奇兵》均出自這家全世界最成功的移動游戲公司之手。

在Supercell，團隊自己決定做什么樣的產(chǎn)品，然后用最快的時間推出產(chǎn)品的公測版，看看游戲是否受用戶歡迎。如果用戶不歡迎，團隊迅速放棄這個產(chǎn)品，再進行新的嘗試。

為什么很多游戲公司不具備Supercell這樣的能力呢？Supercell最核心的競爭力是它的“中臺”能力：在多年的游戲研發(fā)中積累的非常科學的研發(fā)方法（游戲開發(fā)素材、算法等）和體系（鼓勵創(chuàng)新的企業(yè)文化）。

為什么需要中臺

我們先看看今天企業(yè)IT系統(tǒng)建設的模式：當業(yè)務部門提出業(yè)務需求，信息部門進行系統(tǒng)集成商的招標，再進入到需求收集、需求分析、開發(fā)、測試、上線的項目周期中。這種完全基于業(yè)務需求建設系統(tǒng)的方式已經(jīng)成為過去20多年企業(yè)建設IT系統(tǒng)的標準流程。這樣的流程導致IT系統(tǒng)建設較早的企業(yè)內(nèi)部“煙囪”林立，這也是今天很多企業(yè)互聯(lián)網(wǎng)轉(zhuǎn)型困難的根節(jié)所在。

這樣“煙囪”的方式對企業(yè)的“傷害”有三個方面：

成本：重復功能建設和維護帶來的重復投資。大量的功能和業(yè)務在多個系統(tǒng)中同時存在，單單考慮開發(fā)和運維兩方面的成本投入，對于企業(yè)來說已經(jīng)是一種很顯性的成本和資源浪費。

效率：為了打通“煙囪”系統(tǒng)間的集成和協(xié)作，往往成本高昂。隨著很多企業(yè)業(yè)務的發(fā)展，要打通這些“煙囪”式系統(tǒng)之間的連接，以提高或優(yōu)化企業(yè)運營效率。這樣的場景在2005年后（因為在這個時間點上很多大企業(yè)已經(jīng)進行了多年的IT建設，有了不少的“煙囪”）逐步涌現(xiàn)，特別在如今的互聯(lián)網(wǎng)時代，如何更有效地整合內(nèi)部資源、更好地提升用戶體驗，實現(xiàn)各個系統(tǒng)間的交互成為必然發(fā)生的事情。

發(fā)展：不利于業(yè)務的沉淀和持續(xù)發(fā)展。從傳統(tǒng)IT系統(tǒng)建設的生命周期來看，一旦系統(tǒng)上線以后，就進入了運維階段。我們大多看到的是平均周期在幾個月、甚至半年進行一次的功能升級。而事實上業(yè)務的需求是與日俱增的，來自客戶、市場的反饋和信息都要求系統(tǒng)進行快速的響應，而傳統(tǒng)項目的迭代周期對業(yè)務的響應和支持越來越吃力。

采用“煙囪”方式建設的系統(tǒng)體系，企業(yè)中一個業(yè)務領(lǐng)域的數(shù)據(jù)和知識往往被打散在不同的系統(tǒng)中。采用系統(tǒng)打通的方式解決了眼前相關(guān)業(yè)務間的交互問題，但這樣的方式治標不治本。這也是在過去很多年中，在很多企業(yè)經(jīng)常上演的一幕：一個系統(tǒng)上線運行5到8年后，現(xiàn)有系統(tǒng)不管是技術(shù)架構(gòu)還是業(yè)務模型都不能滿足現(xiàn)在業(yè)務發(fā)展的需求。因此需要整體系統(tǒng)升級，而這樣的升級往往意味著對原有系統(tǒng)推倒重建。且不論這樣推倒式重建對于現(xiàn)有業(yè)務帶來影響的大小以及重復的資源投入，更重要的是對于之前多年業(yè)務的沉淀能保留多少，這對于企業(yè)來說可能是最大的資產(chǎn)流失。這個問題本質(zhì)上是由于系統(tǒng)所提供的服務能力沒有隨著企業(yè)業(yè)務的發(fā)展與時俱進。

回到本文開始的例子，Supercell之所以能成功，除了在企業(yè)文化方面鼓勵團隊進行業(yè)務創(chuàng)新和試錯外，更重要的是給業(yè)務創(chuàng)新的團隊提供了扎實的平臺資源。所以為業(yè)務的創(chuàng)新打造一個”中臺“十分重要。

阿里把服務化實施劃分為API as Service、Product as Service和Solution as Service三個階段，也可以看成服務化的初、中、高三個階段。

API as Service是最基本的要求，其具體任務就是要把中間件能力API服務化。完成了API as Service這一步以后，業(yè)務方的服務就可以接入服務化平臺，并使用共享服務平臺來管理自己的服務。這里暴露的是最初級的服務，在優(yōu)雅型、易用性和安全性上還需要改進，所以就需要下一個階段Product as Service。Product as Service把API形態(tài)的服務利用共享平臺“封裝服務”來向用戶暴露。這類組裝服務更面向業(yè)務場景、更專業(yè)化。對開發(fā)者來說，使用非常友好；對提供者來說，對這類服務的管理可以支持得非常細膩，并能提升管理服務的效率。

經(jīng)過這個階段，服務提供者提供的服務就不僅是一堆API的列表，還會包括從業(yè)務需求出發(fā)梳理出來的一系列場景化的服務接口。這一階段完成之后，為了讓共享服務平臺的能力更好地服務于業(yè)務，也為了讓各種業(yè)務場景和解決方案在共享服務平臺上達到最大程度的復用，需要有能力通過共享服務平臺的方式沉淀出解決方案，業(yè)務的擴展是基于服務的擴展而不是基于代碼的方式進行擴展，這就是Solution as Service。

后記

系統(tǒng)的建設要從生產(chǎn)模型升級到運營型模型、從版本模型升級到迭代模型。生產(chǎn)模型會因為10%的差異而重新建設100%的系統(tǒng)，運營型模型最大的優(yōu)勢是所有的沉淀都將被積累。推進共享服務的中臺戰(zhàn)略將助推企業(yè)數(shù)字化轉(zhuǎn)型，帶來生產(chǎn)效率的大幅度提升。

本文作者萬學凡，ThoughtWorks首席咨詢師，武漢。作者保留本文一切權(quán)利，未經(jīng)許可請勿轉(zhuǎn)載。