业务架构-设计过程

概述

分析完企业战略、组织结构，是不是就该进入业务流程分析了呢？先别急，业务流程分析，特别是对于具有多条不同业务线的企业而言，是一种垂直式的分析。如果直接开始进行业务流程分析，那就走上了竖井式开发的老路，就算拥有共同的战略目标，也未必能够建得出企业级的业务架构和业务系统来。业务架构强调的是整体性，需要有横向视角通观整个企业的生产过程，因此，展开垂直的业务分析之前，必须先确立一个统一的分析框作为观察各个业务线的统一方法，这样才能将企业需要的业务能力进行分类汇集，从而产生合理的业务架构。

价值链分析

管理学上分析企业竞争力通常多使用价值链模型，而这个久经考验的管理方法也很适合用来做横向的企业级分析。
价值链（Value Chain）的概念首先由迈克尔·波特（Michael E.Porter）于1985年提出。最初，波特所定义的价值链主要是针对垂直一体化公司提出的，强调的是单个企业的竞争优势。随着国际外包业务的开展，波特于1998年进一步提出了价值体系（Value System）的概念，将研究视角扩展到不同的公司之间，这与后来出现的全球价值链（Global Value Chain）的概念有一定的共通之处。之后，寇伽特（Kogut）也提出了价值链的概念，相比较于波特的观点，寇伽特的观点更能反映价值链的垂直分离和全球空间再配置之间的关系。
2001年，格里芬在分析全球范围内国际分工与产业联系问题时，提出了全球价值链的概念。全球价值链的概念提供了一种基于网络、用于分析国际性生产的地理和组织特征的分析方法，揭示了全球产业的动态性特征。具体采用哪一种价值链模型，需要根据企业的实际需要来确定，比如，是否更关注上下游的关系等。这种模型的建立往往不是企业自身就能简单确定的，可能还需要一定的咨询或者学习过程。波特价值链如下图所示。

价值链主要包括基本活动和支持性活动，基本活动是指主要生产过程，支持性活动则是指对基本活动起辅助作用及维持企业基本运转的各类活动。实际使用中不必完全一模一样地进行照搬，因为波特价值链一看就知道其偏重于制造业，偏重于生产类型的企业，对于服务业而言就需要进行适当的变形。
其实，价值链主要描述的是企业价值的创造过程，引入价值链分析主要是为企业横向审视自身的业务能力提供分析框架。因此，价值链如何设计完全可以是个性化的，只要确认能够符合企业的特点，覆盖其价值创造过程即可。比如，极度简化的价值链设计，也可以将支持性活动整合后并入到基本活动中，形成只有一个维度的价值链。

行为分析：业务领域和业务流程

1.划分业务领域

搭建好价值链这一“横轴”之后，就可以基于价值链的各个环节分析多个“竖轴”了。科学地讲，业务领域的划分取决于企业的战略和价值定位，也就是打算为哪种类型的客户提供哪种类型的服务或产品，比如，银行为个人客户提供金融服务，这就产生了个人金融业务线，其中会包含存款、贷款、金融市场、非金融服务等各种具体业务。而如果觉得这样划分依然是粒度太粗，那么很有可能就会将私人银行这类高端客户服务独立出来，为其设计的一些特殊业务功能可能不会为普通客户提供服务。
划分领域其实包含了两种方式，从客户出发和从产品出发，选择哪一种，需要根据企业的特点以及企业更关注什么来决定。还以银行业为例，银行业有不少产品是同时适用于个人客户和企业客户的，因此，从客户出发，很多产品会有交叉；而从产品出发，则会避免这一问题，毕竟业务系统的设计大多数还是以产品为主线的。但是需要注意的是，这里指的不是具体的某一个产品，而是一组同类产品的集合，比如存款、贷款、托管、资管、投行等，而不是活期存款、定期存款、通知存款这种更细的产品维度。选好维度之后，就有了横轴（价值链）和纵轴（业务领域）两个维度，接下来就可以开始分析业务流程了。

2.分析业务流程

业务流程的分析实际上是将一个业务领域中的所有业务处理过程按照价值链约定的范围进行分解，形成每一个价值链环节中的一个或者多个工作流。具体每一个工作流程的设计可以采用常见的VISIO设计工具，既可以遵循BPMN语法标准，也可以采用其他制作工作流的语法标准。但是需注意的是，整个企业必须统一采用一种语法标准，否则将会无法进行企业级整合。
以BPMN语法为例，一个工作流在BPMN语法中称为一个活动，每个活动都可能会有多个不同的角色共同参与，具体会涉及哪些角色就又会涉及企业的组织结构了。每个角色在活动中承担的职责称为任务，其实工作流的分析重点在任务上，活动的范围并不是那么严格，甚至不是非常重要的，在BPMN语法中，活动之间是可以靠事件串接起来的。既然能够串接在一起，那么范围（或者说流程图的长度）就不是特别重要了。我们甚至可以将一个业务领域中不同价值链环节下的所有活动都连接成一个特别复杂的活动，只不过这样做可读性会非常差。
所以，在操作上，还是建议活动尽可能限制在每个价值链的范围之内，而每个价值链内包含多少个活动则可以自由一些，可参照对业务场景的需要进行划分。业务流程的分析重点在任务上，因为任务在后续的设计中对功能、业务组件内部结构的影响比较大，关于这点后文还会进行详细介绍。一个常见的BPMN工作流如下图所示。

