企业级业务架构设计（2） 设计篇

企业级业务架构设计

设计篇

整体概述

业务架构是面向企业战略和企业整体的，而非仅处理单一需求。其一般实现过程包括设计和落地两个不断交替上升的过程。

设计过程为从企业战略分析出发，通过梳理企业目标，发掘能力需求，再通过价值链分析方式，构建企业整体能力布局（即业务架构），并在分析过程中，将能力需求放入能力布局中，并以此在业务层面落地战略、检验战略的可行性，甚至调整战略。

落地过程主要为通过业务架构驱动IT设计、协调实施过程，建立业务架构元素与IT设计元素之间的联系，并在实施中对业务架构进行基于实现的最终调整，以确保业务架构与IT实现之间的一致性。

优秀的业务架构实践不能仅单纯地停留在业务分析层面，也不能只满足于业务能力的组件化聚类，而是要时刻关注新技术、新业态的变化，适时引入新理念、新方向，使之具备与时俱进的能力。

“技术引领业务”并不是指由IT人员直接抛出新技术给业务人员去琢磨和研究，而是指将对新技术的理解首先通过业务架构设计引发业务变化，用新技术理念推动业务模式演变，再进行IT技术开发，这才是理想的“业务与技术融合”。

设计起点

企业战略分析

企业战略分析模型：该模型从企业愿景、使命这种相对宏观的概念入手，向下分解出可度量的目标

愿景、使命和目标这3部分作为“屋顶”，描述的是企业为自身发展所设定的目标和成功的标准，无法衡量的目标只能是个精神口号，不能转化为行动。

如果这三者出现偏差，就会出现“上梁不正下梁歪”的问题。务必要与企业的管理者沟通清楚，务必让所有参与方都达成一致共识，这是项目中最高层级的概念一致性，绝对不能出现偏差，以免“差之毫厘，谬以千里”。

不少技术人员不重视企业战略，认为企业战略与技术开发无关，这种想法大错特错。如果一个企业的战略使得员工觉得与自己无关，那么只能说明这个战略本身以及对战略的宣导是失败的。

不落实到流程中的战略是无法被执行的，而与战略落地无关的流程到底是在干什么呢？创造的是什么价值呢？为这样的流程开发的系统又是在干什么呢？

如果一个企业花费了几千万甚至上亿成本开发的业务系统，其设计人员连企业的战略都不知道，那么这个系统真的能够支持企业的发展吗？业务与技术的融合就更无从谈起了。

战略是为了完成上面提到的目标所需要采取的路线、方法，战略能力则是为了完成这一策略所需要的能力。

对标分析

很多人将对标分析的好处定位于快速学习领先实践，其实这种想法存在两个误区：

• 1 领先实践真的研究透了吗？

很多时候，即便请咨询公司出手相助，对领先实践的研究也多是表象研究，很难充分了解其机理，只看到了冰山一角。“水下部分”如果不在企业内部身临其境是很难充分感受的。简单化地学习领先实践，无异于照着别人的药方抓药给自己吃。

• 2 对标之前了解清楚自己了吗？

企业召开跨部门业务会议时，大部分时候讨论的不过是基于部门界限的协同，其实很多问题都上升不到需要寻求领先实践去学习的高度，而咨询项目启动时，企业通常也是才真正开始思考自己的问题到底是什么？

这种情况下，企业对自己的认知其实是有限的，很多问题并没有深入挖掘根本原因和产生环境，而这两点对于形成正确的对标分析结论却是非常重要的。

在企业战略设计方面切不可简单照搬、盲目引进，光在“别人家的事情”上下功夫，导致无效对标，甚至让对标分析“带偏”了自己。

组织结构影响

业务架构设计的着眼点是企业级能力规划，希望能够突破壁垒、形成合力。也正是因为这个“初心”，组织结构对业务架构设计的反作用力也是极大的。

项目团队的组织结构中的优点和缺点都将不可避免地反映在他们制作的系统中(康威定律)。

作为业务架构的设计者，拿出来的方案最好是以一种更有效的方式来满足所有相关方的需求，而不是单纯做抽象、归并，要各部门“你让一陇地，他少一棵树”的方式搞折中，这样做实际上就失去了做企业级的核心价值，因为这样的折中既无法保证系统的先进性，也无法保证用户体验，甚至还可能发生退步。

