【数字化转型】| 作者 / Edison Zhou
这是EdisonTalk的第313篇学习总结
最近在阅读钟华老师的新作《数字化转型的道与术》，记录和总结了一些学习笔记和感想，整理成文分享与你，本文为下半部分，希望能对也在参与数字化转型的各位童鞋有一点点帮助！
1中台架构的建设思路
业务中台的架构和落地形态
业务中台建设的目标是：实现企业业务数据的实时、统一和在线。下图是一个典型的业务中台：
在落地的时候，需要保持各个服务中心的业务扩展性，这就需要：
代码和数据库完全隔离
仅提供该业务领域的公共能力
仅以服务方式对外提供服务
支持服务中心的独立运营
业务中台和数据中台相辅相成
业务中台和数据中台相辅相成，需要共同构建起企业数据的运营闭环。
例如，想要查看过去一段时间各个地区或者店铺的商品销售情况并生成相应报表，这就需要对交易中心的订单数据和商品中心的商品数据进行组合，如果订单和商品的数量都是百万级，这时进行实时的查询和组合就会出现性能问题。合理的方式是将生成报表的相关服务中心以及前台业务应用的数据同步到统一的数据仓库，再由数据仓库提供的计算和访问接口满足这一类场景的要求。
近年来炙热的大数据已经让各大企业都认识到了大数据的重要性，但是大数据不只是更快的计算能力，一定要让数据作用于实际的业务中，让数据在业务交易和场景中发挥出智能决策、以数据为驱动、优化业务等能力，才能真正为企业创造价值和效益。
中台建设的方式和发展路径
目前企业中台建设的典型方式有三种：
（1）顾旧立新：即最大限度地保护原有IT系统的投资，也不断建设基于中台架构的新系统。缺点是需要让旧系统停止业务需求响应，如果系统切割器较长就会造成较大影响。
（2）平滑迁移：即原有系统中并不需要将所有的功能模块都进行中台架构的改造，而只需要将部分功能接入中台体系中。缺点是这种方式要求企业必须具有强大的技术团队对该迁移系统具备源码级的改造和把控能力。
（3）不破不立：即逐步批量化废除原有系统，重新构建新系统，在开始之初就明确了对哪些旧系统进行替换和改造，并且是在几乎同一时间段内对这些系统进行重构。缺点是项目投入成本高昂，而且对也无需求梳理、项目协同协作和管控等方面提出了较高的要求。
对我在X公司的经历而言，我们采用的不破不立的思想进行着顾旧立新的进程，在核心业务上采取了新建系统的方式，对支撑后台业务采取了继续使用原有IT系统的方式，但以维护为主少量新需求优化。
目前企业中台建设的大体路径可以分为四个阶段，分别是：初期（局部业务领域）、完善发展期（全业务链路）、数据算法驱动业务期（沉淀数据和算法能力）、数字赋能构建生态期（能力对外开放）。
中台建设的风险和挑战
钟华老师说道，一般企业中台建设面临的风险和挑战包括以下几个：
（1）企业高层领导的支持
（2）明确数字化阶段建设的核心和重点
（3）组织共识和合理机制
（4）专业人才的参与
（5）成熟稳定的架构和技术平台
基于中台架构的新业务建设原则
针对企业新建系统类型和建设条件的不同，有以下几种建设模式：
（1）自有技术团队+软件外包人员联合开发模式
（2）引入专业解决方案提供商，遵循中台架构建设
（3）引入商业套件，实现中台服务能力与套件的业务对接
我在X公司时采用的是自有技术团队，然后引入阿里云成熟云服务组件，对接酷家乐等成熟第三方服务及金田豪迈等成熟设备厂商来一起构建自己的数字化平台。
中台架构与微服务的关系
微服务是支撑企业中台服务交互和管控的核心框架，是企业中台的核心技术，而企业中台不仅仅需要技术平台的有效支撑，同时也会涉及组织架构、人才、运营等一系列非技术的调整和优化。
2中台服务设计及平台化运营体系
有了建设思路，还需要落地的方法，具体就是服务中心的设计方法以及运营体系的搭建探索。
中台服务设计
中台架构建设的核心是进行中台业务模型设计，核心方法就是抽象出具有企业级共享价值的业务模型。
首先，需要判断什么样的业务可能成为业务中台的服务中心，书中提到了有四点标准可以供我们参考：
（1）功能和数据具备共享价值
（2）有价值的业务数据不断汇入和沉淀
（3）功能有不断完善和丰富的需求
（4）功能边界清晰，具有独立运营价值
其次，确定了需要建设服务中心的中台业务，就需要将其落地，书中提到了一个落地流程以供我们参考：
（1）调研与规划：从发展角度去看企业当下的业务运营情况和未来的业务规划，需要综合考虑企业自身的特性、新技术应用、新业务发展趋势等方面来做总体规划。
（2）需求分析：从业务规划的各种业务场景出发，梳理核心业务流程，边梳理业务流程边识别业务实体，两者相辅相成。
（3）中台设计：从需求分析到中台设计有两条路径（如上图所示），A是针对业务比较复杂的场景是从业务域分析开始的完整过程（流程分析、时序图分析和聚合分析最后得出方案），B是针对业务比较简单明确的场景是基于模型库或已有的方案开始迭代推演。中台设计一般分为两个阶段：业务中心分析（三个分析：流程分析→聚合分析→时序图分析）和业务中心设计（三个维度：业务模型、数据模型和服务能力）。值得一提的是，DDD（领域驱动设计）的方法论可以用于指导这个阶段的分析和设计工作。
（4）开发实现：开发团队进行详细设计和开发，并没有太多特殊之处，但是需要开发人员掌握分布式、服务化相关的一些开发原则和技术，特别是分布式事务、异步、幂等性等问题。
其次，在落地设计开发实现过程中，也需要遵守一些良好的设计原则和方法：
（1）契约先行：服务契约公开之后就需要保证良好的稳定性，不随便重构；
（2）服务功能内聚：必须将可能影响到业务正确性的逻辑在对应的服务中一起提供；
（3）服务粗粒度：综合考虑粗粒度，减少前端的远程调用此书，降低其学习成本和耦合度。
（4）消除冗余数据：使用DTO等手段避免携带当前业务场景中不需要的冗余字段；
（5）通用契约：参数和返回值必须是被广泛支持的比较简单的数据类型（比如不能有对象的循环引用，不能有某种特定开发语言才具备的高级特性）
（6）隔离变化原则：避免服务中心内部的重构或者模型变更导致前台应用也跟着变化；
（7）契约包装：可以考虑包装远程服务访问的逻辑，也称服务代理（Delegate Service）模式，由消费者端子机主导定义接口和参数类型，并将服务调用转发给真正的服务客户端，从而让服务使用者完全屏蔽服务器月。
（8）服务无状态原则：要保证服务中心的服务稳定性和可靠性，服务不应设计为“有状态型”的，即服务不应依赖服务使用者和服务生产者之间长期存在的关系。
（9）服务命名原则：优先使用业务概念而不是技术概念。
（10）服务操作设计原则：应当使用具体的业务含义而不是泛型操作对操作进行定义。
（11）重要的服务不能依赖非重要的服务：上可以依赖下，下不可依赖上，平级可依赖但需避免循环依赖，高级别不可依赖低级别。
总体来说，简单就是美，这些原则也并非全部使用，需要我们在实践过程中不断练习。
业务运营体系
在数字化商业形态中，企业不再只以物理实体作为生产资料，数据也将作为生产资料，企业也需要设计出与数字化技术相匹配的业务运营机制，才能保证数字化转型的成功。
钟华老师在书中提出了一个标准的平台级三层业务运营参考模型，包括：
（1）数字能力运营平台
（2）产品运营平台
（3）租户运营平台
如下图所示：
实际运维中，也需要保证运维权限的正规性，需要有完备的工单系统来逐级申请和授权：
能力开放平台
当企业自身的数字化能力构建到一定的水平，基于业务场景沉淀的数据具备一定的社会共享价值之后，就可以通过将内部数字能力通过API的方式对外开放吸引其他合作伙伴一起共建产业生态，其本质是通过服务能力的方式赋能外部合作伙伴，一起服务于平台上的用户。
在构建能力开放平台时，需要注意安全性（保证平台数据安全）、稳定性（提供稳定服务保障正常运行）、平台管控性（需要对平台的运行情况有把控）和提供自服务能力（帮助伙伴更好地构建他们的产品）。
3小结
《数字化转型的道与术》是一本值得在传统企业做数字化转型的技术人读一读的好书，它并不深究具体技术的使用和业务的实现，很少涉及纯技术平台和工具的内容，更多的是钟华老师分享一些他自己几年来在数字化转型及中台建设实践中新的发现和思考。作为技术人、架构师又或者企业CIO/CTO，都要有更全面、更正确的视角，才能正确理解自己所处的行业和企业的数字化转型。
最后，希望你也能读一读这本书，相信它一定可以给你带来启发和帮助！
4推荐阅读
钟华，《企业IT架构转型之道》
钟华，《数字化转型的道与术》
不变的依旧是分享！
往期推文合集：2020年上半年推文合集
如果本文有用，请给我一个“在看”????
