中台之上（六）：如何为一个商业银行设计业务架构？

从实际操作的角度讲，企业级业务架构设计及其建模过程是一个充满可能性和争议的过程，并没有一个直观的量化标准能够用于判断一个架构方案的好坏，我们可以通过一个虚拟的例子体会一下。

假定我们为 A 商业银行设计企业级业务架构，为了集中感受组件和标准化的过程，我们跳过战略分析，不导入更多目标，比较单纯地从简化的现状入手，推导可能的目标架构。

价值链设计

假定只分析存款和贷款这两个大家耳熟能详、无论做没做过银行系统都能基本了解的业务，并且假定产品只面向对公客户。首先派出我们的架构设计团队，设计团队的组成人员最好是具有丰富项目设计、实施经验的人员（能拉上开发人员更好），了解业务分析、数据分析、架构设计，由他们与业务人员（或者叫需求方）共同组成工作团队。团队搭好后，按照套路，既然做企业级，就先设计那一“横”——价值链，我们先暂定 A 行价值链由五个环节组成：产品设计、客户营销、运营管理、风险控制、统计分析五大环节，产品设计主要指金融产品上市前的设计过程，包括分析客户需求、开发系统、配置参数等；客户营销则包括客户信息管理、细分客户、销售产品、签订合约等；运营管理一般指需要后台集中处理的业务或者配送服务；风险控制是银行业务的重点领域，通常考虑各类风控模型的设计、风险视图的构建等；统计分析是指各类报表，包括业务报表、分析、监管报表等。这五个环节基本可以构成金融产品从设计到销售再到售后管理的完整过程。从这五部分的定义可以看出，价值链侧重于划定业务环节并分析环节包括的业务能力。由于是虚拟案例，我们只考虑前两个环节的简化分析，不对整个价值链做展开。

存款领域的模型设计

设计了价值链，我们就先开始分析存款领域。先来看下存款领域的“产品设计”环节，我们可以将这个过程起名为“设计上架产品”，定义为一个活动，其大致流程可以如下图：

图一 存款领域产品设计流程图

在这个活动中由三个角色：产品经理、IT 人员、业务人员；三个角色分别有三个任务：设计产品、实现产品、上架产品。产品经理负责分析产品需求，设计并运用产品模板为业务部门整理业务需求，并提交给 IT 人员去开发。这个岗位在不少银行的开发团队中是需求分析岗，但某宇宙行确实具有此类岗位。产品经理设计好产品模板之后交给开发团队，由于实现产品的过程是个复杂的开发过程，因此，在业务模型中可以用一个虚拟的任务代表。开发完成后，业务人员添加关于产品的基本信息、标签信息等，做上架前的最后配置，配置完成后就成为了一个待售产品，可以随时出售。这个活动中，我们主要关注产品需求、产品模板、待售产品这三个实体，前两个由任务“设计产品”创建，最后一个由任务“上架产品”创建。

之后，进入“客户营销”环节。营销中我们通常一定会遇到“获取新客户”、“维护老客户”、“存款”这三个活动，第一个活动当然是面向银行刚刚挖门子盗洞抢来的新客户，第二个活动则是已有的存量客户信息发生了变动，第三就是营销的目的了——拉存款。这三个活动简要情况如下：

图二 获取新客户、维护老客户、存款的简要流程

对公客户信息在银行，尤其是规模较大的银行中通常是由管户的客户经理负责录入，一般也无需审核，自己搞定。客户信息发生了变动自然要维护，比如联系信息。这两个活动都可以只包含一个任务，至于是否是分成两个活动，其实取决于建模习惯，当然，合并成一个活动就需要更改活动的定义和范围了，毕竟这两个活动中的任务都是在围绕同一个实体做文章，“录入客户信息”是创建“客户信息”实体，“维护客户信息”是变更“客户信息”实体。客户信息建好以后，就进入业务办理过程。客户到会计柜台去开立对公存款账户，开户是个麻烦的过程，要审一堆证件，不过这里我们略过这些内容，仅关注“开立账户”任务对“账户信息”实体的创建。完成账户开立后，就是存入存款了，其实客户无论是存活期还是存定期，都是跟银行建立了一个“存款合约”，代表了一种债权债务关系，而合约主要记录的要素其实来自我们在上一个环节中创建的“待售产品”。因此，“存入款项”这个任务读取了“待售产品”实体，将其实例化建立了“存款合约”、“账户变动”这两个实体，由于余额的变化，该任务还变更了“账户信息”实体。

以上这两个价值链环节的分析虽然简单，但也包括银行业务的基本过程：设计金融产品、营销客户、销售产品。由于是企业级设计，我们可以先不急着分析组件结构，可以再分析下贷款领域再做决定。

贷款领域的模型设计

先来看贷款领域的产品设计，其实，从产品设计的抽象流程来看，两者过程上并没有太大差别，从产品模型的角度，是产品结构和参数项的差别；而从开发视角，则是功能上的差异。因此，从业务模型的角度，二者在设计阶段可以共用一套模型：

图三 贷款产品设计流程

这实际上表示，当把开发过程剥离出去时，负责产品设计的组件可以是企业级的。

接下来进入“客户营销”环节，可以理解，“获取新客户”、“维护老客户”也是一样的过程，区别在于销售产品：

图四 获取新客户、维护老客户、贷款的简要流程

让客户签订贷款合约是我们的“终极目标”，但是贷款不同关于存款，客户要提供一定的保证，保证通常有抵押、质押、担保等形式，对公客户中，非常优质的客户也可以采用信用贷款的形式，不提供任何保证。本例我们假定是由其他客户为该客户提供了担保，在贷款合约之外签订了附属合约——担保合约，合约中记录了担保人信息、担保比例等。对公贷款通常是签订贷款合约之后再开立贷款账户，然后才是发放贷款。数据实体就不再一一介绍。