部门利益是做企业级的最大障碍，跨越这个障碍是对业务架构师设计能力的最高挑战。当然，客观地说，没有更好的解决方案时，不动也是一种选择，因为，同样接受这个挑战的还有企业文化（银行综合积分系统的例子中，积分别后的博弈是营销费用分分配）。

即便设计好了上层的业务架构方案，也未必能够实现。

项目经理、业务经理、技术经理这些角色甚至会成为职业开会人。如果会议效率难以保证，一个问题久拖不决，就会产生两种结果：一是项目组担心工期延误直接改变架构方案；二是采用非正式沟通方式，项目组间通过私下交流解决问题，而后者也极有可能是以改变架构方案为代价的。

一个在组织结构上高度部门化的企业是很难建成一个真正的企业级业务系统的，这一点在做业务架构设计时务必要提前考虑到，方案与组织结构要匹配，否则在落地时很可能会困难重重、面目全非。

企业级建设是一个“砸烟囱”的过程，其实无论你砸得多卖力，“烟囱”总还是会有的，对于企业级设计来讲，这是实践者必须面对的问题。

业务架构设计过程

开垂直的业务分析之前，必须先确立一个统一的分析框作为观察各个业务线的统一方法，这样才能将企业需要的业务能力进行分类汇集，从而产生合理的业务架构。

价值链分析

管理学上分析企业竞争力通常多使用价值链模型，而这个久经考验的管理方法也很适合用来做横向的企业级分析。

波特价值链：

价值链主要包括基本活动和支持性活动，基本活动是指主要生产过程，支持性活动则是指对基本活动起辅助作用及维持企业基本运转的各类活动。实际使用中不必完全一模一样地进行照搬，因为波特价值链一看就知道其偏重于制造业，偏重于生产类型的企业，对于服务业而言就需要进行适当的变形。

价值链主要描述的是企业价值的创造过程，引入价值链分析主要是为企业横向审视自身的业务能力提供分析框架。因此，价值链如何设计完全可以是个性化的，只要确认能够符合企业的特点，覆盖其价值创造过程即可。

行为分析

搭建好价值链这一“横轴”之后，就可以基于价值链的各个环节分析多个“竖轴”了。

• 划分业务领域：取决于企业的战略和价值定位，也就是打算为哪种类型的客户提供哪种类型的服务或产品
  划分领域其实包含了两种方式，从客户出发和从产品出发，选择哪一种，需要根据企业的特点以及企业更关注什么来决定。

• 分析业务流程：将一个业务领域中的所有业务处理过程按照价值链约定的范围进行分解，形成每一个价值链环节中的一个或者多个工作流。
  一个业务领域实际上就是由一组业务活动构成的，业务活动中的角色和任务，体现了所有参与到价值创造过程中的组织单元的分工协作关系。

这一阶段完成的模型通常是不够准确的，因为还没有经过“精炼”的过程，其对企业级设计的贡献还只是个开始。

数据分析

软件设计主要研究的是行为和数据，流程模型分析了行为，数据模型当然就是要分析数据了。

我们做ER图通常是面向单个系统进行构建的，而在构建企业级数据模型时，就需要横向分析所有业务领域的ER图，所以，我们需要以一种总体结构首先建立分析框架。

比如金融类企业常用的FSDM：它是IBM的一个企业级数据模型，囊括了银行约80%的业务数据

作为企业级模型，数据实体和属性都要保证唯一，建模阶段要做到这一点并不难，但是业务架构的重点在于生产阶段的管控，而非建模阶段。

生产阶段要通过数据管控平台或工具对数据字典进行严格管理，未进入数据字典的数据项，将无法生成企业唯一的数据项ID，无法在设计时被使用。

企业级数据模型说起来容易，做起来难，首先要对业务数据进行全面建模，再对生产进行严格管理，并对历史数据进行处理。

组件分析

流程模型与数据模型是描述业务的一对“难兄难弟”，流程模型表达的是“处理”，数据模型表达的是“输入”和“输出”，合起来就是计算机的基本工作流。

如果将该业务系统化，就会变成如下的问题：实现业务活动的计算机程序是在什么样的场景（事件）下开始执行的，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织、角色）执行，执行之后将会产生哪些数据（实体）。

在软件设计上，通常会考虑将关系较近的数据实体聚合在一起，按照行为接近数据的原则，再将相应的功能聚合成一个组件。从业务模型的角度来看，就是按照主题域划分边界，将与主题域内实体相关的任务聚在一起构成业务组件。

