ThoughtWork现代企业架构白皮书-数字化转型底层方法论

Keynote

原件地址

核心内容

定义了一套轻量化、敏捷可落地的企业架构框架方法：现代企业架构框架（Modern Enterprise Architecture Framework）。

并阐述了其[企业级业务架构]、[企业级应用架构]、[企业级数据架构]和[企业级技术架构]的核心元模型以及元模型的应用场景和建模方法。

概念定义

• 架构：架构是系统在其所处环境中的基本概念或属性，体现为它的元素、关系，以及系统设计和演进的原则
• 企业架构：一种架构体系。关注的是在企业级别的各种视角（viewpoint）及其视图（view），其中的基本元素及其关系。
• 企业架构框架：一种具体可实施的框架和方法论。例如：TOGAF，以及本文所述的MEAF
• 元模型（Metamodel）：定义用于结构化描述架构设计的模型元素及其关系。业务架构、应用架构、数据架构和技术架构均为元模型，各自有不同的模型元素。
• 视角（Viewpoint）：不同组织和干系人对企业架构的关注点不同，其所关注的角度即视角。
• 视图（View）：一个视图描述了从一个或一组相关的视角（Viewpoint）出发，通过组合这类视角所关注的元模型（Metamodel）要素及其关系，通过设计与建模之后，形成的切面视图。业务架构视图、应用架构视图、数据架构视图和技术架构视图即是分别从业务、应用、数据、技术视角出发，通过业务架构、应用架构、数据架构、技术架构元模型元素构建出的视图。
• 企业级业务架构：定义了企业各类业务的运作模式及业务之间的关系结构
• 企业级应用架构：关注业务需求是由哪些应用承载的，它们与用户是如何交互的，它们之间的关系以及是如何交互的，它们访问或变更了什么数据。
• 企业级数据架构：描述企业经营过程中所需数据的结构及其管理方法，其目标是将业务需要转换为数据需求
• 企业级技术架构：对某一技术问题（需求）解决方案的结构化描述，由构成解决方案的组件结构及之间的交互关系构成

架构视图

业务架构

目的

• 承接企业战略、支撑实现企业战略
• 通过对业务能力的识别与构建，并将业务能力以业务服务的方式透出，实现对于业务流程的支撑，并最终通过组织给予保障

元模型

• 业务
  • 业务群
  • 业务
  • 场景
• 流程
  • 阶段
  • 活动
  • 任务
  • 步骤
  • 规则
• 组织
  • 组织单元
  • 岗位
  • 角色
• 服务
  • 业务服务
• 领域
  • 子域
  • 领域对象
  • 领域事件
• 模式
  • 流程建模
    • 通用流程
    • 可变点
  • 领域建模
  • 业务身份建模
    • 业务身份
    • 扩展实现
  • 能力建模
    • 解决方案
    • 能力组件
    • 基础能力
    • 扩展点

建模过程

业务梳理阶段：对企业业务、流程、组织、业务服务和业务规则进行细致完整地梳理，作为后续模式设计的基础和输入

• 业务维度
  • 业务群：是企业基于业务战略拆解，确定开展的特定经营活动。比如：开展 ToC 的电商平台经营活动，其下又进一步细分为快消品业务群和消费电子业务群等。
  • 业务：是业务群下具有业务价值的业务单元。比如：实体商品业务、生活服务业务等；内部支撑类的业务比如人力资源管理等。
  • 场景：是面向用户提供价值的端到端业务场景。通 常 从 4W1H（What、Who、Where、When、How）的维度识别和定义业务场景要素，然后从业务场景要素的排列组合中筛选出有实际意义的业务场景
• 流程纬度
  • 阶段：即业务流程阶段，包含一组用户的及与用户交互的业务活动，用以实现阶段性价值交付的目的。比如：售前、售中和售后等。
  • 活动：即业务活动，是某个业务角色办理的业务事项，包含一个或一组任务，有明确的业务成果和业务输出。比如：商品发布、活动发布等。
  • 任务：是完成活动的工作程序，是流程的基本组成单元。比如：查询商品详情、更新商品库存、创建订单等。
  • 步骤：是完成任务的具体步骤，是流程的最原子操作。比如：校验用户状态、校验商户状态、订单总价试算等。业务规则：是定义或约束业务某些方面的陈述，旨在维护业务结构或控制或影响业务行为，它描述业务过程与决策过程。比如：if 订单. 提货方式=“邮寄” 且 订单. 支付状态=“已支付” then “创建物流单”
• 组织纬度
  • 组织单元：是公司组织体系的组成单元。
  • 岗位：是随组织结构设定的，要求个体完成的一项或多项责任以及为此赋予个体的权力的总和。
  • 角色：是业务流程中活动参与者的原型，参与者在流程中的位置通过担任合适的角色确定。组织为完成某一目标，往往会把此目标分解，以便能交给不同能力和责任的角色合作完成