3.小结

业务领域其实是企业确定以某类产品服务某类客户的一个业务范围，在建模上，其表现为：为实现这一价值定位，企业在整个价值链上的各种业务活动的有机结合。一个业务领域实际上就是由一组业务活动构成的，业务活动中的角色和任务，体现了所有参与到价值创造过程中的组织单元的分工协作关系。
需要注意的是，这一阶段完成的模型通常是不够准确的，因为还没有经过“精炼”的过程，其对企业级设计的贡献还只是个开始。在对业务领域及流程的分析中，还需要强调的一点是，别在忙于细节时忘了大方向。业务架构设计是从企业战略开始的，分析到业务领域这一层级时，要将战略分析过程中梳理出的能力需求落实到工作流中，要时刻提醒自己，业务领域内的活动是否能够有力地支持战略的实现，是否能够有效地服务客户，是否能够有效地应对行业竞争，也就是先进性的衡量。将这三个问题如同曾子三问一样来看待，“日叁省乎己，则知明而行无过矣”。

数据分析

软件设计主要研究的是行为和数据，流程模型分析了行为，数据模型当然就是要分析数据了。数据模型在很多系统分析、软件工程的教材上都有介绍，所以笔者在此不再赘述三范式之类的数据建模规则，而是重点讲述企业级数据模型。
提起数据模型，技术类读者的第一反应可能就是ER（实体关系）图，实体关系图是我们做关系型数据库设计的基础。实体关系图是按照对业务对象的划分，将数据属性按照实体聚类，并描述实体间的关系，从而指导程序设计和数据库设计。
我们做ER图通常是面向单个系统进行构建的，而在构建企业级数据模型时，就需要横向分析所有业务领域的ER图，所以，我们需要以一种总体结构首先建立分析框架，比如金融类企业常用的FSDM（Financial Services Data Model），它是IBM的一个企业级数据模型，囊括了银行约80%的业务数据。FSDM将数据分为九大类，分别是关系人、合约、条件、产品、地点、分类、业务方向、事件、资源项目，具体定义如下表所示。

FSDM九大领域简介

分类名称	简称	定义
关系人	IP	银行各项业务开展过程中的相关各方，个人、机构、柜员
合约	AR	参与者之间达成的合约、合同、协议等
条件	CD	描述银行的业务正常开展所需要的前提条件、资格标准和要求
产品	PD	产品是为客户提供的、以换取利润的产品和服务，产品也包括合作伙伴或竞争对手的产品和服务，是金融机构销售或提供的可市场化的产品、组合产品和服务
地点	LO	参与人相关的所有地址，如家庭地址、公司地址、邮政信箱、电话号码、电子地址、网址等或地理位置区域
分类	CL	适用于其他数据概念的分类或分组（类似元数据的概念）
业务方向	BD	银行或参与人开展业务所在的环境和方式
事件	EV	指参与人和银行的交互，以及银行内部的业务交互，它包含最详细的行为和交易数据，例如存款、提款、付款、信用/借记卡年费、利息和费用、投诉、查询、网上交易等
资源项目	RI	指银行有形或无形的有价值的资源项目，是银行拥有，管理、使用的，或支持特定业务目的的资源项目

这个框架可以将数据实体、数据属性进行归类，形成统一的企业级逻辑模型。作为企业级模型，数据实体和属性都要保证唯一，做到这一点在建模中并不难，通过工具筛查就可以比较出名称、定义、取值重复的数据项，从而保证数据的唯一性。但是业务架构的重点在于生产阶段的管控，而非建模阶段。
生产阶段要通过数据管控平台或工具对数据字典进行严格管理，未进入数据字典的数据项，将无法生成企业唯一的数据项ID，无法在设计时被使用，从而达到“严防死守”一般的控制。这种对数据字典进行严格管理的方法虽然有点儿死板，但确实很有效。企业级数据模型说起来容易，做起来难，首先要对业务数据进行全面建模，再对生产进行严格管理，并对历史数据进行处理。

组件分析：行为与数据的结合

流程模型与数据模型是描述业务的一对“难兄难弟”，流程模型表达的是“处理”，数据模型表达的是“输入”和“输出”，合起来就是计算机的基本工作流，这在大部分软件设计方法论中都是共识。数据模型和流程模型的组合，可以清楚地描述出，什么样的事件或条件可以触发一组业务活动，业务活动需要的输入有哪些，业务流程的处理规则是什么，经过业务流程的处理，输出又有哪些。
如果将该业务系统化，就会变成如下的问题：实现业务活动的计算机程序是在什么样的场景（事件）下开始执行的，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织、角色）执行，执行之后将会产生哪些数据（实体）。任务会直接处理数据，而这种处理通常可分为增加、修改、删除、查询四类操作。