聚类过程中需要注意：不同主题域实体采用引用关系，对一个数据实现写操作智能归属一个组件

业务架构的整体逻辑关系

业务架构的设计包括：价值链、业务领域、业务流程（即活动、任务、角色）、业务数据和业务组件5个关键元素

价值链代表了构建企业能力统一视图的“横向”结构，每个价值链环节中均包含了若干个业务流程；业务领域代表了构建企业能力统一视图的“纵向”结构，描述了各类业务流程应如何通过组合实现领域级的业务目标。

业务流程即业务活动，业务活动是由不同角色分别完成的若干任务组成的，任务执行过程中其必然与业务数据发生联系。数据主题域可以将关系紧密的数据进行聚类，再将与数据关系紧密的行为（也就是任务聚类），形成包含行为和数据的业务组件，组件代表了企业的某一类业务能力。

从下往上看，业务组件中业务能力通过任务与活动的关系、活动与领域的关系，表达了对业务领域的支持，这就开放了企业在每个价值链环节中的所有能力。

企业级业务架构整体逻辑图：

对任务边界进行长期的企业级打磨，最终会使组件能力的内聚性增强，职责更集约，从而能够更好地封闭变化，开放调用。对于企业级设计而言，数据在组件间是可以根据需要自由流动的。当然，这种流动也是建立在企业级数据模型对数据的统一定义的基础上的。

业务架构设计难点

企业级业务模型的建设离不开标准化过程，因为做企业级模型需要横向对比分析企业的所有业务领域，以期在设计上实现“以更少支持更多”，这是大多数企业级系统建设或者企业级转型工程的目标，希望能够同时实现快速的灵活响应和减少重复开发这两个目标。

基本标准化方法

业务架构模型的标准化包括数据标准化和任务标准化两个部分。

• 数据标准化：最重要的标准化，需要通过与流程模型的配合，从语义层面逐一澄清
• 任务标准化：实际很难操作，因为缺乏严格的标准来做判断

任务标准化的基本过程：1 将流程模型与数据模型进行语义对接；2 分析重复的业务动作；3 做出关于标准化的建模判断；

避免过度整合

过度整合情况通常会出现在流程看似相近的业务领域，以及一个领域内部的多个产品之间，后者更难判断。
一个业务领域内部的流程本就相近，会很容易让人产生“整合”的冲动，而且业务建模毕竟是一种“纸上操作”，分、合都是很容易的，调整下结构而已，同时整合对建模者来讲又有很大的吸引力。

为了避免这种错误，我们需要从业务和数据两方面下手，配合检查。

业务上自然是要重新审视、理清业务流程，搞清楚具体差异；而数据上则要重新检视数据实体划分的颗粒度是否正确，是否因为包含的属性太多而导致内聚性不够。

流程模型与数据模型之间的语义互查是进行合理标准化的关键，同时这也是一个反复锤炼的过程。

融合

业务人员与技术人员融合得越好，就越能产生高质量的模型和系统。
国外金融机构技术人员占比一般不足8%，国内通常为4%左右，目前似乎也可以说，除了科技企业，其他行业中还很少有哪个企业真的达到了与信息时代、数字化时代相称的人员结构。

尽管标准化的过程很痛苦、自身又似乎很不“标准”，但是因其对企业级业务系统的构建意义非凡。尽管这一过程未免有点“纸上谈兵”，但它的优势也正是在这里。这一阶段的任何调整其代价都是极低的，而不合理的设计一旦传导到开发上，就将产生高昂的纠错成本。

对于大型复杂系统而言，因其面对的问题域异常庞大，所以需要一套清晰的业务与IT的架构映射关系指导企业的持续建设，这就如同人们对地图的需求一样，只有践行标准化才能提供一张准确的地图。

商业银行业务架构设计

价值链设计

假定只分析存款和贷款这两项读者耳熟能详、无论做没做过银行系统都能基本了解的业务，并且假定产品只面向对公客户。

先暂定A行的价值链由5个环节组成：产品设计、客户营销、运营管理、风险控制、统计分析。

• 产品设计：主要是指金融产品上市前的设计过程，包括分析客户需求、开发系统、配置参数等
• 客户营销:：包括客户信息管理、细分客户、销售产品、签订合约等
• 运营管理：一般是指需要后台集中处理的业务或者配送服务
• 风险控制：银行业务的重点领域，通常需要考虑各类风控模型的设计、风险视图的构建等
• 统计分析：是指各类报表，包括业务报表、分析、监管报表等

