蘇寧創立於1990年，在中國和日本擁有兩家上市公司，是中國領先的商業企業，擁有25萬服務於蘇寧的員工，2017年蘇寧控股集團以5579億元的規模位居中國民營企業500強第二名。秉承"引領產業生態、共創品質生活"的企業使命，蘇寧產業經營不斷拓展，形成蘇寧易購、蘇寧物流、蘇寧金融、蘇寧科技、蘇寧置業、蘇寧文創、蘇寧體育、蘇寧投資八大產業板塊協同發展的格局。

作為網際網路零售和 O2O 模式的代表企業，蘇寧在6年的轉型路上，企業架構是如何演進的？又是如何治理的？傳統企業究竟如何轉身網際網路企業？本文根據喬新亮演講整理而成。

喬新亮

環球易購CTO

前蘇寧科技集團副Quattroporte

TGO鯤鵬會榮譽導師

SUC成員

1

背景介紹

我是喬新亮，在蘇寧負責架構管理和專案管理，還負責和雲、基礎平臺有關的研發管理工作。上層是如何做治理，下層是如何做支撐，這其中的挑戰只有自己清楚，也希望跟大家分享一下。大約2000年，我開始做和架構相關的工作，包括SOA、服務治理等。從技術的角度看，很多工作比較簡單，但是在真正推進的過程中，就會知道有很多值得考慮的地方。

本文主要介紹：

· 蘇寧的轉型之路；

· 蘇寧的企業架構演進；

· 蘇寧的技術路線；

· 蘇寧技術管理組織和治理；

· 一些心得分享。

2

企業的架構演進

下面兩張圖可能讓大家有一個印象：蘇寧的業務是很複雜的。2012年，第一次接觸蘇寧的時候，我還在IBM工作，單純地想蘇寧不就是賣電器的嗎？可能直到今天，很多人還是有這個誤解。實際情況當然不是，這是非常大的誤解。比如蘇寧有體育版塊，包括江蘇足球以及今天的國際米蘭。蘇寧的零售是全品類經營，不只賣電器，還賣其他商品。上市的公司只是蘇寧雲商，蘇寧沒有上市的置業，包括酒店、房地產等。這麼多業務都需要IT總部去支援。

接下來看看各個端。今天講的數字化，location based service，各個端都要支援。後端這麼多業務，需要組合起來，要IT去支援。這是一個Context。做技術、做架構師要有一個上下文，要考慮處理的場景是什麼。以前有這麼多的業態，只要處理好複雜的業務就好了。但今天開始走到了數字化，有移動端、PC、各種各樣家庭網際網路，流量是不可控制的。要處理的是很複雜的業務邏輯和海量交易，那麼，IT怎麼去支撐這些業務和交易。

做技術的人，要回答兩個問題。第一個是關於價值的問題，做技術的沒有直接價值，除非你對業務做了貢獻，如何幫助公司的業務快速發展，或者技術自己就是業務。第二，別跑得太快，否則結果不穩，摔倒了。大家都很關心：系統是不是宕機了？服務是不是不可用了？所以要進行平衡，如何做得既穩又快。蘇寧IT有一個戰略口號"穩定、安全、極致快"。任何一個應用、服務都要做到既穩定又安全又要快。這是一個理想，我們永遠在為這個理想努力。

站在我的角度，考慮的是怎麼能夠去平衡。大家記住，架構師有一個Context，做的任何設計都不是理想的，是有上下文和限制的，在這種情況下你的架構要能支援一定程度的穩定、安全、極致快。從技術語言的角度，就是功能性和非功能性。當IT技術變成很核心的生產力的時候，這些非功能性的需求，對於系統來說就變成功能性需求。監控、可用性、可靠性等，這是功能性需求。不能說一個服務只要上線就好了。能監控嗎？生產能看到嗎？可用效能保證嗎？有沒有考慮失敗的時候對業務的影響？它的可靠性怎麼樣？對別人服務的承諾、契約在極端的情況下會改變嗎？這是蘇寧，也是所有IT團隊要去考慮和處理的一個問題。

3

企業的架構演進

下面從業務和技術的角度，給大家分享一下這種挑戰蘇寧是怎麼做的。我分享更多的是，在做的過程中特別困難、甚至今天都在努力克服的問題。

我原來在IBM工作，為各種各樣的企業做過諮詢，包括國有企業、民營企業、壟斷企業、半壟斷的企業、完全市場競爭化的企業。每個企業對技術的看法不一樣，技術發揮的作用也是不一樣的。下面讓大家看一下蘇寧具體怎麼做。

