大型企业中业务中台建设思考

近年来从互联网领域到传统行业竟争变得日益激烈，消费者的层次结构和个性化需求在快速发生变化，企业为了应对这种变化不得不进行业务的快速迭代，在此背景下IT行业里中台的概念逐渐火了起来，大家都在谈论或实施中台化战略，中台有什么魔力能有这样的号召力，各类企业特别是跨业态的集团化企业都希望通过中台战略解决自身问题，但是我们也看到一些企业在实施中台项目中出现了严重的问题和偏差，阿里巴巴张勇曾说过：“如果一个企业奔着中台做中台，就是死”，中台最早是由阿里提出的一种IT架构理念和方法，其实中台思想古来有之，只是在互联网时代给它赋予了新的涵意。

那么什么是中台呢？我认为日常生活中我们每天能都接触到中台的服务，中台能对资源进行向下整合，向上共享复用，前段时间同事在贝壳上买了一套商品房，服务体验非常好，贝壳将线下各类房产中介公司的房源进行了整合，形成统一的房源池，提供真实的房源、房价和小区的近期成交数据，客户只需要在贝壳一个平台找合适自己的房子，贝壳还整合了各家银行的工作人员在贝壳交易中心上班，那里每一家银行有一个办公室，客户可以自己选择在哪个银行贷款，甚至将房管局、税务局等过户手续部门都整合在贝壳交易中心，这在没有贝壳前是完全不可想像的，从中可以看出贝壳平台就是客户与房源的中台，客户与银行、房管局、税务局的中台，贝壳将买房需要的找房、网签、贷款、交税和过户的手续都放在贝壳交易中心完成，全流程实现了线上化和移动化，极大的方便了客户、房东和中介公司办理业务。

中台思想我理解就是一层层对细节的抽象，这和IT系统建设中抽象设计模式的道理一样，将软件中有共性的、可复用的部分提炼出来，快速满足多业务场景的需求和发展，企业中的业务中台将后台资源进行整合和抽象，并向前台提供简单可重用的共享服务能力，实现了后台业务资源到前台易用能力的转化，这种中台思想能不能解决企业中碰到的瓶颈呢？

我从事IT系统研发十几年，负责了多个大型信息平台的建设，也见证了国内企业IT架构十几年的发展历程，从解决一个业务问题的应用系统发展到以数据平台为基础支撑的架构，到互联网微服务和中台架构，背后总是用户的迫切需求驱动着企业响应能力的提升，技术的飞速发展对于各方都是个极大的挑战。技术层面经历了从上古时代的EJB、Servlet、Struts、Spring架构、模板技术、到现在的微服务、前后端分离、Serverless、AI技术等，我发现每一次的技术更新都是对复杂问题进一步的抽象和复用，让使用者不需要关心具体的实现方式，只需要通过简单的集成就能使用，对于将来的IT技术发展我估计也是这样的发展方向，IT技术会逐步下沉到更底层，对外输出的仅仅是傻瓜化的工具，让非专业的业务人员参与到IT建设中来，甚至是系统功能的创造者。比如我们讲的QuickBI和DataV这两个BI工具，开发人员只需要把基础数据提供出来，剩下的事都交给工具和业务人员完成，这不仅仅是技术的升级，甚至已经影响到将来全社会的分工协作界限。技术可以一次次抽象出来复用，那业务模块是不是也可以这样干？

从理论上说将业务模块抽象到合适的粒度是有可能实现的，服务铁路旅客的业务能力，能不能直接挪到航空旅客用？这就是业务中台解决的问题。但很明显由于业务和组织存在更高复杂度和差异度，所以会非常非常难。很多传统企业没有自己的研发团队，像很多国有企业IT系统基本都是依靠第三方供应商提供和服务支撑，而且大多是以传统项目制和采购产品的方式经过多年实施逐步形成的，这种方式基本以甲方出需求，乙方设计实施，甲方验收的流程建设，是由业务和职能单位发起针对自己的问题确定方案，这些单位很难主动去考虑与其它业务实体间的协同交互，这种组织架构形成了部门墙，数据和业务也是烟囱式的，相互协作困难。如果大家能在一个平台上运行，用户数据、产品数据、支付数据、订单数据进行统一处理，这样数据就可以在平台上流动起来，多业务实体间的协同服务，简化旅客出行的流程是完全可能的。对用户来说每多一个操作步骤，就会多损失一半的用户。但有一个很大的风险是组织结构的适应调整，中台项目失败很大原因就是资源得不到满足。阿里巴巴中台战略的成功也是组织中台的不断调整和完善作为保障的。