这5大环节基本上可以构成金融产品从设计到销售再到售后管理的完整过程。从这5部分的定义可以看出，价值链侧重于划定业务环节，并分析环节所包含的业务能力。

存款领域模型设计

存款领域的“产品设计”环节可以先定义一个活动，称为“设计上架产品”

【产品设计环节】
在这个活动中共包含3个角色：产品经理、IT人员、业务人员；这3个角色分别需要执行3项任务：设计产品、实现产品、上架产品。

产品经理负责分析产品需求，设计并运用产品模板为业务部门整理业务需求，并提交给IT人员进行开发。这个岗位在不少银行的开发团队中其实是需求分析岗位，但某银行确实具有此类岗位。

产品经理设计好产品模板之后交给开发团队，由于实现产品的过程非常复杂，因此，在业务模型中可以用一个虚拟的任务来代表。

开发完成后，业务人员添加关于产品的基本信息、标签信息等，做上架前的最后配置，配置完成后该产品就成为一个待售产品，可以随时出售。

这个活动中，我们主要关注产品需求、产品模板、待售产品这3个实体，前2个由任务“设计产品”创建，最后1个由任务“上架产品”创建。

【客户营销环节】
营销中我们通常会遇到“获取新客户”“维护老客户”“存款”这3个活动。第1个活动当然是面向银行刚刚招揽来的新客户，第2个活动则是已有的存量客户信息发生了变动，第3个活动就是营销的目的了——拉存款。

对公客户信息在银行，尤其是规模较大的银行中通常是由管理客户的客户经理负责录入，一般来说是无须审核。

客户信息发生了变动自然要维护，比如联系信息。这两个活动都可以只包含一个任务，至于是否分成两个活动，则要取决于建模习惯。

客户信息建好以后，即可进入业务办理过程。客户到会计柜台去开立对公存款账户，开户是一个麻烦的过程，要审核许多证件，此处省略。

完成账户开立之后，就是存入存款了，无论客户是存活期还是存定期，都是与银行建立了一个“存款合约”，代表了一种债权债务关系，而合约主要记录的要素其实来自于我们在上一个环节中创建的“待售产品”。

因此，“存入款项”这个任务读取了“待售产品”实体，将其实例化建立了“存款合约”“账户变动”这两个实体，由于余额的变化，该任务还变更了“账户信息”实体。

贷款领域模型设计

【产品设计环节】
从产品设计的抽象流程来看，存款与贷款这两个领域在产品设计过程上并没有太大的差别，只是产品结构、参数项和功能上的差异。因此，从业务模型的角度，二者在设计阶段可以共用一套模型。

【客户营销环节】
其中“获取新客户”“维护老客户”与存款领域的过程是一样的，区别在于销售产品上。

让客户签订贷款合约是我们的“终极目标”，但是贷款不同于存款，客户要提供一定的保证，保证通常包含抵押、质押、担保等形式，对公客户中，非常优质的客户也可以采用信用贷款的形式，而不用提供任何保证。

本例中我们假定是由其他客户为该客户提供了担保，在贷款合约之外签订了附属合约——担保合约，合约中记录了担保人信息、担保比例等。对公贷款通常是签订贷款合约之后再开立贷款账户，然后才是发放贷款。

跨领域的标准化

【产品设计环节的标准化与组件分析】

对于“产品设计”环节，我们之前已经分析过了，可以放在一起，这样就有了一个“产品管理”主题域，其包含“产品需求”“产品模板”“待售产品”3个实体；处理这3个实体的是“设计产品”“上架产品”这2个任务，后者可以聚合成“产品管理”组件。

这样我们就可以根据数据关系的紧密程度将与之相连的任务设计成组件，这个组件的定义和范围就是对这些任务和实体的概括。

【客户营销环节的标准化与组件分析】
“客户营销”环节中，“客户信息”实体可以构成“客户”主题域，而“录入客户信息”“维护客户信息”则可以聚合成“客户信息管理”组件，但是事情并没有这么简单，下面我们开始进行贷款和存款领域主要差异的分析。

• 担保合约带来的差异：担保合约中的担保人信息与客户信息非常类似，但是直接交给客户信息实体处理在概念上又不合适，这里需要增加一个“角色信息”实体，专门用于记录客户在银行中不同业务领域可能承担的不同角色。

