关于业务平台架构的思考

关于业务平台架构的思考

从我们最熟悉的说起——业务是什么？

1. 职业上的事务，统称为「业务」——辞海
2. “业务”更白话一些来说，就是各行业中需要处理的事务，但通常偏向指销售的事务，因为任何公司单位最终仍然是以销售产品、销售服务、销售技术等等为主。“业务”最终的目的是“售出产品，换取利润”。——百度
3. anything that relates to organizing the exchange of goods and services by a business, a governmental institution, or an agency”. ——OpenGroup Togaf—business architecture

业务的定义

业务：企业接受客户订购，并将商品或服务交付给客户的一系列活动的总和，称之为一个业务。 业务的基本特征是产品+组织。当产品交付给客户时，面向不同客户、市场、行业，如何解决业务的差异性？答案是业务身份。 业务身份是现实业务在系统中给予的唯一编码标识，是基于“业务”差异性划分而形成的系统ID。业务身份的本质不是为了区分逻辑判断，而是区分需求来源以及规则的适用范围。因此，业务身份应该有全局的一致性。

业务平台架构的定位是什么

• 从业务内部看，要解决的主要问题是什么？
  • 创新：不断适应市场的业务策略
  • 低成本：实施成本低
  • 快速响应：能快速推进，快速试错
  • 外部资源：易于获得生态内足够的外部资源，如流量、供给、渠道
• 从全局看，怎样支持业务快速发展？
  • 基础强大：有强大的基础平台支撑，通用能力得到保证
  • 组装灵活：可以快速选择部分能力，构建适合自身需要的支撑体系
  • 易于变化：变化牵涉面小，可以快速定制
  • 自主投入：不受基础平台资源瓶颈限制
• 从内（技术）外（业务）两个角度看，需要的能力
  • 功能丰富：靠积累
  • 易于复用：粒度合适，易于集成（技术兼容）
  • 开放定制：平台开放（架构开放），运行解耦（部署灵活）、研发过程解耦
  • 信息共享：概念一致、场景链接
  • 沟通顺畅：共同的术语、对业务整体的一致认识
• 从业务角度看，能够被复用或信息共享的前提
  • 核心管理对象的一致性
    • 概念一致：对象+关系
    • 数据描述一致：主数据
  • 存在一定层次的流程一致性
    • 关键活动
    • 基本规则
• 从从技术的角度，软件怎样被复用？
  • 功能复用：一段功能被完整使用
  • 接口复用：输入输出定义复用，实现逻辑重写
  • 流程复用：一段控制结构被复用，控制逻辑加上节点
  • 规则复用：一段判断逻辑被复用

复用的前提是业务实质的相似性，如果管理的核心对象存在较大差异，绝大部份情况下，以上复用都没可能

业务平台的能力取决于

• 是否存在基础的具有共性的关键业务环节
• 是否存在需要全局共享的关键资源
• 是否存在需要广泛连接的关键应用
• 是否存在需要大范围执行的管控规则
• 是否需要稳定性SLA

其价值体现在于

• 通过沉淀可复用的软件基础设施，达到降低成本的目的；
• 通过提供开放的基础架构能力，支持创新和差异化经营；
• 通过管理基础数据和基本流程节点，提供全局管控的手段和稳定性保障

业务架构模型分析

• Business Process：TMF ，APQC
• Business Capability：Open Group ;Gartner
• Value Stream：Open Group
• Business Service ：FEA

描述业务的几个视角

• Business Capability (What)

A particular ability or capacity that a business may process or exchange to achieve a specific purpose（业务为实现特定目的或结果而可能拥有或交互的特定能力或产能）

• Business Process (How)

A set of structured activities or tasks with logical behaviors that produce a specific outcome, service or product（一组有逻辑行为的结构化活动或任务，产生特定的结果服务或产品）

• Business Value Stream(Why)

A sequence of activities an enterprise undertakes to deliver on a customer request（表示一组端到端增值活动集合，这些活动为客户、干系人或者最终用户获得一个总体结果）

在推动企业IT服务能力的持续演进，业界已经有丰富的参考，分析前述参考模型可以看到：

• 顶层的视图，不论哪种描述方式，都是先从企业的管理范围做大的划分——基于价值链的分析形成顶级视图，以是否直接服务客户为基准划分不同分类
• 从内容逻辑看，大多讨论都涉及组织、能力、过程的关系。
• 虽然在不同的时期，不同的视角，强调的重点不同，但都是希望建立更易于为业务理解的视图，并成为构建IT系统的桥梁。

