52 思考实例（上）：中台既不是银弹，也不是哑弹
你好，我是郭东白。从这节课开始我们来讲讲中台。
之所以想以中台案例来结束我们整个课程，有这么三方面的原因。首先，中台这个话题很有商业和研究价值。
中台背后的需求很合理，是国内互联网公司的刚需。在未来，中台的尝试依然不会停止，因而我们需要在当前业界的思考基础之上寻求突破，才有可能创建出真正有商业价值的中台。正如前两节课讲的南极探险案例一样，中台也是一个充满争议的话题，业界流传着非常多不同的观点。这也给了我们研究他人思考路径与逻辑的一个机会。
第二，这是架构决策的绝佳案例。中台是一个有数以万计的研发者参与的大运动，是个对中国互联网影响深远的技术案例。直到今天，中台依然在不同企业中被实施。那么研究中台的本质，就对正在实施中台的团队有一定的启发。
实施中台的书籍有不少，但是对做中台这个架构决策本身，却很少有人做过深入的研究。我们这个课程是一个架构课，而这个模块又是一个关于思考力和决策的模块，所以用这个话题来结束我们这个课程的学习，是我能找到的最好的话题了。
当然，我在国内外亲历了许多中台相关的前期决策和后期实施，有很多血泪经验。所以我在中台话题上的思考，也能帮助你未来在中台相关的决策。
第三，这是介绍理性思维的最佳案例。过去两年，中台的思维经历了从巅峰到低谷的过程。在很多企业，建设中台的决策从头至尾都严重缺乏思考，甚至在中台决策上没人任何底层逻辑。
同样，在拆中台这件事情上也缺乏理性思考。建设中台就靠一句口号：“因为相信，所以看见”。在这种观点之下，似乎所有看不见皇帝衣服的人都是智障，或者更准确地说，都是有信仰障碍的人。
由于这种思维误区，中台不论在推广还是裁撤的过程中，理性思维都被压制到了极致。那么现在，我们就要用理性的思维去分析中台相关的决策，而不是也喊着口号去盲从或打倒。否则，这种没有理性的否定态度就如同那种非理性的狂热一样，同样会陷入新的非理性循环之中。
什么是中台？
围绕中台的争论非常多，但是很多争论者连中台是什么都不知道，这种争论是毫无意义的争吵。所以在我们进行讨论之前，有必要先给出中台的定义：中台是在多个前台业务之间共享的有业务语义的计算能力。
在这个定义里，前台是服务终端用户的能力。这里我们需要强调一下中台和前台在目标上的差别。前台服务于单个业务，目标就是这个业务的增长，定位则要考虑竞争环境、目标客群和监管环境等因素。
中台服务于整个集团，目标有多个，比较常见的是降低成本、加强管控、沉淀数据或放大规模优势。中台的定位是在集团利益最大化的前提下，尽量服务好多个前台业务。
另外还有一个概念是后台。与中台不同，后台是不具备任何业务语义的全集团共享的基础计算能力。如下图所示，就是对这种定位的一个示意：
和中台类似的还有一个概念叫做平台。平台的其中一种定义是指区别于自营的商业模式。另外一种是指技术平台，也就是服务于多个场景或多个租户的技术实例，比如我们上节课提到的供应商管理平台。
中台和平台一样，都是服务于多个租户。不过中台的租户，特指一个完整的独立核算的业务部门。而平台的租户可以是个人，可以是商家，也可以是一个场景。此外，中台背后不一定是一个技术实例，可能有多个分支，而平台则是一个分支。中台可以由多个平台组成，而反之却不成立。
中台的缘起
国内中台概念的流行是从阿里开始的。相关的故事在不少书籍里都有覆盖，这里就不多提及了。
中台本质上是一个对业务能力抽象和共享的过程，其实在软件行业一直存在。互联网的业务中台Oracle Fusion Middleware，早在2006年就发布了。技术中台的历史就更早了，有了企业软件也就有了中台，国外Amazon AWS被认为是比较成功的商业化的技术中台。
无论是甲骨文还是后来的阿里，做中台的动力都是大公司内部由于并购和无序发展带来的业务线大量的资源浪费和低效协同，以及由此衍生出的其他诸多问题。比如整个公司的数字资产不统一，难以借助数据产生规模效应；团队之间互相挖角，内耗严重；公司基础设施部门的需求复杂，导致服务成本过高，等等。
我们先不谈中台是否能解决这些问题。有一点是毋庸置疑的，这些动因，也正是中台想要解决的问题，既没有过时，且正在不同的公司里发生。所以从价值创造的角度来说，中台是个完全值得研究和投入的方向。
为了应对各业务已经形成的军阀割据的现象，多数企业采用的办法就是把一些分散和重复的开发工作集中起来，通过共享同一个研发团队来抽象出不同业务线之间的技术能力。也就是通过组织的统一，来最终诱导出架构的统一，而这个组织就是中台。除此之外，这个单一的组织也会带来技术栈和数据模型的最终统一，从而消除内耗。
业务中台被寄予的厚望
如果企业有了这样的中台，可以创造什么样的价值呢？我们先来归纳一下经常被大家提及的中台的价值。
首先是业务能力共享，这也是最初被认为是中台最重要的价值。
业务能力共享指的是把整个集团的能力集中建设，然后在不同的业务线中推广，避免重复建设的同时，也能放大规模效应。主要包括三种场景类型，
- 技术型业务的集中建设，比如Chatbot、直播、内容等领域，都是FaaS/SaaS商业模式的内部应用。
- 对完全可以复用的标准化商业能力的集中开发，未来以低/零研发成本加速一个新的业务上线。也就是说，一个之前只卖非标品的商家，可以利用同样的技术体系去卖电器或快销品，甚至可以卖生鲜。
- 业务层面的集中建设，由一个中央团队同时提供研发、工具和对内的服务与运营，比如安全、风控、财务、IT等。
对于第三种场景，其中最成功的案例是阿里巴巴的数据业务。在集团内部统一数据标准，最大化数据积累和复用，把一个业务线积累的数据优势推广到其他业务线中去，逐渐建设企业的数据壁垒。这些数据统称为企业的数据资产。
企业的数据资产可以通过数据应用为集团外的客户服务，最终形成以数据为商品的新商业模式，也就是我们常说的“数据业务化”。
其次，提升业务稳定性。对于技术产品差异不大的领域，可以通过集中研发运维来获取更高的业务稳定性。这样一个团队开发的底层服务能够同时服务多个业务场景，聚合所有流量，加速场景积累。同时，研发人员也可以通过更多的场景加速打磨设计。常见的共享领域包括会员、营销、交易、资金等服务。
最后，放大业务资源的规模效应。把各业务线的资源集中化，变成全集团共享的供给资源，从而放大整个集团在供给侧的规模效应。
比如说商品中台不仅包括商品库，还包括商品质量控制体系、背后的货源、相关货源的价格和市场竞争力。而商家中台，不仅包含商家的信息，还包括商家的合作意愿和对集团品牌的信任。正是因为这种信任，相比一个独立的小公司， 商家更愿意和一个大平台上新孵化的初创业务合作。到这里我们可以有一个结论，一个集团真正想跨BU复用的，是从一个大业务迁移而来的市场竞争力，而不是数据和代码。
但是，中台实际上真的可以带来这么多的价值吗？
中台被诟病的地方
2020年我在QCon上海做了一个主题演讲，提出中台主要有如下的弊病：
- 拖慢业务：中台体系反应迟缓，在各种商业竞争上频繁败北。这似乎与前面提到的第一个中台期望背道而驰。
- 遏制创新：中台化的企业普遍丧失业务创新能力，无法跟上竞争对手的步伐。
- 人才流失：中台化之后的企业，优秀人才会大量流失。
- 伤害客户：中台化之后的企业，会逐渐减少对用户体验的关注。当用户不再是企业的关注点，最终整个企业也将在竞争中丧失优势。
这是一个关于思考力提升的模块，那么我们就要思考了：我这些批评有根据吗？这是企业本身的问题，还是中台带来的问题？这些批评与中台的预期价值有什么关系呢？
应该说，上面讲的都是现象。这些现象在做中台的企业中被很多人频繁观察到了，但很多批评其实都不具备逻辑性，也就是被诟病对象和观察到的现象之间没有严谨的因果关系。你观察到的现象到底是不是中台带来的？还是中台只是和这些相关？
假使说这些企业已经出现了上面所有的问题，不得已，祭出全企业中台化这样的大招，期望一招制胜。那么中台只是没有解决企业固有的难题，而不是带来或放大了这些问题。
这时候，我们必须要深入到细节中去，才能识别因果关系。
我们先来分析一下拖慢业务这个弊病。中台会拖慢业务吗？答案是有可能的。中台本来就是一套用来服务多个前台业务的模式。如果这些前台的业务模式和定位完全相同，并且可以完美无暇地对接同一套中台，那么这些前台业务本来就应该合并成一个前台业务。
但事实上，前台业务之所以分开，往往是有各自的特殊性，这些特殊性最终会转变成个性化的产品需求，所以中台不可能抽象之后还很完美地服务好每一个前台业务。
那么一家企业中，当不同的前台业务的体量差异非常大的时候，如果用同一套中台来支持这些不同的业务，就会导致大量成熟业务和强监管环境下的需求，被带入到创新业务中。不仅会给创新业务引入大量的运营复杂性，同时还会增加用户（买家、卖家、本地运营）的学习难度。
而较小的前台业务的个性化需求却无法被顾及，不但自己的需求不被实现，同时还要配合大业务的中台升级而不断地做改动和测试。所以中台对于那些小而另类的前台业务而言，势必会拖慢它们。
再来谈谈遏制创新。事实上，中台如果不是被强制推广，其实根本谈不上遏制创新。对于一个前台业务而言，中台就是一个设计选择，我们完全可以自主创新，选择中台的一个或多个能力。这就是亚马逊采用的模式，这也是亚马逊前台团队的创新层出不穷的原因。
不过，国内个别大厂强制推行“大中台小前台”的策略。前台团队不能自建任何能力，还必须使用中台的能力来做线性组合，这种被完全中台化的业务会一下子丧失自理能力。为什么会这样呢？
大厂里有十几个中台团队，这些团队少则几百人，多则上千人。而一个业务前台少则几个人，多则不过几十人。前台团队最多只能有一个全职和一个中台域对接，既无法理解中台的全貌，也无法跟上它的演变。这意味着前台业务无法在跟中台相关的领域做创新。
接着谈人才流失。企业搭建中台不会导致前台业务的人才流失，但是在中台自身的设计缺乏前瞻性的情况下，一旦前台业务被强制接受一个次优的解决方案，前台的精英人才往往会率先离开。所以根源在于制度，不在于中台技术本身。
最后谈一下对客户心智的追求。中台和这个问题倒是有直接因果关系，而且这种因果关系符合康威定律。
企业建设一个大中台，而且这个大中台又和前台业务、前线用户完全隔开。那么这个巨大的中台组织设计的软件架构，最终将脱离前台用户。除了康威定律外，还有另外一个人才因素：中台团队的产品和研发的核心技能在于抽象和降本。前台业务的核心能力在于对用户痛点的捕捉和新商业机会的创造。
这两种完全不同的技能，往往对应着完全不同类型的人才，也对应着两种完全不同的思维方式。一个长期在多个业务中间找共性来降本的人，是不会专注于最大化满足用户特性的。
也就是说，中台会拖慢业务和伤害客户，也会因为制度问题间接导致遏制创新和人才流失。难道，中台就一无是处吗？
有些人思考问题的时候经常把自己放在了这两种极端上。事实上，中台既不是银弹，也不是哑弹。我们接下来就从不同维度去理智地、平衡地重新思考中台。
从不同维度继续剖析中台
期望的不一定是我们能得到的，被诟病的也不一定不能被容忍的。那么我们从需求角度来认真分析一下中台，至少可以问出这么几个问题：中台到底可以带来什么价值？对外部竞争力的影响是什么？对成本有什么样的冲击？对企业的长期竞争力有什么样的影响？
接下来，我们就来思考一下这几个问题。
从价值创造的角度看中台
建设中台，起初是为了遏制无序发展和低水平重复建设的业务线。很显然，建设中台可以遏制业务线的无序发展和低水平建设。但遏制业务线不是目标，帮助业务成长才是目标。那么中台能帮助业务成长吗？
是的，这样的案例比比皆是。一个大厂，在一个或多个行业有垄断性的优势，那么这种优势就可以用来孵化新的业务。
假设一个电商大厂拥有全网几乎所有消费者的画像，如果这个大厂想要孵化一个新的在线销售电影票的业务，就可以从现有的用户画像中迅速找到最合适的、可以作为启动者的人群。比如一二三线城市的宅男宅女、白领、未婚，然后针对这些人群做推送。
启动之初，大厂可以在一两个城市使用自己的营销费用来完成验证。一旦确认用户的生命周期总价值（LTV，Lifetime Value），大厂就可以在更多的城市推广。这时候，大厂可以让用户附近的影院承担部分，甚至全部的营销费用。
一旦拉新成功，用户将成长为大厂的忠实用户。大厂也可以从中获取抽佣，带来更多的周边消费，比如提醒用户使用大厂的打车服务到电影院去。而电影娱乐的消费，又为大厂带来了大量新的画像信息，继而带来更精准的推荐和购买。
这种优势，使得大厂的拉新成本远低于一个小厂的拉新成本，而LTV却远远高于一个小厂的LTV。
那么这种能力的本质是什么呢？其实就是用户行为数据的优势。同样，供给侧的优势也可以转化成这种能力。比如电商行业的直播业务，就是利用现有的供给侧优势，把孵化直播业务的巨大成本从平台转嫁给商家。
既然这种价值创造是真实存在的，为什么还会拖慢业务呢？如果你分析一下上面的案例就会发现，多数时间，一旦启动业务，迭代速度对于业务来说就是至关重要的。
于是我们刚才提到的中台拖慢业务的问题就显现出来了。所谓的业务能力共享，多数时候都是一个幻想。前面提到的只卖非标品的商家，可以利用同样的技术体系去卖电器、快销品和生鲜。事实上，这完全是一个缺乏行业知识的猜测。如果扒开这三个行业看细节，你就知道这些行业需要的技术体系、人才完全不同。
所以从价值创造这个角度上看，我们的结论是：中台对于启动一个新业务的价值很大，可以帮助一家公司利用它在用户习惯、资源供给、数据和技术的优势，以最低的成本快速启动一个新业务**。
从竞争角度看中台
那么中台到底能不能帮助到竞争呢？
中台最重要的假设就是业务能力共享，小业务靠拖拉拽就能从中台编排出来，几天就能进入一个新行业，这难道不是竞争优势吗？
这种说法根本经不起推敲。想要在一个高度竞争的行业里立足，依靠的是持续高速且创新地响应市场需求。任何一个投资人，都不会把钱投到一个可以被大公司拖拉拽出来的创业公司。
看看过去几十年的计算机领域发展史，哪个创新是从已知能力线性组合而来的？所以真正有竞争力的对手，并不怕拖拉拽出来的系统。过去几年的市场竞争已经充分证明了这一点，大厂靠拖来拽制造出来的业务，都在各自的行业竞争中败北了。
我们在法则五中强调过了，一个架构师最重要的价值就是为企业注入外部适应性。而中台，根本不能为一个小业务注入外部适应性。不但不能提供外部适应性，甚至还会伤害外部适应性。
能做中台的大公司，大多是带着十多年的历史老代码和十几个BU的需求冲突，开始第一个能力建设的。而且很多中台依然支持最早孵化中台的主流业务，所以这些陈旧的代码和需求冲突，一直存在于中台的基因里，根本不会随着时间的推移而被替代。
从竞争的角度而言，中台是个守株待兔的做事方式，甚至是个高傲自大的做事方式。多数从内心里相信中台会为小业务带来竞争力的人，是过分相信过去的成功而看见了并不存在的路径。
所以在竞争这个角度上，我们可以得出的结论是：从中台对竞争的影响来看，中台并不能创造外部适应性，也不能为前台业务在高度竞争的行业带来决定性的优势。
从成本角度看中台
那么从上面的分析而言，大厂孵化出来的小业务，最终也还是要面临残酷的行业与市场竞争。这样一来，大企业做新业务就不具备什么绝对的优势了。
首先，大企业里的人行动起来一般比较保守，愿意冒险的人比较少。其次，大企业的人力成本并不低，研发的速度也不快。所以如果所有孵化业务都要从头建设，那大厂赚取的利润就都用到商业模式的探索上了。
也就是说，从成本的视角看，大厂并不会无限制地投入到一个初创业务中去。如果你在大厂里做小业务，真正面临的问题就来了：假设业务需要你建设一个新的能力，你是选择自己建设它，还是使用公司提供的不太完美的的中台能力呢？
公司提供的中台能力在这个时候有一个巨大的优势，就是接近于零的研发和时间成本。如果你回忆一下我们模块三讲的CTO思考方式的内容，会意识到采用公司提供的统一中台，是小业务的CTO必须认真考虑的一个选择。
从这个视角而言，中台给了小业务一个以更低成本搭建系统的可能。所有小业务节省的成本最终累计起来，就是整个企业节省的总人力和总时间成本。但这是个平衡，小业务将会因为使用中台而放慢迭代速度，所以中台就是个典型的用低人力成本换高高速迭代的例子。
那么在业务尝试这个角度上，我们可以得出的结论是：中台对于大企业试水新业务的价值，就在于中台为企业降低了新业务的尝试成本。
从建设企业壁垒的角度看中台
中台还有一个被垂涎很久的价值，假设一个想象中的完美中台存在，那么这种完美的孵化器最终会变成企业的长生不老药。企业可以靠中台孵化出很多小业务，小业务又长大，反哺更多的数据和场景给中台，继而孵化出更多的小业务。子子孙孙，无穷尽也。
不过愚公就是愚公，他没有想到他家子子孙孙生存的土地具有递减的边际效益，最后还是要靠神仙来帮他移山。
中台也是一样，不论是品牌、数据，还是需求规模、供给规模，带来的规模效应不是线性拓展的，而是以边际效应递减的。一个企业的死忠用户，可能会尝试企业推出的任何一项新业务。但是对于普通用户来说只会尝试，更多的用户仅仅是为了薅羊毛。
也就是说，中台不是长生不老药。到现在为止，中台被证明的商业价值只在数据中台上，背后的技术就是主数据管理（Master Data Management，MDM）和再利用的能力。至少在《反垄断法》能够有效遏制大企业的扩张之前，这种优势带来的价值可以说是令人畏惧的。这也是为什么之前的BAT、京东和TMD有如此强悍的扩张能力。
同样是对供给侧的控制，比如阿里对商家的控制、美团对餐馆和骑手的控制，也具有非常大的价值。需求侧也一样，比如头条和腾讯。我们就不一一分析了。
但不论是需求、供给、数据的规模优势，都是有边际效应的。哪怕是全球最大的平台，也不是每个商家都应该对平台的运营要求言听计从。每个商家都有自己的定位、供给优劣势和特定的服务能力，如果一味听从平台的建议，不断尝试新的模式、服务新的人群，最后只会经不起折腾，蒙受重大损失。
同样，数据中台也有递减的边际效应。首先是高回报的场景有限。其次，数据中台建设的前提条件是数据模型的标准化和数据语义的统一，这种对数据模型统一性和稳定性的约束，代价就是业务迭代的速度。
从公司层面看，中台要降低成本，但抽象带来的增值是有天花板的。抽象的终局是个零和游戏，不过是把前台的事情交割给中台去做。没有价值创造，只有权力转移。
另外，中台要加速业务迭代，也有逐渐减少的边际收入。一个健康行业的需求永远都在进化，不存在超前的完美设计。中台在业务起初时能产生最大的价值，之后就会逐渐衰减。
所以在从企业竞争壁垒的角度看，我们的结论是：天下没有免费的午餐，中台也是一种平衡。中台仅仅在有限的场景和有限生命周期内能为企业建造竞争壁垒，但最终也要以企业的迭代速度为代价。
小结
从上面讨论的这四种不同的角度，我们可以看出来，中台其实有加速启动和压缩成本的价值，但是也有相应的代价，其中最大的代价就是业务的外部适应性，也就是在激烈竞争中胜出的可能性。
下节课我们继续来讲这个话题，看看该怎么建设中台才能让它发挥出最大的价值。
思考题
- 在得知中台这些优劣势之后，你觉得身边哪些中台建设是合理的？哪些是不合理的？为什么？
- 你有没有面临过使用公司中台还是自建的艰难选择？这个选择为什么很艰难呢？最终让你决定选中台还是自建的最重要原因是什么？
- 像中台这样需要极度理性思维的案例其实很多，但是有的时候，决策者在这种最需要理性思维的时刻，却选择放弃了它。你有过这样的经历吗？
欢迎把你的思考和想法分享在留言区，也欢迎把课程分享给你的朋友或同事，我们下节课再见！
- 欧阳绍聪 👍（4） 💬（1）
思考题很难，我说说我自己的。我负责业务架构，对下是现成基建，对上是业务抽象，一般意义上的中台，我要做的事情就是提高业务能效，主要职责是流程编排优化，也就是怎么做的问题，我自己决策依据是业务价值：效率，规模，赋能，这是主线。至于每个节点做什么，是采购，是自建，还是妥协，反而不是我关注的焦点。我自己认为中台在能效上既是成本，也是壁垒，这取决于这个流程编排是否能自主进化。借用一下老师的直播例子，泛娱乐与社交，类似，但本质还是有区别的，直播中台用在1v1 社交业态，是天然的不合脚，前期是比光脚要好得多，中后期就限制了发力，转型，重来阵痛是免不了的。
2022-07-14 - tao_entropy 👍（4） 💬（1）
中台与创新的关系，既矛盾有统一。 1.对于做改进或迭代型的创新，中台提供基座支持，以快速灵活试错与推进。 2.对于突破性或者革新型的创新，因为从本质差异大，从原有的业务复用少，中台就变得不适用。 中台的构建，对于业务视角的要求非常高，选择中台做哪些，不做哪些是非常关键的，技术实现倒是排第二的。
2022-07-12 - 阳光下的孩子 👍（2） 💬（1）
我们公司也尝试过规划做中台，但正如老师所言，当业务要快速迭代升级的时候，要去把有限的研发资源投入到这么庞大的中台建设中，真的是很难寻求到平衡点的。基本只能优先保障业务的快速迭代交付。所以对于业务成长型或转型升级期的企业，基本上是不具备做中台的条件的，很大原因在于这个阶段基本公司的组织架构都可能半年就调整一次，业务战略也不断调整转换。所以，我的判断大部分时候中台是一个伪命题，很难证真，反而很容易证伪。
2022-07-12 - Steven 👍（2） 💬（1）
文章还没读，先生的课我得用pc来读才行，不过之前对中台做了一些了解，先试着聊聊。 我的理解： 首先中台是企业级复用，相当于做出一些通用的业务组件。 业务可以重用和组装这些组件，当然有些个性化的还是需要自己做。 这样的好处： 有新的类似业务，就可以快速的搭建并跑起来。所谓大中台小前台。 缺点： 能做到渐进式创新，不支持颠覆式创新。 业务团队需要和中台团队频繁沟通，效率无法保证。尤其现有中台无法满足业务需求，需要做调整时，就更不可控了。 内部政治斗争就不提了。 数据中台 上面聊的是业务中台，关于数据中台，只提一点，我的感觉最好是企业内部人来做，不熟悉企业业务的人怎么能真正发现挖掘出企业数据的价值呢，而且是企业几乎全部的业务。 因此对于一些第三方做数据中台的公司，我一定程度上报以怀疑态度。
2022-07-12 - 罗杰 👍（1） 💬（1）
第一份工作，我被要求独立负责一款游戏后台。我需要找中台对接一些用户登录接口，结果就是几乎找了别人一周，人家都没搭理我。我就是那个被中台饿死的后台。现在想来，当时的企业文化也是真的糟心。出现事故，后端组只要发现不是自己，那就几乎要拍手叫好了。
2022-07-16 - spark 👍（4） 💬（4）
郭老师，take away~~~抄袭别人的灵魂还是皮毛，阿里是不是抄袭了别人的灵魂？，或许是因为大部分公司没有技术和创新，业务中台是唯一亮点~~~ 很长时间找不到工作，找了个临时工，打包某电商平台的订单商品，每小时22元，每天12小时。提升了对技术优势和生存优势的认知，对《数字化转型》、《产品设计》、《业务中台》、《数据中台》，《复盘方法论》的逻辑，有了亲身体验~~~ 我没有经历过中台建设，就一条业务线，只是业务拆分为聚合Web层和业务能力层，技术抽象为服务治理能力PAAS层，IAAS层~~~ 我对中台的理解是对业务模式的抽象，业务泛化和具象化的平衡，中台的目标是创新和效率的平衡~~~
2022-07-12 - 那一缕尘心 👍（2） 💬（0）
背景：本人主要从事toB方面零售领域的软件开发工作，公司拳头产品是后台的ERP，围绕ERP构建了一套业务中台，围绕中台构建相关前台应用。问题一： 认为合理的板块： 1. 用户中心、报表中心这两类。 2. 用户中心是业务足够明确和稳定；报表中心偏向技术型，从功能角度也足够明确和稳定。 3. 新行业客户使用公司产品时，这两个必备且基本无需求。（业务能力共享） 不合理的板块： 1. 商品进销存，从源头的商品资料，底层模型大差不差，但不同行业都有其特殊的属性和行为，比如标品和生鲜品；这些特性会对商品流通过程中的各个业务环节产生不同的影响。每次上线新行业领域的业务（对公司产品来说是新，业务上来说是红海），意味着996+大改，即做不到期望中业务能力的共享。 2. 从成本的角度，确实能实现快速迭代上线,但也导致产品后续维护成本变大，灵活性降低。 3. 从竞争的角度，只能说公司产品拥有了这个行业领域的基本能力，并不能在这个行业领域内带来绝对性优势；或许对公司产品来讲，最大的优势就是能力全、覆盖的行业板块多。 问题二： 面临过中台or自建的选择，最终选择了完全自建。原因如下： 1. 业务层面，它属于完全新的一项业务产品的开拓，公司已有的业务中台和它搭不上边。 2. 协作层面，我所在团队和中台团队分属不同部门，沟通协作成本大，且初期中台方面的人力也很难协调到。 最后结果，由于是新业务尝试，公司对这个新产品初期规划完全不care，也不愿意投入大量人力，选择自建对我带领的团队来说灵活性、适应性更高。最后满足了几个客户的诉求并顺利完成快速上线。N年后，公司想合并这块业务到已有的业务中台产品，由于初期在架构层面也考虑到这点，因此仅需做小部分的对接改造工作即可。
2023-05-11 - 有铭 👍（2） 💬（0）
个人认为。有两种情况下适合上中台： 1.业务发展已经相对稳定。业务模式相对固定。不再有剧烈的变化。 2.早期看到对手已经出现一个新的业务模式。而自己方的中台，在当前可以快速搭建出来。这个仅在业务早期有用，因为随着业务的发展变化。尤其是复杂度提高，中台迟早跟不上这种剧烈变化的。 反正我认为中台只适合用在相对稳定的领域。
2022-07-12 - Geek_1f23c3 👍（1） 💬（0）
目前公司在做的ToB的统一设备管控的业务，正在将管控的用户设备各种数据从分散的收集方集中到一个集中的数据接受，决策平台。 o 目前看到的好处，有了集中的数据，确实能挖掘出分散数据平台所欠缺的统一协作的场景和进一步的想象空间。 o 但是明显的代价，就是不同设备管理应用平台自身的的关于数据决策，AI驱动的业务活动的创新和实现变慢了。管理应用平台的开发人员需要花费更多的时间来与集中的数据接受，决策平台来沟通，协调数据的传输格式，这个新数据是否与已有数据兼容，以及是否能适应其他的设备管理应用平台，两个平台的开发接口对接，进度协调等。设备管理应用平台的开发人员反而没有更多的时间关注最早的业务活动本身的需求，快速实现试错等方面。
2023-12-23 - Jaising 👍（0） 💬（0）
在即将进入 2024 年的现在来看，中台依然在大大小小的招标文件上被奉为圭臬，只不过从互联网转移到了传统行业，政企数字化改革还能看到大量使用中台来营销产品的广告，也许不那么重视体验、更在意合规、安全的政企业务可能土壤相对更优质一点，整合、成本相对迭代速度、外部适应性优先级更高
2023-12-11 - 大风 👍（0） 💬（0）
对中台的评价，似乎以偏概全了。
2023-03-13 - 任国强 👍（0） 💬（0）
一下把自己的疑惑解开了
2022-09-15 - 大道至简 👍（0） 💬（1）
下面这种前台和中台的链接方式是否能更好地利用中台？ 中台用于快速拉起一种新的商业模式 前台基于中台的基础能力上，扩展出终端业务的一些能力，以便支撑业务高速创新地迭代，既利用中台的一些能力，又能快速扩展出自己的能力，支撑高速迭代
2022-09-08 - 亚林 👍（0） 💬（0）
总部政治势力的崛起
2022-09-05 - Geek_47f2f2 👍（0） 💬（0）
关于中台的几点认知 1. 中台更多是对已有能力的抽象，对未知、创新业务的新能力支撑效率低 2.业务中台发展到一定阶段，应该是去中心化的。也就是说不都是api、spi化。可以把积累出来的领域知识、服务共享出来。让其他bu通过 copy 服务image/copy代码方式重新构建一套。而不都是在中台一个地方迭代。
2022-09-01