记录业务中台建设——启动01

1.背景

        业务中台这个概念在阿里巴巴掀起之后，在国内软件领域是比较火热的，很多公司追寻阿里的脚步开始了业务中台建设，业务中台建设是为了解决传统系统“孤岛，烟囱式”建设模式下导致的问题，比如：功能重复建设、业务创新能力不足（没有业务中台支撑，每建立一个业务需要业务、前端、后端配合，协调工作多，建设周期长等问题）、系统稳定性问题（没有建设业务中台，系统的运维都是单独的，没有对数据、服务和能力进行统一管理，存在着稳定性风险）、数据孤岛（没有业务中台，各个系统单独管控自己的数据，数据不统一不规范）问题

        2015年，阿里巴巴全面启动了中台战略，旨在构建一个符合DT时代的创新灵活的大中台、小前台的组织机制和业务机制。阿里巴巴的中台战略受到了Supercell等公司的启发，这些公司通过强大的中台支持多个小团队快速、敏捷地推出高质量的产品。阿里巴巴的中台战略旨在解决电商业务中存在的重复建设和资源浪费问题，通过整合重复的组织和系统，提高了业务效率和创新能力‌。

2.建设之初，存在的问题

        前面我们说到了业务中台需要解决的问题，但是建设业务中台不同于一般传统软件系统的建设。业务中台的建设之初，第一、用户和业务是不明确的，不同于传统软件建设项目，有明确的业务功能需求，其实业务中台反而比较难找到明确的业务功能需求；第二、对中台理解不一致，并且在于不同厂商交流过程中，其实也存在对中台不同的理解；第三、对中台实现技术框架没有统一的标准，交流过程中，我们发现不同的厂商对于业务中台的实现，其实也会有不同的技术底层实现逻辑。

3.启动过程中的心得

        3.1.抛出问题，针对目前企业现状，我们需在业务中台的建设思路上不断探索，在于厂商交流过程中，发现了缺失业务场景的问题，是否建立多中台，是先建底座还是建业务的的同时建立中台的不同观点。这些无法决策的问题，需整理不同的方案陈述利弊，让决策者进行拍板。

        3.2.业务中台技术选型，作为业务企业，技术选型应该保持独立性，不与上层应用，以及下层支撑平台（云平台）进行绑定，这样技术选型可进可退，不能建立业务中台而替换基础平台，因小失大

        3.3.团队以及人员能力建设，业务中台属于前期先搭建框架，重点在后期业务规划（设计大于开发），比如业务颗粒度划分等，这些都靠人员能力提升，这需要一个长期的咨询指导的服务

        3.4.中台管理规范，一方面，业界中台建设失败大都因为，要么业务划分不合理，或大了或小了，根本无法满足业务的重复使用的需要，导致类似服务（如：80%相同，20%差异）重复建设。另一方面，未建立规范和标准，以及规范标准未落地，导致已建立的服务未被使用，而重建了一个新服务等诸多的问题。

4.小结一下启动过程

        业务中台建设是一个漫长的过程，属于业务治理范畴，一般常发生在企业发展了一定阶段，已建成多个系统，发现其中的孤岛问题无法有效的打通，从而萌生建立业务中台的想法。另一类处于前期较早规划，系统建立的时候经过充分抽象，形成公共服务这一类的企业，他们平移到业务中台更加的丝滑。