这几年在新零售、私域电商以及裂变等新模式玩法上，做了很多探索，而所有模式的探索背后，都有技术的影子，都是基于 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 是服务部门，是业务的支撑部门，即使技术驱动业务，也是在背后驱动。
我们构建了这么多应用，业务认不认可其中的价值？
业务认不认可，是要靠实效来说话。
透明、协作，关键环节不掉链子，这既是我们的努力方向，也是链值技术团队对业务的承诺。
（以上是一次在小型的分享会上分享的内容，整理出来，做个记录）