• 服务纬度
  • 业务服务：是企业和企业的每个业务单元为其客户提供的内部和外部服务。服务是能力对外呈现价值的方式，是具备明确的业务特征，独立完整、由一个或多个关联紧密的功能组合的集合。比如：开户、提交订单等 模式设计阶段：通过流程建模、领域建模、业务身份建模和能力建模4个步骤完成企业能力的识别构建
• 流程建模：负责识别共性业务，并抽取通用流程，设计可变点，作为可复用性分析的基础。
  • 分析业务组合，提取共性业务。
  • 分析所有共性业务的各流程步骤及其输出对象，抽象提炼通用步骤和业务实体；识别各业务的差异部分，提炼设计可变点，确定可变点实现和关系。
  • 分析所有共性业务的各流程任务，抽象提炼通用任务；识别各业务在任务上的差异部分。
  • 分析所有共性业务的各流程活动，抽象提炼通用活动；识别各业务在活动上的差异部分。
  • 分析所有共性业务的各流程阶段，抽象提炼通用阶段；识别各业务在阶段上的差异部分
• 领域建模：负责基于流程建模结果，识别领域事件和领域对象，并划分子域的边界；领域对象构成了提供可复用能力的基本单元，对领域对象的操作即是基础能力。
  • 识别领域事件（事件风暴）
    • 邀请业务专家（或领域专家）和技术专家共同参与事件风暴工作坊，其它参与角色按需补充。
    • 明确和选择需要分析的业务场景。
    • 确定起始事件和结束事件，事件以“XXX 已YYY”的形式进行命名（对于英文版过去完成时的中文表达方法）。
    • 根据场景和业务复述的复杂度，决定以时间线的哪个方向开始梳理事件（正向或逆向）。
    • 以先发散再收敛的方式，按照时间线的先后顺序和并行关系，补充和完善领域事件。
    • 使用“规则”抽象分支条件或复杂的规则细节，通过抽象降低分支复杂度，规则以“XXX 规则”的名词形式进行命名。
    • 完成一遍事件梳理之后，通过问问题的方式，逆向检查（Reverse Check）事件流的逻辑合理性，例如：该事件真的需要在系统实现的时候考虑吗？该事件如果存在，那它的前提条件是什么？该事件如果要产生，那它的前一个事件必须是？
    • 重复以上步骤，迭代式的完成全部领域事件的识别
  • 识别领域对象
    • 对每一个领域事件，快速识别或抽象出与该领域事件最相关（或隐含的）的业务概念，并将其以名词形式予以贴出。
    • 检查领域名词和领域事件在概念和粒度（例如数量，单数还是集合）上的一致性，通过重命名的方式统一语言，消除二义性。
    • 如果在讨论过程中，有任何因为问题澄清和知识增长带来的对于之前各种产出物的共识性调整，请不要犹豫，立刻予以调整和优化。
    • 重复以上步骤，迭代式的完成全部领域对象的识别
  • 划分子域
    • 根据“每一个问题子域负责解决一个有独立业务价值的业务问题”的视角出发，可以通过疑问句的方式来澄清和分析子域需要解决的业务问题，例如“如何进行库存管理？（英文描述类似 How to…？）”。
    • 利用虚线，将解决同一个业务问题的限界上下文以切割图像的方式划在一起，并以“XXX 子域”的形式对每个子域进行命名。
    • 根据三种类型的子域定义，共同结合业务实际（或者参考设计思维中的电梯演讲），确定每个子域的子域类型
• 业务身份建模：负责定义业务身份识别的要素和业务身份解析规则，用于给可复用的能力区分不同的业务身份要素。
  • 分析业务组合，提取业务身份要素维度。
  • 确定各业务身份要素维度对应的领域对象（包括领域对象的属性）。
  • 确定领域对象各属性的取值条件规则，定义业务身份识别解析规则。
  • 指定业务身份名称。
  • 指定业务身份 ID