蘇寧在這幾年轉型過程中，技術發揮了什麼樣的作用？我對於技術和業務的理解是，所有的技術都是為業務服務的。蘇寧在矽谷有一個研究院，剛剛過去的十月份，我去矽谷參觀了Facebook、LinkedIn等企業，大概有十幾天和他們深入交流，探討了這方面的問題。我們把企業模型簡化，從上到下是業務、產品、技術。下層所有的工作都是為業務做支撐。我們根據技術在裡面發揮的作用來看這是一傢什麼樣的企業。

如果一個開發人員做的東西就決定你的業務，這代表是什麼？技術的使用意味著更高效、更快，更能反饋市場的變化。這種企業在市場上是極具競爭力的。所謂的工程師文化，即工程師能決定業務。像谷歌、Facebook，特別符合這種文化。第二種是產品決定業務，不是業務人員決定公司應該怎麼做。像LinkedIn、中國很多的網際網路公司大多都在這個位置。第三種就是業務決定。業務提要求，下面開發人員做開發。

蘇寧是在逐步演變的。公司業務到底是由業務人員決定，還是產品經理決定，還是開發工程師決定？大家肯定覺得由最底層決定最好。事實上不是的。如果開發工程師根本就不思考業務，你讓他決定公司的業務，那將是一場災難。這是一個辯證的關係。我作為技術的管理者，經常會思考如何去拿捏這個度。你是希望眼睛往下面看，這是目標，並不代表公司會立刻變成這樣。

我們從技術、方法論的角度來看，蘇寧在思考什麼。現在技術界有一句話，"架構不是設計出來的，架構是演變出來的"，我覺得太極端了。古人講中庸之道是最好的。架構是否設計和演變，跟架構師很有關係。設計任何的架構，都會有上下文，有限制，這代表著中庸的態度，一定要適合當時場景，平衡權益。而蘇寧在這個過程中，引入了企業架構，開始做規劃。

這是蘇寧轉型過程中比較困難的一個環節。什麼叫企業架構，可能很多人聽到過，實際可能跟工作沒有太多的關係。但是企業架構的思維方式是跟你有關的。比如，一個城市可以野蠻式生長，不用規劃。中國很多城市建設就是挖了填，再挖再填，跟我們的系統建設很像。另外一種情況是，一個城市使勁做規劃，根本不落地。

我畢業之後一直在北京，北京建設規劃了一個又一個環，現在到七環。環狀設計的確給今天北京交通帶來很大的問題，但並不代表不應該做規劃。很多人也知道，環的設計也給北京交通帶來很大益處。那麼，我的觀點是，架構是邊規劃邊演進的，然後還有做治理。這個時候就應該要考慮如何分配，誰去做規劃，誰去做演進，誰去做治理。

某些企業裡的治理者可能有官僚主義，這是我規劃的，你就得照著我的規劃做。這個時候大家會說，這種方法太差勁了，不用規劃，直接做。結果各自演進，變成一種混沌狀態。真正良好的過程是，要去做規劃，並且要去演進。負責人，尤其是做規劃、做治理的人，要有傾聽機制，有服務的心態，要思考如何服務各研發團隊。如果開發人員能夠去思考他做的技術功能是如何支撐企業戰略，如果公司每個人都思考這個問題，那麼這個公司絕對很了不起。具有工程師文化的公司，對人員、工程師要求很高，從戰略，到業務、應用、技術，最後到實施都管控起來，這是企業架構方法論需要處理的一個問題。

規劃是做正確的事，治理是把事做正確。企業架構很關鍵的一點是，有一個很好的反饋機制。企業構是回答企業的問題，產品經理應該思考這個問題，開發人員更應該思考這個架問題。如果企業裡每個人都在思考這個問題，並關聯上自己做的事情，那這個企業會非常有活力。

蘇寧企業架構怎麼做的，看一下理想情況下的過程。目前的業務、技術在什麼水平，我想把它演進成哪個程度、哪個水平，分析差距，找到要做的專案，然後去實施、評估，不斷重複這個過程。到今天，蘇寧都沒有完全做到這一點，但是要不斷去做，讓大家做的事情匹配公司的戰略。

我們看一下具體做的過程。

2011年的時候，我們意識到業務和資訊戰略對齊的重要性，但是大多數時候還是靠各自業務線去驅動。從2012年開始，成立了一個專門做企業架構的團隊，這個團隊更多做的是應用架構層面的事情。那個時候團隊管控的範圍還比較表面，公司內部對其重要性的認識也不是很深。那麼，這個組織架構，除了有自己的規劃之外，還發揮什麼作用呢？當各個研發中心出現工作衝突的時候，這個決策性的組織就出現了。在蘇寧常說的一句話："找架構師來切一下，這個應該在哪裡做。"出現問題，首先應該是在組織裡找原因，而不是找一個人的原因。