一个业务领域是由一组活动构成的，而这些活动又是分布在价值链的不同环节中。如果粗糙地划分业务组件，则将每一个价值链环节设为一个业务组件也未尝不可，不过这样做未免有些“偷懒”了。对于业务复杂的大型企业而言，组件的内聚性一般都很差，所以我们需要进行更为精细的划分。数据模型包含主题域这个层级，即将关系较近的数据实体聚合成一个分类，对于这种关系我们可以给出一个主题名称。比如，当按照产品划分主题时，FSDM中的产品分类下就可以建立一个“存款”主题域，将存款业务相关的数据实体放入其中，并使用ER图的方式进行表达。

在软件设计上，通常会考虑将关系较近的数据实体聚合在一起，按照行为接近数据的原则，再将相应的功能聚合成一个组件。从业务模型的角度来看，就是按照主题域划分边界，将与主题域内实体相关的任务聚在一起构成业务组件。聚类过程中需要注意如下几点事项。
第一，数据关系中存在一个主题域引用另一个主题域的数据实体的情况。比如A主题域引用了B主题域的数据实体，在对A主题域进行任务聚类时，不会考虑将B主题域中被引用的数据实体相关的任务聚类进来，因为它们应当由B主题域进行聚类时考虑将其聚合起来，这样做可以保证在企业级业务系统中，数据生成职责的唯一性，这是应用企业级数据模型时非常重要的一点。
第二，与数据实体相关的任务主要是指对数据实体进行新增、修改、删除的任务，对同一数据实体进行新增、修改、删除操作的任务应当归属于同一组件，这也是一个标准化的过程。只有这些任务具有数据的写权限，而其他任务只具有读权限，这也是保证企业级数据一致性的重要措施。实际设计中也会出现必须要建立主副本的情况，这时，主本数据是主要设计方，副本数据的设计方必须考虑如何保持与主本数据的一致性。

上述原则将在一定程度上影响任务边界的划分，因为在任务中要表达对不同主题域数据实体的写操作，因此就需要将任务切分开，或者也可以直接复用其他组件中已有的对该数据实体进行写操作的任务。表达上，当然是切分开或复用任务最好，甚至还可以复用活动，但是在实际建模过程中则要具体问题具体分析了，这一方面是建模的问题，但另一方面其实也是应用模型过程中很重要的一个环节——解读模型的问题，如果两者比较统一，那么模型具体长成什么样子就不必太纠结了。所以，到底应该如何处理，应同时取决于这两方面的情况，需要考虑的是“通用语言”是否真的建立了。

熟悉DDD的读者可能会问，任务与实体的关联主要是基于对实体的增、删、改操作，这是不是有点“贫血模型”的意味？其实不然，流程对数据的更丰富的处理规则可以包含在任务的描述中，因此这绝不是一个“贫血模型”。此外，IBM公司的CBM理论对研究业务组件的划分也是很有指导意义的。虽然本书介绍的方法与之有所不同，但是目标毕竟是一致的，思想上也可以称为“同源”，建议读者自行阅读研究。
企业级数据模型与企业级流程模型相互支持，而其中最重要的概念都是企业级。企业级在操作层面上，说到底是一个标准化问题。

业务架构的整体逻辑关系

回顾前面几节的内容，业务架构的设计包括：价值链、业务领域、业务流程（即活动、任务、角色）、业务数据和业务组件5个关键元素。
价值链代表了构建企业能力统一视图的“横向”结构，每个价值链环节中均包含了若干个业务流程；业务领域代表了构建企业能力统一视图的“纵向”结构，描述了各类业务流程应如何通过组合实现领域级的业务目标。
业务流程即业务活动，业务活动是由不同角色分别完成的若干任务组成的，任务执行过程中其必然与业务数据发生联系。数据主题域可以将关系紧密的数据进行聚类，再将与数据关系紧密的行为（也就是任务聚类），形成包含行为和数据的业务组件，组件代表了企业的某一类业务能力。
从下往上看，业务组件中业务能力通过任务与活动的关系、活动与领域的关系，表达了对业务领域的支持，这就开放了企业在每个价值链环节中的所有能力。
以上是企业级业务架构的整体逻辑，上述内容可以用下图表示。

如果能在设计及后续迭代过程中多注意对任务的企业级分析和对组件能力的开放共享，避免因组件能力与主要应用部门间的关系产生对其他应用的自然壁垒，可以支持不同领域的不同活动对同一任务的自由复用，也就是常说的企业级能力复用。尽管本书之前的分析其实一直在尽量避免出现活动层面跨价值链环节的复用，但是这并不是代表排斥这种情况的出现，一切还应视实际需要而定。
对任务边界进行长期的企业级打磨，最终会使组件能力的内聚性增强，职责更集约，从而能够更好地封闭变化，开放调用。对于企业级设计而言，数据在组件间是可以根据需要自由流动的。当然，这种流动也是建立在企业级数据模型对数据的统一定义的基础上的。组件不能成为过去竖井式开发的“子系统”，互不“买账”，互联互通才是企业级的特征。