• 能力建模：负责最终完成平台三类可复用能力的设计，即“基础能力”设计、“能力组件”设计和“解决方案”设计
  • 基础能力：是对领域对象的原子操作，完成一个领域对象上单一且完整的职责。比如：创建售后单、修改商品库存量等，是能力组合和复用的最小单元
    • 对流程建模步骤中输出的各“任务”下的所有“步骤”，确定其对应的领域对象（注意，该领域对象应来自于前面的领域建模步骤）。
    • 根据步骤对领域对象的操作，设计对应的基础能力；基础能力的设计应遵循如下原则：
    • 完成对一个领域对象单一且完整的操作职责
    • 基础能力操作的领域对象最大不能超出单个聚合，最小不能破坏业务的一致性要求
    • 基础能力的输入与输出建议对象化，以规范使用
    • 根据流程建模步骤中识别出的与该基础能力有关的可变点，以及各业务身份在该可变点上不同的业务规则，提炼设计出基础能力的扩展点
    • 确定扩展点的默认实现（即默认情况下基础能力执行的业务规则）
  • 能力组件：能力组件是对基础能力的进一步封装，目的是方便业务的使用。按封装粒度不同分为两类：第一类能力组件是根据业务服务的需要编排封装的一组关联的基础能力，从而提供完整的服务。比如：订单创建能力组件;第二类能力组件是平台针对一系列紧密关联的业务活动，设计的能力模板，可基于该模板快速定制某个具体业务的特定流程和能力，从而达到复用全部关联能力的目的。比如：“组合支付”、“快速建站”等能力组件。能力组件加快了业务接入平台的速度，让业务侧专注业务本身，不再需要耗费精力在理解平台大量的基础能力上。
    • 对流程建模中输出的每个任务，设计其所需的业务服务，可采用服务蓝图的方法进行业务服务设计。
    • 对每个业务服务，封装编排满足其需求的一组基础能力成为第一类能力组件。
    • 对流程建模中输出的阶段和业务活动进行逐项分析，从价值交付和阶段性价值交付的角度，识别对应的一系列紧密关联的业务活动；将这些业务活动包含涉及的所有能力组件和基础能力封装定义为第二类能力组件
  • 解决方案:是平台针对一类共性业务的端到端过程设计的能力模板；可基于该模板快速定制某个具体业务的特定能力和流程，从而达到业务模式级别复用的目的。比如：虚拟物品交易解决方案
    • 识别和提取共性业务。
    • 对共性业务进行流程建模和领域建模，具体方法参见前面所述。
    • 进行基础能力和扩展点设计。
    • 进行能力组件设计。
    • 基于通用流程，将共性业务中包含的所有基础能力、扩展点和能力组件封装定义为解决方案
  • 复用基础能力和能力组件的主要步骤如下：
    • 配置新业务对应的业务身份在各基础能力扩展点上的扩展实现，如果无需定制可直接采用默认扩展实现。
    • 开发基础能力的扩展实现。
    • 根据业务流程，编排基础能力和能力组件，实现业务需求。
    • 对于现有能力不能满足业务需求的情况，需要平台侧新增开发任务，修改或者新增基础能力和能力组件；然后应用侧按上述过程完成定制使用
  • 复用解决方案的主要步骤如下：
    • 基于选定的解决方案，配置新业务的业务全流程。
    • 配置新业务对应的业务身份在各基础能力扩展点上的扩展实现，如果无需定制可直接采用默认扩展实现。
    • 开发基础能力的扩展实现。
    • 根据业务全流程，编排基础能力和能力组件，实现业务需求。
    • 对于现有能力不能满足业务需求的情况，需要平台侧新增开发任务，修改或者新增基础能力、能力组件和解决方案；然后应用侧按上述过程完成定制使用

应用架构

目的

• 应用颗粒度的设计
  • 向外围可延伸到平台型企业架构对于应用分层、分组的设计
  • 向内部延伸到应用内部的架构设计
• 通过其中的领域对象串联各个架构视图

元模型

• 端口：对应用的出入口建模
  • 应用服务
  • 扩展点
• 结构：对IT系统的职责、边界建模
  • 应用组：包含多个应用，纵向切分
  • 应用层：包含多个应用，横向切分
  • 应用：包含多个应用组件
  • 应用组件：对功能和数据的封装，是应用架构层面的最小单元
• 状态：对应用状态的变更建模
  • 不变量
  • 领域对象

建模过程

应用组

输入：业务架构的业务、组织两部分成果 步骤：

• 根据业务架构的业务、组织进行粗粒度划分，帮助快速找到进一步划分的切入点

应用组件

输入：业务架构的业务流程、业务对象、业务规则 步骤：

• 子步骤一：功能和数据识别
• 子步骤二：功能与数据关联，识别应用组件
• 子步骤三：识别、调整各应用组件之间的依赖关系

识别顺序

从流转类的应用组件开始识别，再延伸至规格类、视图类，最后到配置类

组件类型

• 流转类
  • 功能：支撑某个流程或流程中的一段活动
  • 数据：流程的状态流转信息和决策证据
  • 例子：结账组件，其支撑的流程是结账流程，管理的数据是订单
  • 变化原因：流程编排变化
• 规格类
  • 功能：支撑某个额业务规则，给出专业意见
  • 数据：一般不管理数据的生命周期，只负责加工给出结果
  • 例子：验证（如发票是否预期）、筛选（三月内消费过的客户）、计算（计价、导航路线建议）
  • 变化原因：业务规则的计算逻辑变化
