在《中台之路，从平台到中台的思考与实践》系列中笔者介绍了我们对中台建设的思考与实践，最后提到了业务信息化操作系统，这是笔者认为中台最核心的产出物，本文将对此展开讨论。
背景
在与一些圈内同事的交流中，笔者常听到类似这样的疑问：
“中台到底是个什么东西？”
“中台是虚拟的还是会输出具体产品？”
“中台的各个服务有没有界面？”
“我要怎么向领导形象地汇报中台建设的成果？”
……
对于中台，不同的人有不同的定义，笔者也曾为其下过定义，但是“以中台解释中台”的方式很难让人听懂，要讲清楚中台一定要跳出中台。
笔者带中台团队多年，虽然对外都还是以“中台”为名，但在内部已逐渐“去中台化”。因为中台一词过于宽泛，无法准确地定义我们团队的愿景与使命，更无法具象化到产出与落地。
那么什么是中台，又怎么“去中台化”呢？
业务信息化操作系统（BIOS：Business Informationization OS）
中台建设的本质目的是为 更高效地赋能业务，为其提供全面、稳定、快速的需求处理能力。 其背后依托的核心是 业务 + 技术 ，是以业务导向的技术能力平台，形成业务级、技术级的能力复用。
但这一解释仍然略显晦涩，更好的解释是中台建设本质上就是做一个 面向业务信息化的操作系统 。操作系统 对应于技术平台，它意味着稳定、安全、通用，业务信息化 则表明它是直接面向上层业务应用的，是要被业务看得懂、用得到的。
这些修饰使得它与我们传统意义的操作系统及各云平台有了明确的区别，它是一个新生的事物。
笔者把它叫BIOS（Business Informationization OS），巧的是BIOS也是基本输入输出系统（Basic Input Output System）的缩写，后者是计算设备运行的基础，而前者则是未来业务信息化的基础。
上图是BIOS的模块全景，Galaxy是内部研发代号。在系统架构上有以下几层：
-
系统内核由我们常说的ABC（AIoT / BigData / Cloud）能力构成，此能力多依托于各云厂商 -
能力服务为上层应用开发提供“原料”，本质由一个个技术服务组成 -
解决方案由能力服务聚合而成，面向特定领域，提供场景导向的业务能力支撑 -
开发接口提供了接入规范及运营管理，为各服务的运行调用提供监控、事件预警、计费结算等能力 -
应用基于BIOS的能力，遵从开发接口的要求实现快速、规范的应用开发
能力服务 对应于技术研发平台，解决方案 对应于业务服务平台，开发接口 对应于生态合作平台，这三个是BIOS的核心。从中台的视角看，BIOS的这核心也就是中台， 应用 对应的就是前台。
除了系统架构分层，BIOS还有：
-
生态伙伴共建共享机制的核心，各层能力均可开放，这也是生态合作方向的重要制度保障 -
服务运营推广的核心，是保障系统持续、稳健发展的关键
通过上述介绍可知，BIOS与各云平台有着几个本质区别：
-
业务导向，主流的云平台都不碰业务，专注技术，这导致这些平台的服务无法直接用于业务生产，有些云平台也提供了行业解决方案，比如阿里的电商新零售，但这些产品过于抽象，在使用上还需要做大量的适配，云平台这一定位是出于投入产出考量，不想“陷在”某些业务点上，这也注定了这些云平台只能作为中台技术底座，但无法在业务层面有效地支撑中台建设
-
开放共享，中台建设，尤其是产业中台建设的重要使命就是“去后台化”（见笔者的《中台是为了复用？未必！浅谈产业中台建设的特点与误区》），要从厂商绑定中脱离出来，但当下各云平台服务互不兼容，切换云服务的成本很高，完全依托于云平台能力的中台只是换了个“厂商绑定”而已，而BIOS的
能力服务提供了抽象定义以兼容不同云平台的服务，并且BIOS倡导的是共建共享，是一个开放的生态
结束
业务信息化操作系统 是一个很新的概念，它是中台的核心产出物，但同时它也有着比中台更高的愿景，它在技术层面上制定标准（比如对象的存储的接口，以兼容阿里的OSS、华为的OBS等）并适配各云平台服务，以对上层调用提供厂商无关的通用协议，在业务层面上提供丰富的通用服务（比如用户权限中心、消息触达中心、规则中心、流程中心等），对领域业务做模型与流程抽象，实现一个个面向特定行业解决方案。
