這幾年在新零售、私域電商以及裂變等新模式玩法上，做了很多探索，而所有模式的探索背後，都有技術的影子，都是基于 IT 技術解決方案的基礎上展開的新模式的探索。
二者的關系很難說是業務模式促進來技術平台的發展，還是技術平台引導了業務模式的發展。
是以，我更傾向于這是技術與業務雙驅引擎。
今天想跟大家探讨的就是者個話題：雲計算、新技術與業務之間的互相驅動關系。
在雲方面，我想不僅僅是電商，包含這幾年剛開始的創業公司，都有一個共同的特點：
雲，是電商天然的屬性。他們從初創開始，業務天然就長在雲上的。
也就是大部分創業公司從創業之初或者像一些傳統品牌商，啟動電商的業務的第一天就天然的寄托在雲端，我認為像天貓、京東 POP 之類的大平台，本身就是一個龐大的 SaaS 服務平台，為我們開展電商的業務提供了基礎設施：店鋪裝修、商品陣列、支付、營銷工具等等。
大家可以看到現在的品牌商基于全管道的布局，分布式的店鋪分布、客服工具、雲抓單等等，使用的都是第三方公司的雲端服務。
但目前電商我們把它看做是一種業務模式或者形态，至少在在的傳統品牌企業是這樣的，電商大約隻占市場規模的 30%-40%，而不是業務的全部，它的後半段業務需要跟公司的業務流程貫通，是以需要回歸到傳統 IT 的支撐，從雲端下來，是以變成這樣的：
數字化的 IT 支撐
（這個圖耦合多個異構系統，是種種陣痛之後的現狀）
那麼傳統企業上雲是主動的，還是被動的？
我認為這裡面經曆了三個過程：
1、第一個階段：被動。
因為要開展電商業務，電商的業務全部都是跑在雲上，不選擇就沒有辦法開展業務。
2、第二個階段：探索。
之是以會經曆探索，是因為大的公司内部有舊勢力，比如傳統的 IT 部門，主管 IT 但又不懂 IT 的管理層，他們想從雲端下來的理由很簡單：他們認為資料放在自己辦公室的機器上比在雲端安全。我接觸的絕大部分中小企業主老闆，包含醫療診所的負責人主任醫生等等大都都是這個認知。
3、第三個階段：主動。
其實最主動的大多是業務部門，業務關系到業績，有雲端工具拿來即用，軟體即服務，誰還等傳統的 IT 部分三五個月再給個初版，還到處出 bug。
當然，現在我們更多給出的解決方案是推薦：混合雲。
這樣的解決方案利用雲端的更加靈活、便捷的資源彈性能力，與業務自身所在的 IDC 機房形成一個整體。而且企業考慮相容之前已有較完整的技術體系和架構，往往也容易選擇混合雲。
推薦混合雲解決方案，其實也是市場向甲方巴巴低頭的一種政策，相信做企業服務的乙方同學都懂的。
我也堅定認為：混合雲，會是未來的主流形态。
為什麼會是這樣呢？
因為對傳統企業而言，IT 是有曆史包袱的，這種曆史包袱，不僅僅是老舊系統，也不僅僅企業之前欠下的 IT 舊債，更有一幫已經習慣于之前作業方式的 IT 從業者們。
每個人都有職業的慣性，打破自己的慣性或者叫舒适區都是已經不容易的事情。
是以，大家完全上雲是謹慎的。
上雲，他們敏感什麼？
更準确的說：是我們的上司們，我們的組織敏感什麼？
核心點：安全
其次：沒有掌握感
你看 IDC 機房機器自己都能看得到，放到雲端機器都是别人家的，自己都看不見～..～
歸納一點：心理因素。 不專業導緻的心理因素。
但随着業務的發展與探索，我們又不能不上雲，不能不采用雲端的解決方案，我們不可能什麼事情都自己做，重複造輪子。
我們無非需要解決雲如果當機，如何自救？也就是做高可用方案
1、定期的歸檔備份政策（配置項、資料庫、檔案存儲等），利用雲快照等工具
2、同城雙活、異地災備等方案（這些成本都較高）
自救的政策還是在于如何更快的采用雲自帶的災備政策和工具，更有效的采用雲彈性的計算能力。
我們總結出一點來：雲，本質是一種賦能
把底層打包成标準化的産品或服務，我們拿來即用。
封裝了各種能力，不僅是運維層面，還有技術開發和資料層面。
基于這樣的思路，我們陸續建構自己内部的雲服務：中台。
我們抽象出了：商品庫、庫存系統、供價系統、價格預擎、全量會員資料、内容庫等
抽象出共享的業務平台：商品資料庫、供價系統、統一會員庫、支付結算系統、實時動态庫存資料、管道終端等，通過共享的業務平台，驅動各部門在資料、資源、進度和标準等方面的共享與協作。
中台，本質是提供統一的能力與統一的資料。
說實在的，這一切并不是我們三五前就規劃好了，而是慢慢演化過來的。是以傳統企業喜歡搞動辄三五年 IT 規劃，形式大于内容，是不靠譜的。
數字化程序中，演化才是常态。
現在運作着的各種業務 IT 技術解決方案，都是基于雲架構的，雲架構是一步步演化過來的：
分布式+微服務
邊界清晰、低耦合、高内聚
從單一體架構平滑過渡到微服務
從單一體的服務接口梳理，而到原生微服務做兩個階段進行，而不是一步到位。
等等，我們所需要做的是聚合不同業務場景，深度分析在系統架構更新、性能優化、資料存儲等技術方向的演化過程、面臨問題、采用哪些新技術，未來的架構規劃等思考過程。
這個過程是一個埋頭幹活的過程，是團隊自我成長的過程，是無法直接跨越的過程。
這裡面有一個很大問題：
在大企業中，如何對技術體系的協同共享問題？
像一些百億級别這樣的傳統大企業，一般都不是隻有一個 IT 部門：
大家是否采用類似的技術架構、是否有規範的接口申明等等
是否是成體系的研發線的管理？
是否以公共元件的形式共享和複用代碼？
大家的 IT 供應商是否也遵循這些規範？
是否有開放的知識分享氛圍？
相信大部分的答案都是：否。都是自成體系，或者自身都是零散不成體系的。
是以技術中台的搭建非一日之功，這對想做事情的技術團隊又有更高的挑戰。
IT 是服務部門，是業務的支撐部門，即使技術驅動業務，也是在背後驅動。
我們建構了這麼多應用，業務認不認可其中的價值？
業務認不認可，是要靠實效來說話。
透明、協作，關鍵環節不掉鍊子，這既是我們的努力方向，也是鍊值技術團隊對業務的承諾。
（以上是一次在小型的分享會上分享的内容，整理出來，做個記錄）