通常，企业架构包括业务架构、技术架构、应用架构、数据/信息架构，而业务平台最薄弱的环节在于业务架构：

• 已经形成框架，但缺乏对关键概念的确切定义
• 已经形成平台，但缺乏长期演进的规划指引
• 已经形成对业务的基础性支撑，但基础能力没有明确的定义
• 平台团队，缺乏对业务的结构化思考框架指引，容易造成团队能力的瓶颈

因此，我们首先需要健全业务架构体系。业务架构体系的构建关键在于先要建立业务视角。那么，什么是业务视角？

• 用业务发生的方式描述业务：围绕能力、流程与场景描述
• 将业务现象背后的逻辑进行结构化呈现
• 强调结果而非方法实现，屏蔽技术细节

那我们要如何才能建立业务视角呢？

• 首先要明确业务目标，理解业务含义，**知道结构划分的依据 **
• 要建立端到端的全流程视角，业务需求能够对应到系统功能
• 在业务沟通中，统一使用达成共识的业务语言而非技术术语
• 系统被业务感知的部分要有明确的业务语义以及清晰的边界

业务平台架构是一个以流程为基础，以能力为表达的层次结构。第一层，明确语义和范围；第二层，构建完备、正交的业务模型；第三层，与交付形态相结合，提供服务SLA。无论从能力角度，还是从流程角度，都是对企业行为的一种描述方式。我们既可以通过满足的客户需求出发，构建能力的集合，也可以根据流程到企业能力的对应，建立起整体的能力框架或过程框架。

关于域（domain）的思考：过程域、功能域、能力域、信息域

域是一个广泛被使用的词，但是定义也很宽泛。（BD：特指某一专业性范围，涉及在该范围内的所有事项均可引用）领域建模这个词很熟悉，但具体领域是什么，在我们当前的实践中并没有可以判定的简单标准。域常常被理解为不同的场景：功能域、过程域、数据域。如果从OO的核心思想出发，则可以将域做一个统一认知：

• 功能是对象行为的外部表现，但作为域的聚合的依据是对象
• 对象的行为和数据是不可分开的，过程是对象行为的执行过程

基于以上的认知，域的概念可以统一为“信息域”，数据是信息的载体，信息是对数据的语义解释。因此，领域建模就是找出问题范围内的对象及其关系，根据对象间关系的紧密程度，来确定是否属于一个域。

价值链把企业的能力划分为核心能力以及辅助能力的划分，实质是以客户为中心，区分客户与企业两个角色。根据TMF-eTom的划分方式，在核心流程进一步细分基础设施和战略、运营，和生产不直接相关的活动都定义为企业管理。

能力的语义分析——5W1H的逻辑

• Why 强调价值
• What 强调目标
• When 时间
• Where 地点
• Who 参与人
• How 方式方法

当我们在较高层次谈能力，往往是在谈Why和What；在较低或细节的层次谈能力，则往往强调的是3W1H——即做的程度和特性。

能力的描述通常有两种形式：一是按照做什么和达到的目标来描述；二是按照特性来描述。而特性往往体现为两类：

一是对一个或多个对象属性值的组合的描述，值的组合往往体现为场景。比如担保交易是一个能力描述，那么担保本身是交易的分类特性，就是交易具有的特点。 二是对一个过程执行的非功能特点的描述。如时间、空间等。比如秒杀，描述的是交易的时间特性，又比如店铺红包，描述的是红包使用的范围（也可以理解为空间特性）。

能力的特性描述实际是场景切分的方式。一旦进入场景，就是离散的结构，而按照流程的能力划分方式，则可以是逐步细化的方式，会形成树状的结构。如果我们把二者结合，并加以规范，就能形成既可以满足MECE，又能够把两种特点有效体现的描述方式。

1. 按照端到端流程完成初始能力描述
2. 找到流程的各个环节，分解成不同的能力
3. 在流程各个环节里，找出关键参数，描述业务的适应能力
4. 找出关键的非功能性的特性
5. 把流程各个环节较为固定的组合找出来

能力分析 vs 流程分析

能力：要达到一个目的，得到一个结果，如果是服务于客户，从客户的角度看，就是“我” 帮客户完成了一件什么事情 流程：我要干一件什么样的事情，其的步骤，体现的是做的过程。 从划分的结果来看，能力划分和流程划分是一致的，但从思考的角度看，是不同的。从划分的确定性看，因为角色有限，能力从结果和目标的角度，避开路径的复杂性，有更强的确定性。

