《数字化转型的道与术》读书笔记



数字化转型重在转型,数字化只是手段,技术只有服务于业务才能发挥技术的价值。

数字化转型与中台架构
中台架构与绝大多数企业 在落地数字化转型过程中道选的核心架构
中台的本质是通过数据统一、实时、在线实现全业务链的贯通、个性化需求扩展以及业务实时联动等 价值 。
思维方式直接关系到数字化转型最终的落地形态和效果,是数字化转型的关键所在。
数字化的建设离不开企业的业务战略。
数字化建设是随着业务的发展而不断演变的过程。
数字化转型虽然是一件长期持续的事情,但没有哪个企业会容许数字化转型或平台的建设在1-2年后仍然无法给企业的业务带来明显的提升价值。




平台思维的十大要素
业务全局视角贯穿业务链
构建支撑业务优化的数据链路闭环
以用户体验最佳为重要原则
提供复用能力支持业务快速创新
支持业务上下游企业的网络协同
支持多个开发团队协同共建
支持用户个性化及业务扩展需求
团队从项目式建设为主转向数字能力产品运营
支持基于能力开放的外部合作伙们生态共建
从职能型组织架构向业务导向型组织架构转变



中台架构建设思路

3.1业务中台建设目标的本质
数据统一
企业通过对业务全局的梳理,明确业务领域中数据格式、标准、对外服务接口的统一,解决业务数据在不同系统中数据格式、标准不统一的问题。
数据实时
在任何业务场景中对该业务领域访问和操作的数据都是当前最新的,不存在数据滞后或不准确的情况。
数据在线
数据以服务的方式提供在线联动,实现数据在平台共享 。
3.2业务中台的核心职能
业务场景覆盖
用户触点汇集
交易处理支持
数据高效和与

3.3服务中心落地形态
代码与数据库隔离
仅提供该业务领域的公共能力
仅以服务方式对个提供访问
支持服务中心的独立运营










3.4中台建设的典型方式

顾旧立新
在保持现有系统不改变的情况下对于企业计划新建的系统采用中台架构建设
优点:最大限度地保护原有IT系统的投资,也不断建设基于中台架构的新系统
缺点:旧系统停止业务需求响应,如果系统切割器较长就会造成较大影响

平滑迁移
在保持这平台或系统运行正常的同时将一套传统架构逐步改造成中台的架构
优点:只需要将部分功能接入中台体系中
缺点:要求企业必须具有强大的技术团队对该迁移系统具备源码级的改造和把控能力。

不破不立
遵行中台建设的最佳实践,逐步指废除原有系统,重新构建新系统。
优点:明确了对哪些旧系统进行替换和改造
缺点:项目投入成本高昂,而且对也无需求梳理、项目协同协作和管控等方面提出了较高的要求






3.5中台建设的典型路径
构建初期
目标:解决局部业务场景问题
措施:组建内部互联网架构团队,建立企业级互联网基础架构平台与业务平台,建设大营销中台+前端改造
完善发展期
目标:覆盖全局业务链,构建数字中台能力,沉淀算法,构建数据优化和驱动业务能力
措施:打造标杆,复制成功经验,打造企业服务和业务运营能力
驱动业务期
目标:利用全业务链场景,利用大数据和算法技术,进行企业内基于数据的核心竞争力打造。
措施:建立数据分析和算法团队,数据驱动业务创新,创造更多价值。
构建生态期
目标:利用数据能力为上下游进行赋能
措施:成立运营组织 以技术服务形式对外输出














3.6中台建设风险与挑战
企业高层领导的支持
明确数字化阶段的核心和重点
组织共识和合理机制
专业人才的参与
成熟稳定的架构和技术平台

3.7基于中台架构的新业务建设原则
自有技术团队+软件外包 联合开发
引入专业解决方案商
引入成熟商业套件




3.8当前企业信息化面临或存在的问题
1.数据割裂,无法发挥数据智能的价值
2.系统间协同成本较高,业务联动性差
3.很难实现业务全局优化
4.不利于数据资产沉淀,无法支撑业务快速响应和探索创新

中台服务设计及平台化运营体系
4.1服务中心建设基本准则
功能和数据具备共享价值
有价值的业务数据不断汇入和沉淀
功能不断完善和丰富
功能边界清晰 具有独立运营价值

4.2中台设计流程和方法
业务中台落地流程
1调研与规划:从发展角度去看企业当下的业务运营情况和未来的业务规划,需要综合考虑企业自身的特性、新技术应用、新业务发展趋势等方面来做总体规划。
2需求分析:从业务规划的各种业务场景出发,梳理核心业务流程,边梳理业务流程边识别业务实体,两者相辅相成。
3中台设计
业务中心分析:流程分析→聚合分析→时序图分析
业务中心设计:业务模型、数据模型和服务能力
4开发实现:开发团队进行详细设计和开发,并没有太多特殊之处,但是需要开发人员掌握分布式、服务化相关的一些开发原则和技术,特别是分布式事务、异步、幂等性等问题






良好的设计原则和方法
契约先行:服务契约公开之后就需要保证良好的稳定性,不随便重构;
服务功能内聚:必须将可能影响到业务正确性的逻辑在对应的服务中一起提供;
服务粗粒度:综合考虑粗粒度,减少前端的远程调用此书,降低其学习成本和耦合度。
消除冗余数据:使用DTO等手段避免携带当前业务场景中不需要的冗余字段;
通用契约:参数和返回值必须是被广泛支持的比较简单的数据类型(比如不能有对象的循环引用,不能有某种特定开发语言才具备的高级特性)
隔离变化原则:避免服务中心内部的重构或者模型变更导致前台应用也跟着变化;
契约包装:可以考虑包装远程服务访问的逻辑,也称服务代理(Delegate Service)模式,由消费者端子机主导定义接口和参数类型,并将服务调用转发给真正的服务客户端,从而让服务使用者完全屏蔽服务器月。
服务无状态原则:要保证服务中心的服务稳定性和可靠性,服务不应设计为“有状态型”的,即服务不应依赖服务使用者和服务生产者之间长期存在的关系。
服务命名原则:优先使用业务概念而不是技术概念。
服务操作设计原则:应当使用具体的业务含义而不是泛型操作对操作进行定义。
重要的服务不能依赖非重要的服务:上可以依赖下,下不可依赖上,平级可依赖但需避免循环依赖,高级别不可依赖低级别。


4.3业务运营体系
数字能力运营平台
产品运营平台
租户运营平台

Tips
一家企业是否具有核心的、差异化的竞争力,在于这家企业是否具备更强的业务探索和业务创新能力。
沉淀可复用的业务能力是数字化转型的重要建设指标,它也是一个重要的指导原则
业务中台和数据中台相辅相成,需要共同构建起企业数据的运营闭环。
企业中台不仅仅需要技术平台的有效支撑,同时也会涉及组织架构、人才、运营等一系列非技术的调整和优化


上一篇: 《行动教练实践指南》读书笔记
下一篇: 开花了
文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags:
相关日志:
评论: 0 | 引用: 0 | 查看次数: 1485
发表评论
昵 称:
密 码: 游客发言不需要密码.
邮 箱: 邮件地址支持Gravatar头像,邮箱地址不会公开.
网 址: 输入网址便于回访.
内 容:
验证码:
选 项:
虽然发表评论不用注册,但是为了保护您的发言权,建议您注册帐号.
字数限制 30 字 | UBB代码 关闭 | [img]标签 关闭