软件工程里的"重用"——从中台说起

前段一个关于“中台”的文章被广为传转发，有挺中台的也有 dis 中台的。有朋友说，身边确实有需求要做这个的，你怎么看，有什么思路么。这里我就整理一下，大概思路是从中台说起，然后说下软件工程里的“重用”，最后说一些企业内部开源的思路和想法。漫谈，没有什么太强的目的和意图，看的人也不用强加看法上纲上线。

套用一个路子，凡事都离不开“从哪来，是什么，到哪去”这三个根本话题，中台也不例外；但是“是什么”和“到哪去”我也不知道，也说不清楚…就是作为铺垫先说“从哪来”，毕竟这个信息是公开渠道可以获得的，即使说不清楚也可以说的八九不离十。按照广为传颂的，大概是首富去了欧洲参观，看到有些公司可以快速的开发同质的产品（有可能是软件，比如游戏），并且赚了大钱，首富颇为欣赏这个思路。不知道当时欧洲公司英语之类的怎么介绍这个，首富用自己的语言天赋和灵感给这个办法一个名字“中台”。并且叮嘱属下回去好好研究，深入践行。说个题外话，搞游戏的，还有搞网站的，批量生产游戏和站点是个标准套路，游戏和网站的产销是一个完整的产业链，这个并不神秘也不稀奇。一般搞游戏的，要么偶出爆款，要么就是一直出大路货然后靠量发财…频出爆款的，那是真实力。回到话题里，首富的这个“殷切期望”，属下深入解读之后，提出了一个可行且有意义的实践方案—合并首富旗下多条业务线通用的部分。不得不说首富手下有能人，一方面这里确实有很多地方是重复建设，包括业务也包括技术，确实需要整合；一方面这个方案实际是一个组织结构调整的好的理由。大的组织定期“重组”既是个习惯，也是个需要…时间飞快，很快这个就“落地”了，具体做了什么，有哪些收效，有哪些可度量结果，这些都不重要，重要的是这个过程被迅速的迭代成了一个“故事”。要知道，首富旗下，能讲故事是基本技能，江湖传闻“自带PR属性”，我认为这说法不是贬义，但是其他人具体怎么理解，就因人而异了。到这里，事情发生了重大的变化：“中台”变成了一个技术概念。至于怎么做到的，是作者有意升华出来的，还是读者自己“揣摩”和“升华”，无从考之。首富旗下除了有能把老板想法落地的人才，也有能讲故事的人才，但是最重要是首富手下有能挖坑的人才…所谓小坑怡情…这种“可重用”“提高生产力”的神奇事物，只有在推广到市场上，才能为首富创造更大的价值—不仅给我省钱，还得给我赚钱。首富的思路清晰明了，挖坑人心领神会—内部技术硬邦邦的真家伙，从云部门推出去给市场检验一下~云部门具有超强的执行力，毕竟执行力“不好”的都在考评环节“贡献社会人才”了。执行的结果就是：泱泱大厂是不做落地项目的—可以理解，一个是做不好容易跌份，一个是成本确实高。题外话，现在说也就是前年，某天府之国的汽车大厂找某云落地一“平台”，最后某云提出“（项目）钱我不要了，但是平台我也不做了”，被该车厂CIO痛骂…这是段子…这个大厂被坑之后，恰逢去年经济不景气汽车行业不景气，在合资车品牌里领跌…事情没有因果，都是运气。大厂自己不落地可以，但是总还是有市场需求的，此时天降奇缘：更有钱的金主出现了，要说该金主在赚钱方面真的是横扫云这种苦逼的生意…以产地为“护城河”，市值一涨再涨…中东什么黑色黄金还需要开采，这个比开采还省事…欧洲洋人的葡萄酒还分什么产地年份，这个东西要简单很多…金主要开拓“网上渠道”…不知道这种躺钱的地方，怎么还会有改进赚钱方式方法的想法…贫穷是限制我想象力的…不过客观上看起来，一个是这种东西不需要网上渠道，一个是网上渠道一定会和既有的分销体系在利益上有冲突，一个是真的需要网上营销也可以用既有方案，再不济，随手就收购一个酒类电商平台，应该是绰绰有余…所谓“坑不单行”…最后也是闹得沸沸扬扬…以至于很多人都开始怀疑“中台”了。为了挽回声誉，神秘补刀手出场，迅速给这个事情定了个性：中台不是谁做都可以的，涉及到组织调整，是一把手工程。这个说法类似“衣服好不好看，也分谁穿”，属于高级黑…不仅搞这个事的人级别不够，而且你组织结构也不够“先进”…不是车不行，是开车的人不行，是路不行。自古挖坑不留名，要命还看神补刀。跑题了…