但是这样做的话，原来的“客户信息”实体再称为客户信息就有些不太合适了，所以我们可以在抽象程度上上升一格，将其改为“参与人信息”。

• 工作流带来的差异：在工作流的顺序中，存款开户在前，签约在后，贷款则相反。

从实际业务中考虑，首次开户时，开户和存入款项的顺序一定是开户在前，贷款实际上也是开户在前，涉及记账的放款在后；除去首次开户之外，存款和贷款都是利用已有的账户存钱或放款，而不需要考虑开户的问题。因此，不考虑合约时，两个领域间的流程也是可以整合的。

那么引入合约之后呢？其实这就遇到了企业级设计中很常见的一类问题，涉及跨领域整合时，流程可以进行调整吗？这个问题不是指建模能不能更改，在图上更改当然很容易；而是指实际业务能不能更改？愿不愿意更改？

我们可以设想，将存款合约部分从“存入款项”任务中分离出来，考虑建立一个签订存款合约的任务。实际执行过程中，客户对这点变动其实是无感的，毕竟无论是开户在前还是签订存款合约在前，客户都是提交了申请之后就在柜台前等待，是柜员在进行一系列的操作。

那么对于柜员而言呢？如果是账户开立在前，那就意味着不管客户存活期还是存定期，都是先审核开户资料，再选择存款产品。如果签订存款合约在前，那么就是客户先选择存款产品，建立合约信息。

如果系统发现客户尚未开户，则会弹出开立账户的界面；或者在存款签约界面中直接嵌入开立账户的功能，如果客户没有账户，则展开这项功能；如果有账户，这部分就不展开。也就是说，其实是可以调整流程的

组件设计

根据上述过程描述，我们可以将数据实体“贷款合约”“存款合约”“担保合约”都放在“合约”主题域下，而将与之相关的“签订存款合约”“签订贷款合约”任务聚合成“合约管理”组件；将数据实体“账户信息”“账户变动”放在“账户”主题域下，而将与之相关的“开立账户”“存入款项”“发放贷款”任务聚合成“账户管理”组件。

这只是一种设计方式，我们也可以根据客户实际需要等其他因素变更设计。

比如，将“存入款项”和“发放贷款”中的记账动作分离出来，增加一个“记录账务”的任务，这样“存入款项”和“发放贷款”将更加关注流程，也就是“交易”，而“记录账务”则会更加关注记账。

于是账户管理组件中就会变成“记录账务”“开立账户”2个任务，而在合约管理组件中填入“存入款项”和“发放贷款”2项，这样做就延长了合约管理的范围。

更进一步地，如果并不关注企业级合约管理，更关注的是产品级的合约管理，则可以将合约管理组件拆分成存款和贷款2个组件，存款组件下放入“签订存款合约”“存入款项”2个任务，贷款组件下放入“签订贷款合约”“发放贷款”2个任务。

根据关注点、设计思路的不同，架构设计也会发生变化，并没有绝对的对错之分。

小结

企业唯一的价值链结构：产品设计、客户营销、运营管理、风险控制、统计分析。
依据价值链展开的2个垂直业务领域：存款、贷款。

在2个垂直业务领域中共用的3个业务活动：设计上架产品、获取新客户、维护老客户。
在2个垂直业务领域中共用的5个任务：设计产品、上架产品、录入客户信息、维护客户信息、开立账户。

基于数据主题域聚类任务后构成的面向各垂直业务领域开放自身能力的4个企业级业务组件：产品管理、客户管理、合约管理、账户管理。其中，产品管理处于价值链环节“产品设计”之下，其余则位于价值链环节“客户营销”。

架构设计是一个不断精炼和确认的过程，上文提到的过程对于业务人员而言并不难理解，因此，需要架构人员、技术人员在设计过程中努力“培养”客户，创造一个深度融合的机会。而且上述设计思路对于业务人员日常分析自己的工作环境、设计工作方案、改进工作流程都有帮助，是一种可以跨越IT边界的工作方法。对于这一过程的投入，业务与技术是双赢的。

• 业务架构设计并没有简单的衡量标准
• 设计思路和关注点对架构方案有很直接的影响
• 架构设计需要反复进行迭代，虽然这不是我们所情愿的，但是实际操作中这是不可避免的
• 架构师的经验很重要，可以减少反复次数，尤其是关键设计的反复迭代