定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来：中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。
我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略目标”、“中台就是一个革命性的设计”，似乎不做中台就成了反革命一样，就是落后生产力的代表。
其实中台本质上是一个对业务能力的抽象和共享的过程，一直存在，也谈不上革命。甚至业务中台这个概念也没有那么新：Oracle Fusion Middleware 早在 2006 年就发布了， 覆盖了包括企业智能、团队协作、内容等多个领域。
我想特别强调中台和前台的定义差别。前台服务单个业务，目标是就是这个业务的增长；前台必须紧贴业务做好差异化；前台的定位要考虑到竞争环境、目标客群、业务成长阶段、运营人员能力、人才供给、监管环境等因素；前台要有自己的技术内容、定制流程、流程对接和个性化数据应用。中台服务整个集团，目标往往是降低成本、加强管控，或者是扩大规模优势；中台的定位在以集团利益最大化的前提下最大化服务前台业务的需求；中台有自己的技术实现、研发流程和数据标准。而后台是不具备任何业务语义的基础计算能力。下图就是对这种定位的一个示意：
不论是甲骨文还是后来的阿里， 其实本质动因是一个大公司内部的大业务呈军阀割据现象，导致多条业务线重复造轮子。由此而衍生出其他的问题， 比如说团队之间内耗严重；小业务无资源， 增长乏力；整个公司数字资产不统一， 损失机会成本；业务线也不能对核心系统做打磨，业务线不稳定。因为这些原因， 所以阿里的高管们就以美国海军陆战队和 Supercell 的组织形式为启发， 做了“大 (业务) 中台， 小 (业务) 前台”的策略
那么中台是否是这些问题的完美解决方案？中台是不是万能药？我们已经知道答案是否定了。现在看来中台的解决方案至少有以下几个缺陷：
-
对创新的遏制：一个被完全中台化的业务导致集团内部过分分工， 任何前台业务都被认为是中台能力的线性组合。举个例子， 有的公司会有接近或超过千人的供应链中台、搜索广告中台、内容中台等等， 而多数业务前台少则几个人，多不过几十人。前台团队任何一个人哪怕是全职和一个中台域对接， 也无法理解该域的全貌或者跟上这个中台的演变。这意味着前台业务完全无法在这些中台相关的领域做创新。本来的创新业务变成无从创新， 当初的动力变成了中台最大的诅咒。有说法说，一个业务靠拖拉拽就能编排出来了， 这不是创新是什么？事实证明这种创新完全无用。没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式。真正的创新不是现有能力的线性组合。
-
反人性：中台自身的场景往往缺乏前瞻设计 ，是对现有场景的抽象。而当某个创新在一个前线业务线孵化出来之后，中台团队会通过强制收编该能力来扩大自己的能力， 同时强迫前台团队下线一个他们研发了很久的创新。这种行为往往造成精英人才的流失， 使得本来就受到遏制的前台创新变得更为匮乏。
-
过度设计：中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业和强监管环境下的需求被带入到了创新业务中。在带来大量运营复杂性的同时增加了用户（买家、卖家、本地运营）的学习难度。这就是我们常讲的膨胀软件（Bloatware）：巨大、复杂、缓慢、低效。
-
丧失对客户心智的追求：中台团队的产品和研发的核心技能在于抽象和降本。前台业务的核心能力在于对商业机会的捕捉和新商业机会的创造。这是两种完全不同的技能，往往对应着完全不同类型的人才。一个长期在多个业务中间找共性来降本的人是不会专注在最大化前台业务增长的
中台不是万能的， 它仅仅合适在高确定性和高通用性场景下创造增量价值
从一个团队或者是 BU 角度来看，小 BU 期望通过中台带来业务增长，但事实上大 BU 的需求总是优先， 会占用几乎所有的中台资源。小 BU 的需求永远排在第二位，会饿死在等待的途中
另外中台靠合理的设计创造价值， 我们期望中台的设计是最优的， 但是真正有能力的架构师不一定在你所依赖的中台团队。你接触的中台边界不一定合理。如果中台很复杂， 跨团队的沟通也会变得更艰难。中台创造的增量价值就越小了