业务建模 vs 业务架构

在独立讲述流程建模或者能力建模的论述中，都强调用业务的语言，构建符合业务习惯的成果。业务建模只强调逻辑的完整性，但是在以IT实现为目标的前提下，业务建模和IT实现之间必须建立简单的对应关系。无论是能力建模或者过程建模，最终要与信息模型建立映射关系。在业务分散而平台支撑要统一的情况下，也可以看作是IT在寻找和业务的共同语言。

商业能力的划分

能力划分的核心是围绕客户，以是否与客户诉求直接相关作为基准划分。在顶层的视图，划分能力和流程的视角是一致的。因为无论流程视角还是能力视角，都要找出我们能为客户做什么。所以，我们仍然可以区分三类能力：1）客户销售与服务能力；2）支撑能力；3）企业管理能力。

能力划分的逻辑 ** 能力划分是自顶向下的逻辑分解的过程**。能力分析的出发点首先是角色分析，以满足角色的诉求为目的，因此，其顶层的划分都是以角色的诉求为划分基础，本质是场景（或流程）的划分。**前端的能力是直接服务于客户需求的，所以其顶层可以按消费的逻辑进行划分。**场景的细分本身可以构成能力细分的逻辑基础，但仍然需要找到场景细分的逻辑。**后端支撑能力本质是服务于经营者，可以从经营者的诉求进行划分。**但因为内部角色的分散，难以在顶层形成贯穿全局的流程主线，就会形成面向资源的分散流程。所以，其能力划分既可以按大的角色分类进行，也可以直接按资源分类进行。这里的资源，本质就是我们所说的域。这也代表了一类细分的思路，在场景细分的划分基础上，通过资源的分类完成下一级的细分。即便到了资源的分类层次，仍有可能进一步细分的必要，这又会回到场景划分的逻辑。所以，业务能力建模的过程也是在不断寻找不同层次的能力切分逻辑的过程。 从全局看，核心是以客户为中心进行能力的划分，其实质是按照直接满足客户需求到为满足客户需求进行间接准备来划分。实际上，每一部分能力都服务于生态中的某个特定角色，所以在能力的描述上，直接满足的是当前角色的价值要求，间接地通过客户为中心视角进行原则性校验。

• 企业的能力围绕“客户、企业自身、合作伙伴” 的生态形成闭环。
• 前端围绕满足客户需求
• 后端分为满足生产要素管理和满足企业自身管理
• 企业管理暂不涉及

后端支撑能力与企业管理能力

• 后端支撑能力
  • 客户管理
  • 产品管理（PLM）
  • 合作伙伴管理*
  • 营销活动管理
  • 账单与收入管理
  • 资源管理
• 企业管理能力
  • 人力资源
  • 财务
  • 技术发展
  • 基础建设
  • 法务
  • ……

从概念性的能力到软件实现的层次

能力的表现形式

• 高层的能力，应该是逻辑的表达，对应于软件的整体或可独立交付的部分
• 低层的能力，应该和软件的外在存在形式关联，如分布式环境中的服务接口、SDK中定义的接口

能力的划分

能力是围绕以完成客户诉求为目标来划分的，完成一个能力可能需要多个领域对象的协作。能力的细分有横向和纵向的划分方式，未必代表软件实现的粒度细分，所以要建立能力和软件实现的映射关系。但在能力粒度上，一定需要和软件的交付物有一致并且明确的边界。

再看能力、流程、域的关系

能力是按照完成目标来划分的，流程是按照执行过程划分的，域是按照实体聚合切分的。业务流程是业务感知结果的流程，系统流程是执行步骤的划分。域内可以有流程，域的多项能力可能对应细分流程的多个步骤，不一定有必然的先后顺序，也可能是离散的能力组合。域和能力之间也需要在一定的粒度上建立映射关系，否则会造成在域和能力都有很多层次，并在多个层次间建立复杂的映射。

商业能力层和域内的关系

