记录业务中台建设——启动02（顶层规划）

1.Why

        回到最本质的问题，为什么要建立业务中台？既然我们不是跟风建立业务中台，那么就需要明确目前企业的痛点，以及是否能够通过业务中台就能顺利解决这些痛点？面对一个传统的企业（非IT公司，并未整体对企业整体信息架构规划，标准也补齐备），由于多年的软件项目建设积累，大概率会出现了如下一些比较常见的问题：

• 1、架构制约系统性能：不支持微服务弹性扩容，请求高并发处理弱，高可用性无法得到保障；
• 2、内外协作效率不高：由于是传统企业部门由多个职能科室组成，项目按照职能部门牵头，沟通协作效率极低；
• 3、数据孤岛：由于企业发展之初为争取市场，在未从企业整体角度进行规划的前提下，建设了大量的系统，导致烟囱式项目特别多，数据孤岛，数据不一致，数据分散于各处互不相通，不利于沉淀数据资产发挥数据更大的价值；
• 4、重复建设：由于各个部门对信息的诉求不同，且存在各个做各自的项目，导致如：ERP、财务、运行、综合等系统，未抽取共有功能，共有能力无法得到沉淀，存在软件系统重复造轮子的情况，这种情况即增加了成本又提高了运行风险；
• 5、难于升级：目前某些单体项目上线之后，数据库被多个其他系统使用，导致难于升级，牵一发而动全身；
• 6、技术老化：诸多系统还是采用较老的技术架构实现，无法满足公司发展的要求；
• 7、标准混乱：架构不标准、不统一，系统功能难于梳理，系统之间难以协同建设；

        企业立项业务中台项目希望通过业务中台的建设，对企业的应用服务进行治理，一方面形成公共能力，方便未来的系统的建设，另一方面，统一数据标准，打破数据孤岛，打通数据，方便后续数据价值发掘。

2.What

        我们要建设一个怎么样的业务中台呢？我认为业务中台建设是一个持续的过程，需要建设中台基座、标准和规范等内容，未来的系统建设必须严格满足这些要求。中台的建设会对现有传统的项目建设流程以及团队协作方式产生较大的影响，新的业务软件建设需求来了，不能只站在该项目需求技术上进行设计，而需要站在公司整体层面，进行设计，复用已有能力，抽离公共能力，并统一数据标准，这样一套组合拳下来，可极大的解决第一点提出的问题，以下是我对业务中台的技术底座的思考：

• 1、中台开发架构的思考：微服务，ESB，Service mesh
• 2、对业务服务建设的思考：如何设计微服务；对于业务层如何划分，如何拆分；对于已有接口的集成和替换；
• 3、整合其他能力的思考：整合AI、大数据、Devops等技术，弥补原有技术短板
• 4、多云部署：支持私有云、公有云、混合模式部署
• 5、开箱即用，高性能、高易用、高扩展；

3.How

        说到如何落地业务中台，我们不仅需要从技术上考虑，更多是从业务进行规划和设计，技术只是业务中台次要考虑的内容，业务的规划和设计才是业务中台最重要需要考虑的内容。结合传统企业目前的情况，如何才能让业务中台顺利落地，我有几点想法供大家参考：

• 第一、建设业务中台应该采用微服务，结合目前技术成熟度考虑，SpringCloud alibaba框架，在行业中即得到技术和业务论证，且生态活跃，可作为我们践行微服务的技术基石
• 第二、业务中台应具备整合AI、大数据、权限认证、泛微流程等平台的技术能力，统一对外提供更丰富的能力
• 第三、业务中台应具备诸多业内共有服务，比如：统一架构、多模态内容，低代码开发、AI驱动
• 第四、业务中台上应具备开箱即用的能力，提供：最佳开发框架（模板）、最佳开发标准、以及最佳实施案例等
• 第五、业务中台应具备多云部署，考虑目前公司私有云建设模式，通过业务中台的建设的服务，可轻松以容器化方式部署到私有云，保留公有云、混合云部署能力
• 第六、业务中台提供咨询服务，针对微服务领域模型的划分、微服务业务的拆分、以及对于已有服务或接口的替换，前期提供全面的咨询和指导，以快速带领开发团队进行微服务的转型。
• 第七、业务中台应具备全面的服务监控预警机制以及全面日志记录，方便快速进行运维排故
• 第八、针对内外协作问题（即包括线上线下的沟通，也包括文档管理等内容），用户、产品、开发、运维能够在统一平台上进行沟通协作，即提高了消息及时性，也可避免消息在传递过程中丢失

4.小结一下

        业务中台是一个“服务治理的过程”，建设业务中台，更多是提升整个团队能力的过程，与以往的项目建设模式是有巨大的区别的，业务中台的交付物结合企业特点，我觉得有主要有：规范的开发标准、开发流程，以及最佳MVP实践经验，还需要打通已有系统各个节点的流程，让软件从需求->设计->开发->上线整个流程能够通过系统实现闭环。