阿里巴巴集团CEO发出内部信，宣布组织结构全面升级，建设整合阿里产品技术和数据能力的强大中台，进而形成“大中台，小前台”的组织和业务体制，使前线业务更加灵动、敏捷，迎接未来新商业环境带来的机遇和挑战。同时，让集团更多优秀的年轻人承担起更大的责任。
最早阿里巴巴的组织架构其实比较简单，都是独立的BU：支付宝、淘宝、阿里软件、B2B。每一个BU没有所谓的大中台，一部分是业务的架构师、架构团队，一部分基础的架构团队，没有中台的概念，都是为了业务服务的，平台的建设也是根据业务的需求而沉淀下来的。
当阿里巴巴的淘宝逐渐衍生出了聚划算、天猫，也就是三淘。三淘在一定程度上被拆分开了，因为各自的业务价值被定位为不同，但它们仍旧都是电商业务，后面慢慢也孵化出了飞猪等其他业务，这时候共享团队就浮现出来。这一阶段商品、交易、营销等基础设施，既要支持淘宝，也要支持天猫，还要支持聚划算，而淘宝、天猫、聚划算各自又有自己的技术团队支持发展。集团希望各个业务既能跑得快又不要重复建设，就把原来的基础平台设置为共享业务部。
共享业务部是在三淘拆分的时候独立出来的，原来的大淘宝就被拆分为四部分：基础共享业务团队、淘宝、天猫、聚划算。但这个拆分后，又产生了新的问题。第一个，中台的属性变强，使得中台支撑业务方的属性偏弱。本来两者的组织架构在一起的话，本身的协同会有一定KPI上的倾斜。也就是说本来你是淘宝团队的人，你天然就会以淘宝团队对中台的需求去支持它，一旦被拆分出来，中台就会很公平的支持三个业务。当中台开始公平的支撑三个业务的时候，三个业务也会自己招技术团队，淘宝、天猫、聚划算会有自己的业务团队，使得共享团队处于比较尴尬的地位。
其实大中台背后如果是大前端的话，大中台就毫无意义了。但是当上层业务的复杂度越来越高，他们越来越没有精力顾忌底层基础的东西时，大前端被慢慢往回收，比如商品、交易、营销等非常基础的东西会沉淀在基础平台，而上层业务的市场、导购、玩法、商家平台这一系列东西则由业务团队自己建设。
这时候技术中台的人，整个业务成就感其实不强，技术沉淀感比较强；前端的业务成就感比较强，但技术沉淀比较弱，这也导致晋升出现了问题。做业务的人，技术沉淀不够深，业务本身变动比较快，业务价值很难说清楚是技术团队带来的，还是运营和产品带来的。而底层的共享团队，好处是能有很多框架的沉淀，坏处是一旦到了高P，自身对于全局的思路比较弱，很难找到未来中台的扩展点，因为不了解需求。
今天回过来看，大中台小前端是一个比较理想化的说法。大中台小前端并不是在一个技术平台上区分谁是中台，谁是前端。技术上这么区分其实价值并不大，只会导致上面说的，前端的人没有沉淀，后端的人没有业务拓展的能力。我认为大中台小前端应该应用到业务领域或者运营领域。这就像以前大家都说淘宝的运营很强，但现在淘宝的运营基本上看不见了。这背后是业务很多沉淀的东西慢慢被产品化，一旦被产品化后，它可以通过产品化的能力大规模裁剪前端运营人员，而后端运营人员通过产品化运营，结合活动运营、市场运营的间歇性的活动，可以起到很好的促进。
所以，大中台小前端其实比较适合运营、销售和渠道，同时这些东西应该是在业务到达一定规模的时候拆分的，也就是运营、销售、渠道的规模还没有起来的时候，建中台的意义不大，反而会阻碍模式探索的进度。只有业务模式稳定了，再通过产品化的模式沉淀，放大后端的产品化能力，使得前端的销售、运营、渠道发挥最大的价值。因为销售、运营、渠道的人本身因为后端标准化的内容输出，使得前端对个人能力的需求降低，这时候中台的可扩展性会比较强。
那技术上到底需不需要大中台小前端，我觉得不需要，技术上需要的是框架上的沉淀，这些沉淀可以通过SDK、源代码或者其他方式的共享实现复用，而未必需要中台这种模式实现。中台的模式，好处是可以升级对前台的影响，可以统一的执行；坏处是它可能成为前端业务发展的瓶颈。