後來，蘇寧開始設計整個應用架構，包括資料資產的規劃和設計。我舉一個簡單的例子。一組資料有很多的系統，如果大家對它理解不一致，就會帶來很多問題，而這個問題是公司層面要去做治理的。直到今天，整個企業架構的治理流程和制度是比較完善的，先做規劃，然後釋出，最後反饋，如果在此過程當中有意見，可以不斷修訂。蘇寧所有研發中心包括四千多人，而這個應用架構的組織不到十人，資料架構只有三四個人，但是這個組織會管控很多核心的內容和設計，同時與各個研發中心之間有匹配和對應。

從治理的結果來看蘇寧的主體架構。可能很多人不了解，蘇寧今天已經不是一個SAP。蘇寧大概有1400多個系統，其中兩個系統和歷史遺留有關。一個是WCS，在2011年左右，WCS是其前臺的網站，是一個套裝軟體。一個是SAP，和供應鏈管理有關。但是，到今天已經完全不一樣了。

第一代架構:POS+ERP支撐線下規模擴張

上圖是第一代架構、蘇寧的門店，後臺是ERP，前臺是POS。這個架構在當年的價值就在於，很大程度上利用它，蘇寧業務超過了國美。使用這套體系能夠快速開店。當時國美在收購店面的時候，蘇寧是快速開店，其中一個很重要的原因是資訊化的支撐。從那個時候開始，蘇寧對IT的作用有了認識，吃到了甜頭，幾分鐘快速配置系統，就能做好開店的準備工作。

第二代架構:WCS+POS雙線作戰，搶灘線上

後來電子商務興起，蘇寧引進了IBM WCS電子商務套件，（上圖第二代架構）這個系統支撐了蘇寧好幾年的發展。它非常靈活，但有一個最大的問題是，當業務量增大、業務複雜的時候，它的速度很慢，而且擴充套件性差。在2012年的時候，當時資料庫用的是頂配的780小型機，不能支撐整體業務。2012年10月，我把這個套裝軟體做了拆分，可以橫向擴充套件。可以認為是應用的一個拆分，但是應用和資料庫被繫結，它的內部邏輯無法更改。把它擴充套件成物理部署，當時變成十倍，給蘇寧留了很長的時間能夠做後面系統的整個拆分和遷移，過渡階段不讓它受影響。這時候，我覺得系統的不穩定和擴充套件性，對蘇寧的業務是有影響的。在快速支撐和發展業務的時候，如何快速橫向擴充套件，這是很重要的一個考量點。

第三代架構:前中後架構重塑，O2O融合

從2012年開始，蘇寧一直在做的事情有兩方面的原因。第一考慮的是擴充套件性、效能的問題。把前臺網站的邏輯和後臺ERP的邏輯拆到中臺。蘇寧有一個很簡單的架構，就是前臺、中臺、後臺，前臺關注消費者，後臺關注內部運營管理，中臺的系統是重用的邏輯。涉及到的各端，包括PC、移動端、門店、家庭的網際網路，所有邏輯呼叫的都是在中臺系統。

第二考慮的是，如果對於今天很多新的網際網路企業業務來說，可能會容易一些。但蘇寧不一樣，很多舊有的業務邏輯，而且體量很大、交易量很大，既要維持業務的增長，還要能調整架構調整，支援未來的增長，這本身是一個很困難的演變過程。技術永遠是為業務服務的，或者說技術能夠直接變成業務，這是技術團隊最值得自豪的一點。

場景舉例，多渠道庫存共享：

第四代架構:開放零售生態圈(未來)

到今天，蘇寧有1400多個系統，服務有好幾萬。從2011年左右就有一個ESB，做整合，同時在那個時候，蘇寧對所有的服務進行了管理。後來把它變成一個分散式的服務呼叫框架——RSF。一方面是服務的治理，一方面是服務的交付。

今天我關注的是，每天都會產生海量的資料，怎麼樣讓資料發揮價值，如何讓這些資料決定公司的運。營蘇寧的資訊科技要上一個臺階，那麼蘇寧的業務運營有可能是資訊決定的。比如，承諾送貨準時到達這個業務，如果利用技術、資料對它進行全流程、每一環節的監控，就可以做到每一單的管理。這個時候你會發現，有很多業務可能因為考慮其他的利益，去犧牲了使用者的一些體驗。如何讓這一點變得透明化，讓資料去做決定就很關鍵。

今天中國的電商還處在剛剛起步階段，大部分的情況是，不知道使用者的感受，如何更懂使用者、更感知使用者，都要靠後臺海量的資料。我認為，這部分是在業務應用的層級，跟技術關係不大，更多是一種思維模式，要站在使用者的角度思考。

4

技術路線

下面分享一下蘇寧在演變過程中的技術路線。

電商轉型初級階段