回到话题本身，还是有不少人提想要建设中台的，我们来探讨下这其中的原委。先说一部分结论：对中台有期望的本质都是在寻求某种“重用”；然后本文结尾，再把这个结论补齐。

提到重用，我们把话题转到20世纪最伟大的发明，计算机。到目前为止，我们用的计算机体系主体还是诺伊曼体系，在这个体系内，对于一个程序，在给定的输入情况下，输出是确定的。人们也在尝试用这个体系去解决“不确定输入下”如何获取“尽可能确定”的输出，或者说“多大程度的确定性”，这个主要是因为输入的不确定性，并非诺伊曼计算体系的原因。在这个大的技术背景和前提下，配合了一些类似“do not repeat yourself”之类的指导思想，计算机工程里呈现了一个有趣的特征：机器尽可能的做重复的事情，但是计算机相关人员在极力的避免“重复劳动”。为了避免重复劳动，计算机领域人员在过去70多年时间(从1946年开始计算)里先后实践和找到了很多达成共识的“避免重复劳动”，也就是“重用”的方法：

1. 拷贝、粘贴、复制。这些最基本的重用，其实每天都主导着大多数计算机领域工作人员的工作…
2. 程序，或者称为可执行程序
3. 类库。这个可能是被大家最熟悉的重用方式，封装起来被反复调用
4. 框架。框架很大程度是面向编程人员的。计算机领域工作人员其中一部分是程序员，程序员通过框架可以提高开发速度和质量
5. 中间件。IBM在90年代，针对应用开发过程中通用功能，提出了中间件的概念，也就是以独立软件方式提供重复能力。这个领域先后诞生了那个时期领先的行业巨头
6. 服务。相比于以上的几种，服务是一个跨越。因为服务这个词汇的抽象性，我们这里把服务约束到“REST”，以方便后续的讨论。最具有标志性，也是被最多人熟知的，是另外一个首富，在2000年后提出来的。当时以贝索斯为领导的亚马逊团队，发现内部团队之间在实现功能时候会采用不同的工具和方式，这导致了“合作”的难度大大增加，而如果过度的约束团队的工具和方式，又有副作用（比如学习成本，比如创新被压制）。这个背景下，亚马逊开始倡导“注意接口重用，具体实现各自为政”的工作指导思想。而这里的“接口”和“实现”，就是REST API和“服务”。这个“基于接口重用的服务体系”后来衍生出了“云计算”这种影响深远的东西…当然，这个思路并非只有亚马逊有，只是亚马逊比较早的明确提出这个论调。题外话一下，亚马逊也是个强调“讲故事”的地方…东西方首富在这里有了异曲同工的地方…
7. 平台。实际上平台并不是计算机领域重用的方法，这里列出来主要是为了枚举我们常用的“重用”的方式和方法

在列举了常见的重用方法之后，我们简单把他们分下类，在计算机领域为了“重用”我们有这么几个类别：

1. 劳动重复。拷贝粘贴就是重复劳动的典型，重复劳动，产生出“重用”的工作产物
2. 代码重用与“模式重用”。如果我们可以有效统计和分析代码，会知道很多很多源码里，其实很大程度上，是重复的…这个部分在抽象一次以后，就是常见的“编程模式”
3. 组件重用。框架和类库都是这个分类里的
4. 工程重用。一个已经落地的项目，需要建设另外一个类似的项目，这时候很多部分是工程重用
5. 方法重用。一般一个方法被验证可行以后，可以用同样的方法去尝试解决类似问题
6. 能力重用。人们希望可以重现某种能力，为此一直孜孜不倦的在努力…云计算是这个分类的典型
7. 思想重用。这个部分我是真的不懂，实在是编不下去了…但是我承认有可重用的“思想”存在，并且很佩服这类

虽然大家如此追求“重用”，但是重用并不简单，主要有这样几种原因：

