中台是否能解決所有问题

中台能解决一些问题，可是中台能解决一切问题吗?很显然不行能，中台也只在小范畴内合用前面一直在说中台是为理解决效力问题，可是效力晋升还离不开一个因素:本钱对互联网营业来讲，仅从开发效力角度来看，当规模还没大到必然水日常平凡，可以简略地经由过程添加投人晋升开发效力。滴滴，从最先的出租车营业到专车、快车、代驾租车风车，每一个营业线零碎根本都自力，虽然这些营业的重合度十分高，可是为了能疾速开发，把它们分隔反而效力会更高。

不外，跟着营业愈来愈庞大，庞大度愈来愈高，再如许发展下去，不管从本钱(挥霍会比力大)仍是手艺(倒霉于手艺积淀)来看，都是倒霉的、因而在如许的场景下十分适合运用中台。那末中台适合甚么场景呢?最典型的场景就是公司多个营业线营业场景相似、在手艺实现上十分雷同，像电商和出行这类营业。

那末，即便是在十分适合运用中台的场景下、是否一用上中台就一切都万事大吉了呢?很显然也不是。就拿前面提到的买卖场景来讲，咱们对买卖场景做了不少的笼统，进而根据笼统的后果建模，试图在必然确实定场景下灵活化处置，使建模后的后果更灵活，可是建模的条件依然是针对特定场景的，以是这类场景的运用依然会受限。

比方当前在初版买卖零碎重构后，o20形式泛起了，此前重构的形式就很难在原本的买卖模子上精良运行了。

总结

普通一个营业零碎会阅历单零碎、散布式零碎、商品化、平台化以及终极中台化的发展历程。差别阶段的区分以下。

(1)单零碎，就是单个零碎，营业形态比力单一，一切营业逻辑在一个零碎中实现、对应的开发协作普通在10个人左右。这类结构普通是在营业发展早期为了应答疾速开发发生的，不消太多思索不变性和扩展性，独一的刚性请求就是疾速实现需求。

(2)散布式零碎，当开发职员到达100人左右时，就必需拆分零碎了，根据营业单位进行脚色划分，要思索好不变性和扩展性，由于此时他人能够会依赖你的服务。

(3)商品化，就是更多地把零碎当做一个商品来提供。当客户运用商品时要思索他的进修本钱、要思索是否能够定做客户的需求、对用户的问题反应是否能实时相应(售后服务)以及商品是否不变靠得住…这些都需求由商品的提供者来保障，也就是要尽可能包管商品的标准化、规范化和靠得住性。

(4)平台化，就是在商品化根蒂根基上，你不只但愿更多的人运用你的商品，并且还愿意邀宴客户、搭档一块儿建设和完善零碎，给他们提供一整套的服务；你也不只仅知足固定的需求，还会积极替客户着想，挖掘他的潜在需求。平台化比力适合团队

(5)中台。实在咱们大部分的营业场景中只有做到营业的网站建设平台化就很好了，在营业鸿沟比力明晰的情况下，只有把根蒂根基的营业平台建设好，就能够十分疾速地组装新营业零碎。可是当团队到达上万人规模时，信息获取本钱高、互联互通本钱高、服务威力不确定……这会带来十分高的协调本钱，当协调本钱到达必然水日常平凡就不会再有协同了一每一个零碎城市倾向于本身实现需求而不是依赖他人一这就会招致每一个营业要造成本身的闭环并发生不少的反复建设，成为恶性轮回。中台就是用来冲破恶性轮回，建立便于协同的营业标准和机制的。