从CBB谈中台的重用复用
一个新产品中采用经验证的模块、部件、平台的重用度比例。这样，重用度高的新产品隐性的技术故障因素就会低得多，产品的稳定性、竞争性就会相应提高，产品开发成本和研发周期也会相应地降低和缩短。在新产品的开发中要尽力避免随意的技术创新，没有任何继承性的随意技术创新的结果是：一轮轮地技术创新，一茬茬地排除技术故障。这就引入本文的主角CBB了。
说起来了解CBB的思想，还是10多年前在华为做软件平台时的事情了。CBB又名公共构建模块(Common Build Block)支持某个功能的组件和模块。通过CBB委员会，形成CBB的设计规范，评审，变更管理，激励，任职贡献等，构建企业级，产品线级，产品级的CBB仓库，从而逐渐提升各级的产品的复用能力。
中台现在越炒越热，岂不知现在成为这样。中台是个筐，啥都往里装。很多企业在数字化转型过程中很迷茫且焦虑，不知道怎么开展，这时候以中台作为抓手或杠杆是可以理解的，但是最终要落地，以什么形态落地呢？绝不只是将老系统用新技术，微服务重新来一遍，或者说这么做，只是一部分准备动作。那么和CBB有什么关系呢？
图源自高新技术企业集成产品开发(lPD)管理
这里面就要说说中台提到的复用上，无论是业务能力，技术平台，技术组件的复用，都可以借鉴CBB的思想，形成分层次的复用架构，真正从降低出错概率，提升需求响应速度上去扎实落地。正如罗马不是一日建成的、中台也不可能一蹴而就。想想你对中台的期望就很容易理解了。
从中台复用看“烟囱式”架构2.0
老的“烟囱式”架构，也就是每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。大多数的架构会被打包成为war包并且被部署到Apache Tomcat Web容器中， 整个结构趋于传统的单体架构，业务逻辑耦合在一个项目中--企业IT架构转型之道
于是提出了SOA、微服务甚至现在的服务网格、云原生等等技术方案。如果我们从复用的角度来看、如果不从业务层到逻辑层进行抽象、不做类似CBB的技术体系建设、只是流程式的系统。那么我认为这个系统还是孤立的，因为其没有提供可复用的能力出来、那么可能即使一个需求变动比率不大的系统，都需要较大的工作量。我把这个叫做“烟囱式”架构2.0。
因为中台的落地、核心是复用体系和能力的构建、无论是使用什么优秀的语言或者框架、如果只是模仿现实、不做共性抽取、不做业务模型，不形成基础的能力。建立的系统，仍是“烟囱系统”，虽然你可能是技术上做了系统的集成或整合。
中台复用能力的建设、首先需要有中台能力体系的负责组织、让所有的能力建设，不是单独的烟囱、而是可以组合、涌现出复杂能力的基础设施。