1. 经过多年发展，很多需要重用的东西，都已经有了可以重用的实际东西。无论类库、还是框架、还是模式…想弄出又新又实用的“可重用”很困难。也可以这样说：面对一个确定的问题，找到可重用的方式、方法、工具的可能性，远大于找不到的可能性
2. 重用需要很高的抽象能力。虽然可能多数人都不喜欢重复自己的劳动，但是真的把自己重复的事情抽象出来，并不容易。人和人之间的抽象能力，差别是很大的。落实到计算机领域，不仅需要抽象出来，还需要能“制造”出来，难上加难
3. “可重用”还需要很多实践的检验。即使做出了重用的工具，能够经得住实践的考验也非常难。不仅仅是“稳定可靠”的重复很困难，还有易用性，普适性等很多因素
4. 应用层的东西，因为需求总是变化，因为市场总是变化，因为业务总是变化，开发出重用组件的可能性更低。应用开发领域，包括配套的工程领域，比如测试，为了兼顾重用和客户化，最后大多数都是通过重复劳动来实现

因为这些很实际的困难，从技术角度开发出来的“重用且有用”的东西越来越稀有…

回到“中台”这个话题，不少提到中台需求的人，我理解实际他们在寻找的是“贴近应用层、可重用的技术能力”。这里有两个特点，一个是贴近应用层，一个是重复的目标是“能力重用”（比如可以批量开发“套娃”产品的能力，类似中后期的诺基亚手机…）。通常有这些想法的是“业务领域技术管理类”人员，主要因为他们看到的问题是业务问题，希望通过技术重用来解决。当然了，这可能是我身边世界上最难的两个问题，我觉得原因有这么几个：

1. 业务问题本身差异很大，即使看起来类似的东西，没有分析出来的差异化也常常是超出人们想象的。即使同行业，也很少有可以直接复制的东西。因为一旦可以复制，行业竞争就会加剧，所以活下来的都是有“不可复制”能力的
2. 业务问题变化很快，即使开发出重用的东西，也可能很快就无法重用…或者说：在输入持续变化的情况下，很难构建重用的能力
3. 可重用的技术，和期望的“能力重用”，并不存在等价关系。在一个给定的团队内部，技术“重用”往往提升空间并不大；甚至说，在一个给定的环境里，包括供应商，包括技术团队本身，能重用的多数都已经是重用了（当然不排除那些故意把能重复的工作反复做来体现工作量的）。但是这种技术上的重用能力，并非可以直接输出成“能力重用”。能力重用，本身是团队的能力体现，不会因为团队用了某种特定的技术或者工具，就“能力重用”了。简单的说，没有重大技术突破情况下，技术重用并不会显著提升业务能力。这里引出了我想要表达的一个主要的观点：技术重用能改进工作效率，但是不会直接提升业务能力；而工作效率，只是业务能力的一个组成部分。

可能有人会说，你上边提到的“中台”，实际是“业务中台”；现实当中还有很多其他的“中台”，比如“数据中台”，等等。说个段子，去年在一个客户组织下，多个厂商进行了一个大讨论，就是如何建设“数据中台”，而这个话题最后又转换成了“数据中台和已有的大数据平台到底啥关系”…虽然这个客户有自己特定的情况，但是本质上，这一轮的“数据中台”就是“大数据x.0”，就是大数据的升级版。把数据相关的能力，封装成服务，本来这个东西叫“data xxx as a service”，是PaaS的一个细分种类。这些东西很早之前主流的数据处理厂商就有类似产品的全家桶，这几年用开源的数据处理相关软件重新做了一遍，再构建到PaaS上，顺风顺水的就有了新的名字“数据中台”。从另一个侧面看，这种朗朗上口的名字，是不是比以前的“数据能力即服务”更容易普及更容易被接受呢，我认为是的。实际上大多数的“xx技术中台”，本质都是这个形态，技术能力通过PaaS技术实现了平台化。这一部分，是技术充分、边界清晰，具备落地条件的，而且有一定的重用性。注意：如果一个东西具备重用条件，并且具备不错的商业价值，那么最后一定会出现该领域成功的商业公司。而且事实已经证明了，这种公司不会是clouera这样的，或者说：这个东西的最终形态不是传统的软件公司，最大可能会是云计算公司。从这个角度来说，“技术中台”就是云计算。