• 视图类
  • 例子：验证（如发票是否预期）、筛选（三月内消费过的客户）、计算>（计价、导航路线建议）
  • 功能：支撑某个业务活动所需的整合信息
  • 数据：一般不管理数据的生命周期，只负责加工给出结果
  • 例子：商品信息的整合展示、统计报表
  • 变化原因：视图组抓昂逻辑变化
• 配置类
  • 功能：为前三类提供配置输入
  • 数据：基础的资源信息
  • 例子：商品目录设置内容管理系统中的配置功能规则的开关
  • 变化原因：前三类对配置要求的变化

应用

输入：应用组件 步骤：

• 基于应用组件构建应用物理边界
• 识别是否存在架构质量属性冲突

质量属性冲突

• 该边界内是否存在变更频率冲突
• 该边界内是否有特别的移植性要求
• 该边界内是否有特别的弹性要求
• 该边界内是否有特别的性能要求
• 该边界内是否有特别的可用性要求
• 该边界内是否有特别的信息安全要求
• 该边界内是否有特别的合规要求

应用层

输入：应用 步骤：

• 识别出变化速率上的差异
• 为不同的变化速率匹配架构设计目标和管理方法

应用服务与扩展点

输入：

• 「自动化」的业务服务
• 业务架构中的「能力组件」，「基础能力」 步骤：
• 业务架构中的「能力组件」转换为「应用服务」；「基础能力」转换为「功能」

数据架构

目的

将业务需要转换为数据需求

元模型

• 结构：对数据的职责、边界建模
  • 数据对象：从数据视角对现实世界特征的模拟和抽象
  • 数据组件：为数据加工工序建模，输入输出均为数据对象
• 端口：对数据的出入口建模
  • 数据服务：对外显示定义的支撑分析类场景的服务契约

建模过程

数据对象和数据组件

输入：应用组件背后的数据 步骤：

• 定义数据对象
• 数据抽取（数据对象承载）
• 加工转换（数据组件加工）
• 保存至数据仓库/数据湖
• 提供数据服务
  • 贴源层服务：针对某个业务场景自身的分析服务
  • 衍生层服务：整合多个数据源的分析服务

技术架构

目的

结构化描述针对业务、应用、数据等上层架构设计意图的开发实施方案

元模型

• 架构模式：快速识别问题本质以及经验复用
• 架构方案：描述技术架构设计
  • 平台：由一组技术服务构成，提供解决特定技术领域能力的逻辑模型
  • 服务：实现上层架构设计意图所需的技术能力或功能；目的是将上层架构中的技术需要与实现相分离
  • 组件：描述技术服务的实现，是可部署的物理组件
• 架构策略：约束和规范架构设计过程

建模过程

输入：上层架构设计 步骤：

• 系统性的分析架构需求
  • 分析：针对上层架构设计进行分析和解读，形成问题和上下文
    • 问题描述了架构需求背后要解决的实际问题是什么，例如业务中台中如何保证前台获得一致的服务等级承诺（SLA）。
    • 上下文描述了与问题相关的背景信息，例如问题产生的背景是什么，需要考虑什么样约束条件，期望达到什么样的效果等等
  • 应用模式：通过对问题和上下文的分析，快速映射到的业界或企业内的最佳实践
  • 决策：描述在模式的基础上，引入与具体架构方案设计相关的影响因素后，形成的符合满足架构建设需求的技术类决策，决策的描述方式可以是决策树或决策表
• 结构化的设计架构方案
  • 技术组件：用于描述技术服务的实现，是可部署的物理组件，例如可运行的软件系统或构建打包后的应用组件，技术组件通过架构模式的决策元素，与技术选型进行关联
  • 技术服务：描述实现上层架构设计意图所需的技术能力（或功能），例如网关、防火墙、数据存储、缓存等。技术服务属于逻辑模型，作为一种对服务能力的描述，与之相关的 SLA 等跨功能性需求会同时作为其参考描述信息
  • 技术平台：描述由一组技术服务构成，提供解决特定技术领域能力的逻辑模型，它主要用于从更高的层次对技术服务进行管理，简化架构参与者对复杂架构的理解和使用，统一对用户提供一致的 SLA 服务承诺
• 沉淀可复用的架构经验
  • 模式：解决某类问题的最佳实践，只要问题存在，模式就是稳定不变的，不受使用场景的变化而变化，可以结合领域扩展模型对模式细节展开描述。
  • 经验：经验是特定场景中对模式的实例化应用的过程记录，经验可以加快对模式的理解，学习如何结合实际场景应用模式解决问题，经验的内容由架构模式元模型中的问题、上下文、决策三个元素组成，每个元素可以通过定义对应的参考模型展开描述
  • 方案：最后是架构设计结果，作为案例供后续参考