商业能力是客户可直接感知的能力，越是面向客户直接交互的层次，在技术上越难以限制其差异性，可能会与需求直接映射；越是趋近技术实现的层次，越是需要更高的抽象，以间接满足需求。 商业能力提供流程性的封装，在顶层按照与客户的交互场景划分，并结合域的划分进行分解。商业能力层以提高交互场景的合理性和对外的灵活性为目标，关注的是面向客户体验的逻辑实现。各域内以实现领域内的接口复用为目的，提供合适粒度的接口，与商业能力层确认概念模型。 商业能力团队应该首先是一个设计团队，其次才是一个实现团队。设计应该是和各域一起探讨的过程，商业能力要限制向下层过度延伸，也要迫使下层要更注重域内抽象。在设计过程中，**逻辑分解应该尽量形成在各域的独立逻辑，然后组合成对外的交互逻辑。**最外层交互所依赖的服务都在商业能力层实现封装，应该以业务设计结果为准，而不是技术设计，对外的扩展点，都在商业能力层定义和体现。

商业能力在软件结构上的分层

如果对外提供的就是商业能力，那么域和商业能力的边界到底在哪里？

• 所有在SDK、RPC接口中对外提供调用或者是SPI提供实现的，都在商业能力层定义。
• 也就是，需要提供给外部使用或扩展的，这里不包含界面层对后端的调用，界面是软件的一部分。
• 这里就要区分什么是内，什么是外？
  • 这个和我们定义的商业能力的服务对象有关系，如果按照组织来分，那就要考虑组织的边界和能力的分层，比如，业务平台面对业务方，业务平台就是内。
  • 如果考虑放大到所有提供中台能力的都和业务平台同等的地位，那么，整个中台就是内。但这样就要有整个中台的统一的对外组织和架构标准了。
  • 如果从企业内外来看，客户就是外，企业就是内。

商业能力和域的分层及域间关系 问题在于域间是否允许调用呢？如果允许，这样的域内调用和外部通过商业能力的调用差别是什么？对于依赖另一个域的实体对象信息的查询调用，都允许。对于依赖另一个域的判断的调用，或者嵌入另一个域的处理环节的调用，都禁止，交给上层去集成。也就是说，上层进行逻辑和控制结构的组装，不限制下层的信息查询，但限制下层的逻辑蔓延。 对于下层能够独立完成的判断逻辑，或者处理环节，鼓励下层去做。但对象必须有属主域，判断应该是本域的关键对象的行为判断，而不能是跨越边界。判断什么是查询，只有直接被认为是对象的直接属性的内容，被认为是查询，所以对于一个域要有基本的概念模型。

商业能力的表达 对组织边界外的外部系统服务，都是商业能力封装，对于和客户直接交互的提供给界面的都是商业能力。商业能力本身可以分成两类：一类是领域内服务，一类是跨域服务。跨域服务，可以作为独立的分类。从上下级关系看，上级的逻辑必然覆盖下层的逻辑，建立能力树，是给用户导航的方式。

基于企业架构，构建业务架构

要想构建业务平台架构，我们需要有一套行之有效的构建方法论。方法论的构成包括：原理过程+表示法+工具。 如下图所示，能力地图代表业务架构，概念模型代表信息架构。对于多数业务平台，一般技术架构都已经有较为明确的选择。所以，业务平台亟需构建的是除技术架构之外的泛“业务架构”。从企业管理维度上看，企业架构在业务平台通常可以解决的问题包括：

• 研发投资的价值识别
• 架构演进的组织方法
• 组织的职责划分

构建架构体系

战略-模式-能力-过程 业务架构的边界来源于战略输入。从能力的角度，产品目录是业务架构的延续；从实现的角度，产品目录是应用架构的延续。在交互层面，通过合适的集成手段，实现应用功能面向用户的有效整合。应用架构的边界和域的边界有内在的关联，可以通过自顶向下的讨论以及循环迭代完成演进。

构建能力地图

• 确定架构定义及结构描述
  • 分层划分的规则确定
• 现状描述
  • 能力地图的草稿初建
• 搜集关键场景，确定目标架构
  • 补充关键演进场景
• Gap分析
• 演进计划
• 构建一个基础的完备正交集合
• 构建不同场景的视图
  • 外部客户交付关键能力视图
  • 内部业务的热点关键能力视图

构建概念模型

• 现状搜集
  • 已经被广泛引用的概念、实体
  • 已经被广泛使用的术语
  • 已经被相对固化的流程节点
  • 已经广泛使用的场景
• 未来场景搜集
  • 战略输入
  • 业务规划
• 建模
  • 域划分
  • 模型定义
  • 耦合验证
• 演进计划