写中台的内容，其一是看到有关于中台的文章，其二是现实版本的失败，其三是想记录下来。
业务中台
概念
将业务模块提取成可公用组件，将同类组件捆绑到一起，形成一个大业务组件，并以服务的方式向外部系统输出。
这样，既减轻了开发相同业务的压力，又减少了后期需要维护的模块数量。
毋庸置疑，这是一个好办法。据说淘宝就是基于中台的架构，快速对外扩张。
飞跃
2016年，依靠阿里大量的产品技术输出，飞跃式的从原本的单机客户端演变成集群服务化。
将散落在各地的离线客户端数据，提升到集团部门可实时查看的在线系统。
也曾多次现身在“新零售专场”的优秀案例之中。
历经3年的架构变革。虽然带来了飞跃，但用户还有很高的期望。
现状
以销售业务驱动的传统行业，最开心的是压中了爆款，降低了积压库存的风险。
但是，市场风向是多变的。想要不断的创新、试错，就会不断的提出需求，从已有需求的部分变更、到老需求与新需求的如何共存。
随着市场竞品间的激烈碰撞，业务需求变更的情况会越来越严峻。也就是不仅多，而且要求快。
苍白
大量业务组件集合体的业务中台，在数量多且要求快的需求单面前，已经慢慢脸上苍白。
业务间耦合严重，改一发而动全身。
测试要求复杂，全功能测试慢慢变成一种奢望，越发膨胀的中台已经无法一天全部测试通过。
上线周期漫长，更甚至于造成数次宕机。
改变
最终必然需要改变，要以更好的服务用户为目标。
也就是，业务中台拆解成了，保障业务更加稳定的可离线客户端。
数据中台
如果业务中台是因为扛不住变化，最后崩溃。
那么，数据中台就非常的稳定。
因为，数据存在了，就不会产生新的变化。
一些想法
最后，既然“新零售”还在继续，
那么，这个需要不断创新、试错的角斗场，还在等待最终的王者。