以前一个企业要建信息平台一般分为前台和后台。很多企业的后台系统在立项建设时不是为了服务于前台系统也不面向最终用户，而更多的是为了实现管理手段的电子信息化，提升企业的管理效率。这类系统一部分是当年花大价钱采购，需要每年支付大量的服务费，版本老旧变更困难；一部分自建的年久失修同样变更困难，对业务的响应慢，动不动改个小功能还要花一大笔费用，从集团公司最顶层看各成员企业几百个信息系统，很多系统都是这样，不仅仅是慢和贵，更重要的是被系统供应商给绑架了，很多系统代码的产权是谁的都说不清楚，而且几乎看不到哪个系统有扩容规划、灾备演练、降级限流等架构的实际落地和执行。

此时前台和后台就像汽车上两个转速不协调的齿轮，赛车手希望前台的四个轮胎转速越快越好，而发动机作为一台汽车的心脏它的齿轮转速则不是越高越好，它需要考虑车速、档位、油耗、温度和安全等综合指标，中台就是找到一个最合理的平衡点来保证前后的协调一致，想要快速响应前端用户的大量需求，要求能够快速创新迭代，所以前端要求转速越快越好；后台由于对应的是相对稳定的后端资源，系统变更困难越稳定越好，希望转速越慢越好。随着企业业务的不断发展，前后台架构导致齿轮不匹配的问题就逐步显现出来。后台变更越来越困难，但还要响应用户持续不断的需求，导致业务逻辑直接在前台实现，致使前台系统不断膨胀和复杂，形成了一个个烟囱式系统，业务沉淀不下来，系统交互困难，用户响应能力低下。

中台的出现将前台与后台的齿轮转速进行适配。将后台资源集成开放响应用户的需求。将前台应用中的稳定通用业务能力逐步下沉中台，提高前台的用户响应能力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力抽取到中台实现，为前台提供更强大的炮火支援。2020年新冠疫情爆发，全国驰援武汉，我们国家发挥了强大的中台整合能力，一方有难八方支援，政府从各地组织医疗资源和抗疫物资，通过疫情数据和病症情况的实时监控，不停的迭代医治方案，很快控制住了疫情的发展，体现了在中台的支持下前台快速的应变能力，一省驰援一市的方案体现了微服务化的分而治之架构，国家将抗疫的经验分享给其它国家，援助医疗物资体现了中台的共享复用，但我们从数据上了解还有很多发达国家对疫情的控制没到位，更能体现出IT中台架构的建设风险和运营的风险都比较大。

从第一次接触业务中台的概念到负责中台设计、实施、上线运行，我认为中台概念非常合理先进，从架构的角度看，对企业数字化转型和IT架构一下子清晰了很多，可以从更高的层次分析和把握整个企业的IT架构，前台业务敏捷迭代快速响应用户需求，中台业务稳固支撑。反过来前台的大量需求不断的滋养中台的成长和完善。不过在企业里真实情况真是这样吗？真正能做好、运营好业务中台的可能并不多，提出中台概念的阿里巴巴也是经过了十几年的沉淀才达到目前的阶段，能够想象到过程一定很不容易。阿里巴巴是以战略提出的中台架构，京东以组织架构中台化开始，不难想象某个集团企业要开发上线一个中台的信息系统来解决企业存在的问题，我个人认为失败的风险极大。我从技术的维度将实施业务中台的一些经验教训进行了分析和总结，后期我会尽最大化归纳整理一个高可靠、高性能、低成本、低运维的业务中台模型。提几点我对实施业务中台的建议和思考：

企业中存在很多相同或类似的业务需求，通过IT技术将这些业务功能抽象化，下沉为通用的、复用的业务能力，全面支持各业务线的快速发展，并提供业务创新的能力平台和底座，这是实施业务中台的核心价值。所以业务中台是为业务服务的，各业务中心要了解和掌握你所支撑的业务具体情况是什么样子，对业务知识和流程要有深刻的认识。

业务中台化不会有一套拿来改改就能用的方案，必须具体情况具体分析，中台化的过程不出意外一定是痛苦和艰难的。需要让企业的主要负责人知道什么是中台，信息系统中台化后组织结构的调整和业务流程重组可执行吗？企业的业务发展到了必须实施中台战略吗？

