《华为数字化转型之道》阅读笔记
《华为数字化转型之道》 这本书主要分为4个部分：认知篇、方法篇、实践篇和平台篇。先粗读一遍后再精读一遍，做一些笔记，提取出文中的部分内容以及个人的想法观点。主要是对其中的方法篇比较感兴趣，本文也主要涉及这块内容。里面引用了官方书籍中的内容，如有侵权，联系删除。
架构蓝图
通过架构蓝图对数字化转型愿景进行系统性的、分层分级的梳理和诠释，以便企业上下能在同一个蓝图上统一认识。然后基于企业架构中4A架构，从专业的角度对蓝图进行细化设计，以支撑蓝图的落地，从而更有效地指导项目的实施。
如何整合：
华为2016年的架构蓝图：
4A架构
从架构专业角度，通过业务架构、信息架构（数据架构）、应用架构和技术架构4个方面入手，对架构蓝图进行细化设计。
架构的定义：
一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，并且在一定环境和原则下进行设计和演变。
问题：如果不做企业架构规划会带来什么？
系统烟囱式建设，系统边界模糊互相扯皮，系统重复建设，企业内多套标准或者标准不统一，IT系统之间集成困难，难以更上市场需求以及功能的快速迭代。
TOGAF
目前业内最广泛、最流行的企业架构（Enterprise Architecture）就是 TOGAF (The Open Group Architecture Framework)。下面是 TOGAF 10.0 Metamodel 概览图：
TOGAF 的核心就是大家熟知的四大架构：业务架构、数据架构、应用架构和技术架构。
华为“一体四面”企业架构
“一体”指的是瞄准业务目标实现或业务问题解决，由架构师团队协同进行框架设计；“四面”指业务架构、信息架构、应用架构、信息架构、技术架构4个关键要素。
业务架构（Business Architecture，BA）
业务架构是对业务的结构化表达，描述组织如何运用业务的关键要素来实现其战略意图和目标。业务架构由价值流、业务能力和业务流程等几大要素组成。在规划阶段，规划团队可以从价值流出发，识别每一个价值流所需的关键业务能力，进而识别哪些能力可以重点引入数字技术进行业务模式重构，提升业务能力水平。 要点：项目战略/愿景、AS-IS流程图（若有）、TO-BE流程图、服务蓝图、产品功能全景等
信息架构（Information Architecture，IA）
信息架构是以结构化的方式描述在业务运作和管理决策中所需要的各类信息，以及这些信息之间互相关系的一套整体组件规范。业务对象是信息架构的核心，在规划阶段，可以重点分析“产品、客户、合同、订单、员工”等关键业务对象以及分布，分析这些业务对象是否已经在IT系统中进行了管理，了解这些业务对象在系统间的传递是否顺畅，以及是否在数字世界中创建了数字镜像。 要点：数据模型设计、数据治理、数据组件、数据服务、数据平台、数据湖等。
应用架构（Application Architecture，AA）
应用架构识别和定义了支撑业务目标达成所需的IT系统，以及这些IT系统的定位和周边IT系统的集成关系。在规划阶段，应用架构重点关注用什么样的联接平台来构建来构建客户和用户体验，以及采用什么样的IT系统承载数字化转型所需的关键业务能力。 要点：业务到IT的转换，识别支持各业务功能所需要的应用程序、组件、外围IT系统等。
技术架构（Technology Architecture，TA）
技术架构定义了一系列技术组件，代表了各种可以从市场或企业内部获得的IT平台和基础设施资源。在规划阶段，技术架构首先需要关注企业应该引入哪些数字技术，同时需要关注各种业务场景对IT平台和基础设施的需求。 要点：根据应用架构，进行技术支撑分析，例如 技术选型、代码分层架构、PaaS平台、云原生技术、DevOps实践、微服务设计、部署架构等。
这里华为的信息架构与我们常见的理解有些差异，一般叫数据架构。而在TOGAF中数据架构和应用架构合并为信息架构。
转型规划全流程
华为结合多年的实践，总结出的数字化转型的“三阶十二步法”以及实施步骤。
”三阶十二步法“：
具体步骤：
掌握工具知识第一步，如何活学活用才是最难的。
变革管理
数字化转型的落地还需要结合一些系列的变革举措，通常也很容易失败。业界变革项目失败原因有：员工抵制、领导层支持力度不够、期望过高、项目管理不善等。可见变革的来源主要来自人。华为通过其”船模型“来改变或提升人的变革意愿和能力。
产品化思维管理IT
组建业务和 IT 一体化团队，打造一体化产品团队，共同设计和交付。将业务人员和 IT 人员整合到 IT 产品团队之后，需要进行能力的融合及赋能，使业务人员懂 IT，IT 人员懂业务。
IT 能力以服务化的方式提供，接下来看下华为的 V模型 设计。以下关于 V模型 的详细介绍全部引用官方的说明。
V模型 - 从业务到IT的服务化设计方法
什么是V模型
V模型 以服务化理念为核心，以数据为锚点，将自顶向下的业务设计方法和IT应用的规划及设计方法相结合。
从左边的业务设计开始，到右边的IT系统实现，起点是价值流和业务能力。V模型向上对齐业务战略和价值，向下落地到业务设计和IT产品实现。
业务和IT中间是数据，要拉齐业务和IT，关键是找到稳定的业务对象（概念实体），并围绕业务对象进行“业务/数据/应用”的一体化设计。应用服务作为三者的融合单元，实现业务、数据与系统功能的全拉通。
沿着业务场景和业务流程，对业务活动、任务进行逐层分解，把能力转变为服务，使能力能被各种场景下的业务流所调用。服务化从业务设计开始，不仅是IT的服务化，也是业务的服务化。
让不同专业背景的业务和IT专家，用同样的语言、方法规划和设计IT产品，提升沟通的效率和设计的有效性，是业务和IT一体化产品团队工作的有效武器。
V模型关键要素
1、价值流
价值流是一组端到端的活动集合，能够为外部客户或内部用户创造一个有价值的结果。价值流描述企业为他的客户创造什么价值以及如何创造价值。有别于业务流程，价值流是对这个价值创造过程的高阶直观描述。
2、业务能力
业务能力指为实现某一特定目标的一组人力、流程和技术的集合。业务能力是服务化变革的入手点。数字化转型面向愿景，推动和引导业务模式、组织架构和运营模式。这些变革点可以体现在业务能力的变化中，进而落实到人员、流程和技术工具变更中。
3、业务场景与业务流程
业务流程是在特定企业环境及资源保障下，为了实现客户价值和企业商业目标而形成的一套规范业务运作规则和机制：通过一系列可重复、有逻辑顺序的活动，按照相关的政策和业务规则，将一个或多个输入转换成明确的、可度量的、有价值的输出。
由于公司业务复杂，同一业务可能存在不同的场景，比如同样是采购业务，有行政采购、生产采购、工程采购等不同的场景，所以为了保证IT产品的设计方案能具备普适性，我们需要识别出不同的业务场景，针对每一种业务场景匹配相应的业务流程。由于同属一类业务，这些业务流程中的活动有一部分可能是相同的，还有一部分可能是相似的，所以在应用服务化设计时，这些不同流程中相同或相似的活动可以由同一个应用服务来支撑。
4、业务活动
业务活动是流程的基本单元，指某个角色（团队或个人）利用特定的工具和资源，按确定的要求和标准，将明确的输入转换为明确的输出的过程。活动有明确的业务目的以及特定的业务价值。一个活动可以有多个配合角色，但只能有一个主导的角色。活动需有稳定的输入和输出。这里的输入和输出即为BI(Business Item)，就是通常意义上的“表、证、单、书”。
5、业务对象
业务对象是业务领域重要的人、事、物，承载了业务运作和管理涉及的重要信息，是可以独立存在的数据实体。业务对象在业务领域范围要唯一、相对稳定，不应区分场景，不应区分状态。业务对象可以进一步分解为逻辑数据实体，进而再分解为属性字段。
6、应用服务
应用服务是一个或一组软件功能，具有明确的业务目的，独立完整。应用服务既是业务要素，又是应用要素。它封装了对业务对象的操作，并支撑一个或多个相关联的业务活动。应用服务需明确服务接口和服务标准。应用服务是业务、信息和功能的聚合。
应用服务不应由业务人员或IT人员单独设计，而应由组织业务设计师、信息架构师和系统工程师等共同参与设计。应用服务是对外共享的独立、完整的功能，是服务化设计的核心。
7、应用系统模块
应用系统模块是为支撑特定业务需求而提供的一组紧耦合的物理功能，可独立测试、发布和部署。模块内高内聚（相同或高度相似的功能应归于同一模块），模块间低耦合（模块间的依赖最小化并通过服务接口集成）。一个或几个关联紧密的应用服务组合为一个应用系统模块。模块的颗粒度不宜过小，否则可能出现服务间过于频繁的信息交互，导致服务运营困难。
8、产品/子产品
作为产品运作管理单元，产品/子产品是强关联的一组模块的集合，也是产品团队进行建设、预算、核算、考核、合作分包等管理的基本单元。
V模型过程示例
1、确定业务能力
价值流和业务能力是起点，所有的业务领域都是为提供某一组特定的业务能力而存在的。开始时需要先识别所处的业务范围，以及业务的外部客户或内部用户是谁，并从如何为客户或用户创造价值的视角，一步步描绘这个价值创造过程；继而识别为了实现业务的价值创造，需要具备什么样的业务能力。
2、分析业务场景，定义并收敛业务活动
接下来需要基于对价值流的细化，以及对业务能力的描述，识别具体的业务场景和业务流程，并沿着场景和流程，对活动进行逐层分解定义。另外，不同场景可能存在相同或相似的活动，需要将这些活动一一识别出来。
3、识别BI，定义业务对象
识别每一个业务活动输入和输出的“表、证、单、书”，定义业务对象。如果一个活动的输入和输出符合业务对象的特征，则可以是一个业务对象。反之此BI不能独立存在，需要继续确定所归属的业务对象。
4、识别应用系统模块，以及应用服务/特性
基于业务对象初步识别出应用系统模块，保持两者有相同的颗粒度。然后，基于逻辑实体和活动，识别出一系列应用服务清单，再将应用服务归类于某一应用系统模块。通常来说，同一业务子领域下的应用系统模块组合成一个产品，同一业务领域下的产品组合成一个产品族，使IT建设对准业务。
设计的核心：围绕相对稳定的数据来设计业务和IT
V模型的核心是找到数据业务对象，不管业务组织、流程和场景如何变化，其所操作的业务对象相对稳定。可以围绕业务对象来设计作业活动和规则，并识别功能特性。
以供应链仓储的入库业务为例，该业务包含了原材料仓入库、成品仓入库、分销中心入库、国家中心仓入库、站点入库等诸多场景，但所有场景都是围绕“入库单”这个业务对象的“增、删、改、查”，所以要围绕业务对象进行业务和IT设计，包括业务活动、活动的输入和输出、作业步骤、作业规则和算法等（见图5-12），形成可被各种场景调用的服务。
实行IT产品化运作的模式，组建业务和IT一体化产品团队，用商业视角来定义产品的价值主张，快速迭代，持续交付，实现业务价值。
Y模型：业务运作模式重构
从价值流出发描述创造价值的端到端过程。
运营商业务示例：
分析客户旅程
定义价值流，匹配客户旅程的关键活动
识别客户旅程的关键接触点
识别和定义业务场景
业务场景设计
业务服务化
数据底座
数据底座整体设计
数据湖是逻辑上各种原始数据的集合，除了“原始”这一特征外，还具有海量和多样（包含结构化、非结构化数据）的特征。数据湖保留数据的原格式，原则上不对数据进行清洗、加工，但对于数据资产多源、异构的场景则需要整合处理，并进行数据资产注册。
数据入湖
数据入湖的5种主要技术手段包括：
批量集成(Bulk/Batch Data Movement)
数据复制同步(Data Replication/Data Synchronization)
消息集成(Message-Oriented Movement of Data)
流集成(Stream Data Integration)
数据虚拟化(Data Virtualization)
写在最后
我们经常使用4A架构理念去做架构设计，那么是否可以结合DDD进行落地呢？
这里通过一些具体的例子来了解它们之间的关联：
业务架构（Business Architecture）：
DDD强调通过领域专家和开发团队的合作来定义业务需求。业务架构中的关键流程、功能、角色和能力可以通过DDD的领域模型来描述。
例如，在银行业中，可以有“客户服务”、“贷款审批”和“账户管理”等领域，这些领域可以通过DDD的边界上下文（Bounded Context）来划分。业务架构中的流程图、业务能力模型等可以映射到DDD的领域模型中。
应用架构（Application Architecture）：
DDD中强调的边界上下文和聚合（Aggregate）概念与应用架构中的模块化设计相契合。应用架构中，系统之间的接口和服务划分可以通过DDD的边界上下文进行管理。
例如，电商系统中的“订单处理”和“库存管理”可以是两个边界上下文，每个上下文中都有相关的聚合和服务，这与应用架构中应用系统的划分相符。
数据架构（Data Architecture）：
DDD中的领域模型和实体通常代表业务中的关键概念，这与数据架构中的数据模型、实体关系模型相对应。通过DDD的领域模型来设计数据结构，可以确保数据架构与业务需求一致。
例如，在客户关系管理系统中，客户实体可以有多个属性，如姓名、地址、订单历史等。数据架构可以从领域模型中提取这些实体，构建数据库表结构。
技术架构（Technology Architecture）：
DDD的分层架构与技术架构有很强的对应关系。DDD中的应用层、领域层、基础设施层等与技术架构中的软件架构、开发框架、通信技术等相关。
例如，在一个微服务架构的项目中，应用层可以与REST API相对应，领域层可以包含业务逻辑和领域模型，基础设施层可以包含数据库和消息中间件。这种分层架构可以反映在技术架构的设计中。
通过以上实例，可以看到DDD与4A架构中的不同方面的对应关系。DDD通过聚焦领域知识，帮助业务架构、应用架构和数据架构之间的有效联系，并在技术架构中提供了一种分层的设计方法。