刚来这家公司的时候，我对于中台的理解仅限博客，知乎，百度。
没有中台的时代
在传统IT企业，项目的物理结构是什么样的呢？无论项目内部的如何复杂，都可分为“前台”和“后台”这两部分。
什么是前台？
首先，这里所说的“前台”和“前端”并不是一回事。所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、物流查询、订单系统、评价中心等等。
什么是后台？
后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、钱包管理、订单管理、店铺管理、数据报表等等。后台为前台提供了一些简单的配置和数据展示。
架构图如下：
这样的架构，俗称，烟筒架构设计。
在传统的前台-后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。
这种时候，为提高开发效率，我们有必要整合出一个中间组织，为所有的项目提供一些公共资源。而这个中间组织，就是人们所说的“中台”。
阿里巴巴，现在的互联网公司，无人不晓。
他们提出
阿里的“大中台，小前台”战略
共享业务事业部，就是阿里巴巴中台（更确切说，是”业务中台“）的雏形。
中台解决什么问题
从共享服务架构图可以看出：是企业”烟囱式“系统建设带来的3大弊端：
1.重复功能建设
2.维护带来的重复投资
3.打通烟囱式系统间交互的集成和协作成本高昂、不利于业务沉淀和持续发展。
共享服务架构的建设，摆脱了”烟囱式“系统建设方式带来的一系列问题。
中台的本质
服务复用
中台的价值
降本增效，这里的本包括人力成本、时间成本。
中台的分类
1.业务中台
2.技术中台
3.数据中台
4.算法中台
业务中台-架构图
技术中台-架构图
数据中台-架构图
算法中台 - 架构图
从0到1的阶段，没有必要搭建中台。
从0到1的创业型公司，首要目的是生存下去，以最快的速度打造出产品，证明自身的市场价值。
这个时候，让项目野蛮生长才是最好的选择。如果不慌不忙地先去搭建中台，恐怕中台还没搭建好，公司早就饿死了。
从1到N的阶段，适合搭建中台。
当企业有了一定规模，产品得到了市场的认可，这时候公司的首要目的不再是活下去，而是活的更好。
这个时候，趁着项目复杂度还不是特别高，可以考虑把各项目的通用部分下沉，组建中台，以方便后续新项目的尝试和旧项目的迭代。
从N到N+1的阶段，搭建中台势在必行。
当企业已经有了很大的规模，各种产品、服务、部门错综复杂，这时候做架构调整会比较痛苦。
但是长痛不如短痛，为了项目的长期发展，还是需要尽早调整架构，实现平台化，以免日后越来越难以维护。