除了“技术中台”之外的，面向业务能力的，我们暂且叫做“业务中台”。基于如上两段的讨论，我的结论是：“业务中台”实际是不能复制的，因为业务中台目标是可重现的业务产品，如果业务中台可以复制了，那么业务产品就可以复制了，这样这个行业就会陷入无差异竞争，很快这些依赖“复制出来的业务中台”的组织就会利润降低甚至被淘汰；而没有被淘汰的组织，一定是有“差异化”的能力，也就是不可以被复制的能力；这些差异化的能力是“生长”出来的，而不是“复制”出来的。换个说法：业务中台也许是存在的，但是并不能复制别人的业务中台。这引出了本文我想阐述的另外一个观点：技术的本质是重复，商业的本质是差异化，处理好这两者关系和矛盾的组织更有竞争力。

进一步阐述这个观点。技术的重复价值毋庸置疑，提高生产率，降低生产成本。那么商业呢，商业实际有两个维度：一个是重复，一个是创新。大多数“成功赚钱”的公司，都是找到了可复制的赚钱方式的，这个时候，商业领域“重复”的能力显得格外重要。甚至说，如果不能找到“快速可复制”赚钱办法的公司，都很难“成功赚钱”。但是商业领域的竞争更为激烈，虽然有商标、知识产权、专利、等等保护，但是利益驱动下“可重复”的商业模式会被其他人快速学习和尝试复制。这个时候，商业的另外一个本质就显现了，就是创新。可以说，“伟大”的公司，都是把创新和“重复赚钱”并重的。良好的商业环境里，创新会有良好的商业回报。通过不断的创新，不断的形成有价值的差异化，来推动公司具备持续的赚钱能力。但是需要注意，持续的赚钱并非只有创新+重复这一个办法，还有更简单的办法，就是垄断；但是这里我们不讨论这个话题。

在很多时候，商业对于“复制”的诉求和对“创新”的诉求，是矛盾的。重复的这个部分，可以通过组织、流程、人员、培训、工具，等等这些手段，包括技术重复，来实现。但是一旦这些都实现了，想改变这些就会变得很难，而创新就是要改变这些。同时，这些可重复的部分，也往往是成本冗余的地方。这个估计也是首富提出“中台”一个背景：组织通过复制自己，实现了新的产能，新的产能成本并没有随着复制降低，甚至更高；但是通过“复制”方式出来的产能，很多时候是利润降低的。成本和利润这个叠加以后，就是“摊子原来越大，利润越来越低”。创新和垄断可以带来高利润，简单重复通常带来的是利润率降低。所以在首富这个特定背景下，提出“中台”，是为了降低冗余，是为了节省成本，是为了解决“摊子越来越大”的问题。本质上并没有创新，如果非要说创新，算是“管理创新”吧…但不是技术创新。这里引出我要阐述的第三个观点：“中台”也许是管理创新，但是绝对不是技术创新。

在“重复”和“创新”之间，如何找到新的模式，能同时满足这两个对商业至关重要的能力呢？一个可以借鉴的思路是：内部开源。内部开源在如下三者中能够构建新的平衡和能力，这是传统模式所不具备的：

1. 构建更高质量可重用的技术，或者说“技术复制”。组织内部因为分工，往往会造成即使某个团队的某个产品技术落后，但是也不会被淘汰，内部开源可以快速的发现这些问题，甚至解决这些问题
2. 用“技术复制”支撑商业复制。商业为了避免被竞争对手“复制”，往往有很多壁垒和保护，但是这些保护往往也会称为组织内部部门之间的“壁垒”。内部开放的技术复制，有利于打破这种内部壁垒
3. 创新，用新的技术淘汰旧的技术，新的产能淘汰旧的产能。开放和创新一直是相伴相生的，有了开放的土壤，自然有创新的果实

最后总结一下这里零零散散讨论和阐述的观点：

1. 首富提到的中台，也许是一种管理创新，但并不是技术创新
2. 业务中台具备不可复制性；可以复制的业务中台往往也价值有限，会很快被淘汰。业务中台需要“长”出来，而不是“搬过来”
3. 技术中台本质是云计算，是细分技术领域的云化形态
4. 技术领域一直都是以“可以重用”为追求的，但是这些可重用的技术，并不会持续的显著的提升业务能力和竞争力
5. 内部开源，可以帮助组织构建“技术重用、商业重用、创新”三者之间的平衡的新的形态，这个新的形态更有利于组织形成持续的竞争力