点击上方“程序猿技术大咖”，关注并选择“设为星标”

回复“加群”获取入群讨论资格！

企业架构目前还是个小圈子，尽管圈子中大企业不少。虽然小，但是很热闹，如同任何一个技术领域一样，为了加深理解而进行各种各样的 PK。2021 年不过一个月，从中台、数字化到低代码，像翻书一样的翻脸。好在技术圈的“瓜”成熟度一般都不高，不至于炸裂。最近在忙着适应新工作，也在忙着写各类规制化的文章，随心所欲的一直没怎么写，今天对着关于“中台”的争论小感慨下。

一、认知曲线饶过谁？

对方法论的争论不仅是方法论自身的需要，也是人的认知过程的局限，比如，我们经常聊的“Gartner 曲线”，它还有另外一个名字——邓宁-克鲁格效应曲线，就是反映人的认知过程的，长成“Gartner 曲线”那样，应该算是该曲线的变体。

该曲线可以演绎为下图：

新方法出来的时候，一般会有些“光环”，比如“中台”，阿里巴巴做成了，我出来告诉你我做成了，你信不信？当然信啊，人证物证俱在。一着急，难免觉得企业架构这破东西终于有个搞明白的了，不是“银弹”也胜似“银弹”，不服？把你家的骡子还是马拉出来溜溜啊！

不管别人家的到底是骡子还是马，反正自己家拉车的总觉得不成样子，那就把“中台”搬过来吧。结果发现，这东西不比过去任何一种企业架构更简单，不是一把手工程，不把自己家那点儿事搞明白，不花上差不多的时间，没法搞定。都差不多，还未必能吃到心心念念的流量，那不上当了，谁让我做的，先把 CTO 拉去祭天！

当然，“怒不可遏”的终归也是还会“遏”住，冷静点儿想想，大家都是在解决企业内部的 IT 系统到底该怎么做合适的问题，搞来搞去，手段无非“分”、“合”，“分久必合，合久必分”，想想，这逻辑从古人总结出来开始就管用，古人很聪明。“分”与“合”的依据，最终还是业务上的偏好、技术上的实现与成本的可覆盖之间的平衡。乐意付治理空气的成本，就喜欢修烟囱，一般情况下，别人管不到，只有国家“绿水青山就是金山银山”的政策才能管用。

所以，阿里到底拆不拆“中台”，是它自己的事情，业务上急，成本可覆盖，重复了就重复了，以后要削减维护成本了，再合，或者业务不重要了，系统直接扔，数据回收，就当做了一个“笨重”的扩容，谁说聪明人就不会用“笨”招，不是常说“比特币”就是聪明的“笨”吗？

冷静冷静都能走上“开悟之坡”，只要你还记得到底做系统是为了什么就行。不是很多企业也都做成了“中台”吗？只要知道“中台”是为了啥，就能做成。毕竟，从企业架构的视角看过去，企业内部的系统本来也是应该逐渐长成那个模样，对于企业架构而言，那不过是现在为数不多的几种表达方式之一，而且，在我看来，这些表达方式很可能最终是等效的，只要你真的是从企业想要的东西出发去做企业架构。

二、最终还要看“初心”

企业想要的是什么？达成目标。为了达成目标，企业要像一个整体，信息要分享，执行要更有效率，哪怕是盘散沙，也得散在一个盘子里，别满屋子都是。从这个角度出发，你只要不成天别出心裁的往屋里各个角落乱扔沙子，记得在一个盘子里放，你做出来的企业架构就不至于太离谱。而再有点儿自律精神，给差不多大小、形状的沙子聚聚堆儿，不管是叫“中台”还是叫业务组件，还是你喜欢的熊大、熊二，这盘沙子可能就端得上台面了。不喜欢了，就换个维度把沙子再聚聚堆儿，或者大堆儿拆小堆儿，你可能就从一个架构搞到另一个去了。

当然，认真做企业架构比在盘子里搞沙子要复杂和严谨的多，都是付出了很大辛苦且怀揣梦想的，所以即便不赞成，也不至于把“中台”推到反创新、反人性的程度，“中台”自己还没搞到哲学高度呢，这么做属实拔苗助长了。而且，不能把执行的问题等同于方法本身的问题，“军令如山倒”，但是执行的时候也不是一点儿灵活性没有，军事计划从执行开始就在随时修正，这才不至于出问题。僵硬地执行计划，不按照战场环境调整，那不是把失败的责任向计划身上推吗？打仗要做军事计划这个方法没错，《孙子兵法》也极力赞成各种算计，错的是执行时的态度。

做“中台”不算错，错的是做的时候眼里只有“中台”，就像做企业架构也没错，大小企业都可以做，错的是做的时候眼里只有“架构”而没有“企业”。麻雀虽小，五脏俱全，但它确实装不不下一颗“牛心”，“心”太“牛”了也不行，只要切合实际，就是好“心”。

人的认知确实是一个很神奇的东西，它的过程谁也摆脱不掉。为了提升认知速度，人们总是打各种比方，比如我上边讲的这些，但是每种比方都有局限，都难以完整说明事物，甚至容易导致误解。“中台”有没有一点这个呢？可能也有吧，比如，这个“中”和这个“台”不都谈了好久，放在哪里是“中”？这个“台”是“平台”吗？此外，各种文章里常有的大陆军、无人机、海豹小队、航空母舰等等，如果想搞懂这些比方，我觉得，只有深入到理论本身，比如，把这 30 年的企业架构理论至少浏览一遍，不然，这些比方中的任何一个都会给你带到某个沟里去。

另外，至少有过一个深入点儿的实践，再去理解这些东西，不然，有点像是听相声，一阵情绪的波动之后，如果不是想当段子手，估计未必记得住多少。

三、小问题，大缺陷

“中台”也确实有个小问题，但这个小问题真的是个大缺陷，就是方法论上欠缺严谨性，所以，骂它很容易，“中台”几乎不设防；帮它就不太容易，因为找不着关键点，“能力复用”这个点是“通货”，基本上每个敢出来溜的方法论都有这个本事，这顶多算“马步”不算“铁布衫”。

对方法论研究和锻造欠缺一点儿发自内心的关注，对于很多做实现的人来讲，会觉得是个小问题，毕竟，在技术圈里牛的是“一言不合就晒代码”，虽然现在到企业层面开始晒架构了，但是晒方法论的还是少，大家晒的严格来说是“结果”，这些“结果”有可能是在我家“牛”，到你家未必好用，想用的话，要不把你“家”照我“家”改改吧。

其实经过这两年的跌宕起伏，大家也都明白了，好“中台”不是别人家的“中台”，是用别人家的思路、经验建起来的自己家的“中台”，最有帮助的就是这个思路、经验，而系统阐述、提炼思路和经验的，就是方法论，实践做的好的企业，再辛苦辛苦，把方法论也好好做做吧，这样才好普惠天下。

作者简介：

付晓岩，IBM 副合伙人，全球企业咨询服务部大中华区金融核心锐变团队业务发展和交付总监，机械工业出版社《银行数字化转型》和《企业级业务架构设计：方法论与实践》作者。

感谢您的阅读，也欢迎您发表关于这篇文章的任何建议，关注我，技术不迷茫！

• JDK1.8新特性(四)：函数式接口

• 中台 | 什么到底是中台？

• MySQL性能优化(七)：MySQL执行计划，真的很重要，来一起学习吧

• 微服务架构下的核心话题 (三)：微服务架构的技术选型

• Kubernetes Pod篇：带你轻松玩转Pod

喜欢就点个"在看"呗，留言、转发朋友圈