能用微服务解决就暂时用微服务技术去支撑业务的发展，如果微服务能解决还要上中台的话，我个人不太推荐。用微服务的技术支撑了业务中台的运行，我们上线了业务中台后也在逐步的调整和适应，步子迈的稍微大了一点，业务中心分的太细导致复杂的业务依赖关系和分布式事务的问题，所以也在对业务中心进行从细到粗的合并，一些镀金的功能以微服务的方式运行提供能力支撑。

中台化要用互联网思维建设，选择更容易实施的业务领域开始，而不是全面开花，如果是大型集团化企业要实现整体架构中台化，可能在市场上就没有这样一个承建商敢承接，另一方面不能抱着建信息系统的项目制实施，应通过敏捷迭代的方式每个月，甚至每周每天都能看到成果和问题，逐步迭代完善，采用小步快跑、快速试错的方式实施，如果等到上线的时候才发现问题那就比较麻烦，涉及的业务太全面，可变因素和不确定性就会很多，失败的风险相应也更大。

中台项目的实施要有自己的业务专家、IT架构师和研发团队，中台建设是个长期的工作，它需要逐步成长和完善，如果直接交给IT承建商去实施，风险有点大，我们在建设中台的时候我作为集团公司IT架构师全程参与并决策整个架构的设计，工作细到每个业务中心的数据模型和字段，每天对承建商的代码级评审，而且通过外包的方式组建了一只自己的研发团队参与到中台和业务应用的开发中，我们业务中台的验收标准是上线的那一天就是承建商撤离的时间点，也不需要承建商二期以及运维，需要完全由自己的外包研发团队承接，这个其实很容易，因为自己的外包研发团队和承建商的研发团队整个实施过程都是一起开发，分工协作，比如承建商做订单业务中心，自有外包团队做支付中心。另一方面从业务上由我们信息部门的业务经理按条线分工去现场了解、收集和分析需求，这样可以把握需求的范围和质量，因为我们的业务经理是都是从机场一线上来的，最懂业务最了解现场情况，而不是直接将需求管理交给承建商去做。

要处理好业务中台和业务应用这两层之间的关系，很多传统企业没有自己的开发团队，上层的业务应用层可能有几十个IT厂家要基于中台开发和改造。有专业化比较高的应用，还有一些应用直接使用的SAAS服务，如何在架构上处理好还真不容易，需要从多个维度来解决。我们在开发业务中台时人为的将项目团队分为两个组，一组专门做业务中心，另一组则开发新的业务应用，当业务应用基于业务中心开发完成时，那么基于业务中心开发业务应用的标准就出来的。另一方面从架构上也要适应业务应用层的多样性。

企业建设业务中台不应该完全从IT技术层面考虑，需要从技术、业务、组织和运营多个维度协同推进，而不单单是IT系统的一个维度。业务中台只是支持业务场景的手段，并将多渠道的业务能力抽象沉淀下来，业务中台的逐步成长完善也需要独立的组织进行运营，平台型组织是业务中台的重要基础也是企业转型的方向，前后台业务的拉通是平台型组织的发展大趋势，阿里中台之所以成功不仅是技术，更是敏捷的组织变革，阿里提出“大中台、小前台”的中台战略后，进行过十几次组织调整和部门合并，都是为拉通前中后台提供了基础。

中台架构的实施落地推荐从易到难逐步实施，从最简单的资源中台开始，到技术中台、数据中台->业务中台->组织中台，最终完成企业架构的中台化。这个过程是漫长的也是曲折的，我们在两年的中台建设中，碰到的问题大多与技术无关，更多出现在组织的边界划分上，我作为IT架构师更多的努力是从技术手段去解决碰到的问题，但往往在关键的节点是绕不开组织的问题。我曾经看到别人写的一段话：“组织可能不是中台建设的阻碍，而恰恰是中台建设的本质”，只有亲身经历过中台建设的人，才能正真体会出中台早已超出了技术的范畴。

设计再完美的架构在建设过程中也会有变化，因为实施各阶段面临的影响因素非常多，所以变是正常的，不变才是有问题的。大型信息系统都是从小到大一步步完善，在每个阶段都会遇到各类系统性和业务类问题，然后在不断的解决这些问题，所以架构是由业务规模驱动而逐步演进完善的，当然IT架构也不应过度设计而舍本逐末。