蘇寧進入電商之後，線下門店1600-1700家，有18萬的使用者，用的是SAP管理軟體。很多企業，在今天還處在這種水平。在電商轉型初級階段，如何很快實現網際網路的轉型，開始引入了IBM這個夥伴，最終是要實現自我掌控。一個傳統企業做轉型，我覺得一定要有決心。

IBM在蘇寧的顧問最多的時候有四百個，這為蘇寧贏得了時間。在那個時候引入IBM WCS，以EAI方式快速接入，整合蘇寧已有的資訊化體系，然後基於物理機的平臺，開始運轉。

電商轉型自建SOA體系階段

隨著業務的快速發展，當時已經很先進的軟體、平臺、技術，配上最強的機器，都撐不住了，怎麼辦？開始拆分。在這個時候，很多是關於擴充套件性、吞吐量問題的處理。另外一個問題就是物理機的運維部署難以支援。後來就是把它拆分，建設了RSF、ESB框架、監控系統，引入和評估開源軟體。到今天為止，蘇寧新建的系統都是基於開源軟體，而且都是自己掌控的。

另外，歷史遺留的很有用的套裝軟體，也要計劃遷移的。當你把系統拆分成很多服務，如果你對它不了解，那將是一個災難。另外就是對服務的管理。ESB直到今天還在使用，因為ESB有異構的系統，比如要做中間層轉換，這是ESB的作用。還有一個和這個有關的就是測試服務，服務釋出時需要持續測試和整合。

電商轉型高速成長階段

在高速成長的時候，蘇寧就是在不停做拆分：

第一，要管控、規劃，特別有一個團隊在負責這些事情。監控體系部分，包括像基礎設施的監控、Web的監控、連線的監控、服務端的監控、呼叫鏈的監控都要和管控和規劃相匹配。第二，對可靠性提出了很高的要求，還對基礎架構、基礎元件的可用性、擴充套件性提出了很高的要求。

後來引入了OpenStack，蘇寧現在所有的資源管理都在OpenStack上。蘇寧經歷過VMware、CloudStack、OpenStack階段，管理一萬多個物理機，像持續交付、持續釋出目前都執行在OpenStack上。

這是電商轉型高速成長階段的技術架構現狀：

電商轉型新階段：未來

我們也在關注Docker。關於是否引用新技術，蘇寧都是提前去研究，新技術是否能夠更好支援業務。如果現在的技術支援得很好，我們不會輕易更換它。衡量點都在於對業務的支援和匹配。這裡面最關鍵的是服務部分，大量系統的拆分，其實是一個治理的過程。系統再細，最後就是一個服務。關於系統的管控、服務的管控方面，RSF有一個服務管理的平臺，定期出報告，負責人會收到報告，對服務進行管理和治理。

5

技術管理與組織治理

管理組織有兩個部門：一個是技術管理，包括CTO辦公室和PMO辦公室，關注標準和架構的規劃，管理架構、安全、應用開發等；另一個是專案管理，包括幾個人做一個專案，專案之間的承諾、契約是什麼，有沒有按時推進，按時交付等。管控還要有系統和工具支撐。

這裡隱含了一個規則：沒有資料支撐的不做管控。當系統出資料的時候，開始管控。

這裡也在平衡規劃管理和服務的關係，怎麼把管理組織做成一個服務型組織，支援業務的發展。系統和工具是技術平臺的部分。另外，所有和業務、應用沒有關係的部分是技術平臺，它需要支援各研發中心的發展，是不是能讓別人做的更快、更穩定、更安全，是不是讓別人不要去關注底層的技術細節。上面的兩個組織是很小的，但發揮的作用非常大。其餘大部分的組織是屬於業務應用研發。

管理很重要的一點是，要看公司人的情況，技術的成熟度、能力成熟度。管理需要拿捏是業務人員驅動，還是產品人員驅動，還是開發工程師驅動。如果一個團隊能力很強，為什麼不能讓產品驅動，不能讓開發人員驅動，去決定業務怎麼做呢？

6

我的心得分享

第一，規劃和敏捷要並重。敏捷和規劃不是衝突的，應該要完美契合在一起。尤其做技術管理的，一定要時刻拿捏度，管控規劃要做多大，敏捷多少要放開。

第二，人的觀念轉變最重要。業務產品技術的劃分，最關鍵的還是要找到正確的人，一個好用的人抵過不好用的人10倍。

第三，要激發團隊的主觀能動性。規劃往往會抑制團隊的主動能動性，但敏捷容易製造混亂。很多人離職不是因為薪資，可能是因為成長的空間不夠大，做的工作看不到價值。怎麼讓一個人可以擁有十年的工作經驗，而不是隻有一年的工作經驗使用了十年，這是管理者或者技術管理者不停要思考的問題，管理者需要和團隊一起成長。