本文主要是介绍数字化转型系列主题：阿里“拆中台”，我们能学到些什么？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文转自：微信公众号 健荐
目录
导读
阿里都“拆中台”了，我们要不要也跟着拆？
从阿里“拆中台”，我们能看到什么？
从阿里“拆中台”，我们能学到些什么？
回到中台，那我们能做些什么呢？
导读
有好多朋友问我对于阿里“拆中台”的看法，今天正好又被问到这个问题，就随笔写写自己的看法，一起探讨。
我猜想大家问这个问题，言外之意心里无非就是以下这几个问题：
阿里都“拆中台”了，我们要不要也跟着拆？
从阿里“拆中台”，我们能看到什么？
从阿里“拆中台”，我们能学到些什么？
阿里都“拆中台”了，我们要不要也跟着拆？
这个问题最简单，我们先姑且不考虑阿里拆中台信息的准确性，就算是阿里把中台都拆了，我觉得跟我们也没什么关系。
大家行驶在不同的“海域”，有着不同的“目标”，人家扬帆还是收帆，人家冲刺还是掉头，与我何干？
我相信那些真正明确自己建中（平）台是在做什么，解决的什么问题，期望达到的目标是什么的同学和企业，也都不会太在意，因为大家有各自的目标和问题，有着不同的环境、上下文和阶段，不会因为别人的调整而调整自己，远航不是因为人家要远航，靠港也不是因为人家要靠港。
而我更关注的是从这里，我们能看到什么或是学到什么？
从阿里“拆中台”，我们能看到什么？
针对这个问题，社区里有一种大家热议的说法，就是老K提出的观点：
中台适合做“组合式创新”，没法做“颠覆式创新”。
首先我认为有道理，但我自己的理解稍微有些不一样，差异点就是我认为中台并不是“组合式创新”，业务模式复用才是业务中台的终极目标，组合只是手段和表现。
业务中台很适合一种业务模式趟通了，成功了，通过业务中台，将业务模式与具体的业务解耦和分离，然后围绕这种抽象分离的业务模式做各种的扩展，使之可以在不同客群、地域、场景的快速复制粘贴。（比如我们常说的阿里的交易业务模式和滴滴的出行业务模式都是如此）。
业务模式复用本质上也是创新（比如把实物交易的业务模型扩展后用于旅游行业），只不过不是业务模式本身的创新而已。
但同时，成也萧何败也萧何，如果说业务中台承载的终极形态是业务模式复用，但是如果用过度了，依赖了，就发现企业会惯性的永远围绕一个成熟的成功的业务模式在跑，反而不利于业务模式的创新，就像《创新者的窘境》中提到的：一个组织的潜在能力也决定了它的缺陷所在。
所以，企业到底是建中台，还是拆中台，就看企业当前目标是业务模式复用还是业务模式创新，不同的阶段和目标做不同的事情，更别说这两个目标对于一家有活力的企业，本身也是个不断交替迭代的过程。
正所谓分久必合，合久必分，分分合合就是企业演进的过程，创新沉淀再创新再沉淀。
那阿里“拆中台”，是不是就跟我们没关系，我们能从中学到些什么呢？
从阿里“拆中台”，我们能学到些什么？
阿里其实最值得我们学习的反而不是具体调整了什么，而是这个自身不断调整的过程。
据我了解，阿里光在组织层面的调整，一年就有至少两次，我们企业有几个能够做到？
其实这些互联网大厂，最值得我们学习的我觉得就两点：
一是对于市场和用户的敏感，体现在“认知力”上；
二是认知发生变化之后的快速反应，体现在“响应力”上；
“认知-响应-认知-响应……”，就形成了对于市场和用户的反馈环路，这个环路越快企业成功的几率越大。
这也能侧面体现为什么大家都在建数据中台和业务中台，因为企业寄希望于通过构建数据中台帮助其提升“认知力”，同时寄希望于通过构建业务中台帮助其提升“响应力”。
如果我们说企业的演进过程就是企业对于市场的不断“认知-响应”的过程，市场一直在变，企业要关注的是如何快速不断的“认知-响应”，而不是总试图一步做对。
前者是演进，后者是赌博。
就像人家把心思都放在了如何快速调整适应新的市场变化，什么该合什么该分，我们还在天天掙蹦纠结“到底合才是对的还是分才是对的”。
一个在过程中找答案，一个总是希望有了答案才开始过程。
差距就是这么拉开的。
回到中台，那我们能做些什么呢？
中台这么多年了大家还在不断争议，主要是方法论上还不够严谨和清晰，我们天天谈的还是围绕概念和别人家的八卦，讲Why和What太多，讲How太少。
道理讲多了大家也会听烦的（包括我这篇），好在我们团队这段时间已经在整理和构建我们做中台所使用的平台型轻量级企业架构框架的方法论，等整理完了会以白皮书的形式发布出来，跟大家共享，一起碰撞和探讨。
这篇关于数字化转型系列主题：阿里“拆中台”，我们能学到些什么？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