跨领域的标准化

如果不搞企业级，就是竖井式开发，那这样两套业务模型就可以分别使用了，各自构建一个业务系统；但是搞企业级，就需要一起分析了。

对于“产品设计”环节，我们之前已经分析了，可以放在一起，这样就可以有一个“产品管理”主题域，包含“产品需求”、“产品模板”、“待售产品”三个实体；处理这三个实体的是“设计产品”、“上架产品”这两个任务，后者可以聚合成“产品管理”组件。这样我们就根据数据关系的紧密程度将与之相连的任务设计成了组件，这个组件的定义和范围就是对这些任务和实体的概括性描述。按此类推，“客户营销”环节中“客户信息”实体可以构成“客户”主题域，而“录入客户信息”、“维护客户信息”则可以聚合成“客户信息管理”组件。再往下就到了相对复杂的业务部分，这里我们有两个问题要考虑，一是，担保合约中的担保人信息与客户信息非常类似，而且维护需求也类似，而且这种维护可能会不必要地造成担保合约的变化，因此可以考虑将其从担保合约中剥离，但是直接交给客户信息实体处理在概念上又不合适，因此，可以增加一个“角色信息”实体，专门记录客户在银行中不同业务领域可能承担的不同角色，但是这样原来的“客户信息”实体再叫客户信息也不太合适，所以我们可以在抽象程度上上升一格，将其改为“参与人信息”，这个实体应当是一个“客户”在银行有且仅有一个，并且是与业务无关的，其在各种业务中承担的角色由“角色信息”实体记录，这样也有利为“客户”构建更完整的全景视图。一个比较容易理解的比喻就相当于一个初创企业的领袖——董事长兼 CEO，这种情况下，人都是这一个人，但是有两个不同的身份、不同的职责，所以，把他本人定义为“参与人”，而把他担任的两个不同职务定义为“角色”，没准儿哪天他又兼任了 CTO，我们都可以很方便从他本人的信息出发，看到“角色”实体记录了哪些角色，而不用把董事长、CEO、CTO 的个人信息拿过来比较看是不是一个人。当然，这种抽象不是一层不变的，取决于实际需要和系统建设目标。优化后如下：

图五 优化后的获取新客户、维护老客户、贷款流程图

第二个问题是工作流的顺序，存款开户在前，签约在后，贷款则相反。从实际业务中考虑，首次开户时，开户和存入款项的顺序一定是开户在前，贷款实际上也是开户在前，涉及记账的放款在后；除去首次开户外，都是利用已有账户存钱或放款，并不需要考虑开户问题，因此，不考虑合约时，两个领域间的流程也是可以整合的。那么引入合约之后呢？其实这就遇到了企业级设计很常见的一类问题，涉及跨领域整合时，流程可以调整吗？这不是指建模能不能改，图上当然很容易，但是实际业务能不能改？愿不愿意改？有的时候大家会觉得，既然都决定做企业级了，那不是有了尚方宝剑了，实际工作还真未必，想想之前举的综合积分的例子，如果搞不定利益分配，企业级也不是那么容易做到。回到当前的例子，我们可以设想，把存款合约部分从“存入款项”任务中分离出来，考虑建立一个签订存款合约的任务，实际执行过程中其实客户还是无感的，毕竟无论开户在前还是签订存款合约在前，客户都是提交了申请之后就在柜台前边等着，是柜员在里边操作；那么对柜员而言呢？如果是账户开立在前，那就意味着不管客户存活期还是存定期，都是先审核开户资料，再选择存款产品。如果签订存款合约在前，那就是客户先选择存款产品，建立合约信息，如果系统发现客户没开户，那就弹出开立账户界面，或者存款签约界面中直接嵌入开立账户功能，如果客户没有账户，展开这项功能；如果有账户，这部分就不展开。也就是说，其实也可以调整流程，那么存款流程就跟贷款流程很类似了，具体的流程图我们就不再画了。

组件设计

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

这只是一种设计方式，也可以根据客户实际需要等其他因素变更设计。比如，将“存入款项”和“发放贷款”中的记账动作分离出来，增加一个“记录账务”的任务，这样“存入款项”和“发放贷款”将更加关注流程，也就是“交易”，而“记录账务”会更加关注记账，于是账户管理组件中就会变成“记录账务”、“开立账户”两个任务，而在合约管理组件中填入“存入款项”和“发放贷款”，延长了合约管理的范围；进一步，如果并不关注企业级合约管理，更关注的是产品级的合约管理，则可以将合约管理组件拆分成存款和贷款两个组件，存款组件下放入“签订存款合约”、“存入款项”，贷款组件下放入“签订贷款合约”、“发放贷款”两个任务。可见，根据关注点、设计思路的不同，架构设计也会有变化，并没有绝对的对错之分。此外，上述划分产生的组件，是不是也有“中台”的意思呢？我们可以清楚地看到一个用于今后中台沉降过程的起点。

总结

本节的例子是为了说明问题而虚拟的例子，实际业务场景比例子中复杂的多，但是通过这个简单的模拟，我们可以意识到：

1. 业务架构设计并没有简单的衡量标准；
2. 设计思路和关注点对架构方案有很直接的影响；
3. 架构设计需要迭代和反复，虽然我们不情愿，但是实际操作中是难免的；
4. 基于上一点，架构师经验很重要，可以减少反复，尤其是关键设计的反复。

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