【CSDN 编者按】数字化转型是金融科技发展的未来所向，实现金融数字化转型的底座则是智能技术平台和数字业务平台。由于没有标准答案，数字化的平台建设中存在诸多解决方案，其中不乏成功案例，但更多则是事倍功半的错误解法。

《新程序员 005：开源深度指南&新金融背后的技术力量》特邀Thoughtworks架构师黄雨青，第四范式架构师钱平通过长期实践经验，找出了制约数字化平台的四大痛点，在此基础上寻迹数字化平台建设的正确打开姿势。

作者 | 黄雨青、钱平       责编 | 张红月

出品 | 《新程序员》编辑部

数字化转型是现今最主要的趋势之一，金融行业亦是如此。“十四五规划”指出并要求金融业稳妥发展金融科技，加快金融机构数字化转型。

然而，金融行业业务本身具备产品种类多、业务条线多、客群类型多等特点，在这样业务复杂多变的背景中，我们该如何提升科技的业务响应力，从而持续加快向客户提供新产品和服务的速度？这个问题是金融企业的科技团队在数字化转型中面临的必答题。

 

 

对于这个问题，“构建数字化平台”往往是很多金融企业科技部门给出的“标准答案”，甚至被期待可以像生产线一样，支撑起企业80%的核心业务。同时它要具备一定弹性，当生产工序变化时，能够快速调整从而应对这些变化。

在诸多数字化转型框架以及评估体系中，平台化都是核心的能力支柱，其中包括智能技术基础平台和数字业务平台，从而形成企业数字化转型的坚实底座。

当然，数字化平台的构建没有“标准答案”，该从何入手建设数字化平台，行业内存在着不同解析。在我们的过往经验中，就见过很多事倍功半的错误解法。

本文节选自《新程序员 005：开源深度指南&新金融背后的技术力量》，本期杂志将开源开发者最关注的核心开发者与技术栈，以及与企业最关心的开源行业化应用以及商业化前景、治理风险等问题进行深度解析。

与此同时，还将围绕“新金融背后的科技力量”带来最前沿的观点、实践案例与技术剖析！小伙伴可扫码下方二维码提前预定！

三种事倍功半的误区

一些平台的建设起始点基于更高的理念：达成最佳实践。因而投入大量的人力和物力，然而结果却往往不尽人意。以下是三种常见的“事倍功半”的数字化平台建设方式。

科技自驱

科技自驱的平台架构方式指导思想是这样的：从建设技术平台底座开始，遵照同业实践和趋势进行技术能力储备，尽量人有我有。这样一来，当未来有具体业务需求，技术团队就能很快“祭出”相关的武器来应对。同时，拥有这样一个技术底座能彰显自身科技能力的“先进性”，这是好的方面。

但与此同时，这样的思维也有误区：对实现域进行堆砌，却没有思考上层的解决方案以及业务侧需要解决的根本问题。结果往往是，武器库里堆积了很多枪支后才发现真正的敌人其实在海上。

借鉴同业

既然“苦练内功”成效来得慢，那就瞄准业务需求直接“拿来即用”。这类思维会驱使决策者直接购买行业最佳解决方案，稍作修改就面市应用。虽然听起来比自己架构更高效，但在实际中我们发现，这类“简单改改”的项目最后往往演变成“持久战”，买来的平台即使进行深度改造依然无法流畅地支撑业务。

事实上，这个思维的盲区在于：聚焦且局限于解决方案域层面，却没有考虑解决方案与企业自身问题域是否匹配、功能是否需要、方案背后的流程及组织机制是否能被公司现状支持等方面。

各个击破

这个问题场景是：某团队已经利用数字化技术解决了业务中存在的难题，此时，其他业务线看到这个团队的成效纷纷效仿，于是数字化团队深入不同业务线协助各个击破。但在突围过程中，团队慢慢发现，当他们涉及的范围越大，面临的冲突就越多，尤其是在一些跨业务的服务场合，反而降低了客户体验度。

这种建设思路存在的问题是：既缺乏整体规划，也没有针对单点问题进行深入分析，结果得到了一堆互为烟囱，甚至互相矛盾的解决方案。

数字化平台建设的四大制约

由此可见，如果不具备从问题域出发、对解决方案域进行顶层设计，再推进到实现域的思考路径，常见四大痛点将制约数字化的整体发展：

1. 缺乏整体规划，建成一堆平台，但功能、逻辑、数据都是割裂的；

2. 缺乏自身禀赋考量，同质化建设，无差异化竞争力；

3. 缺乏运营机制、评估机制的协调能力；

4. 投入大、周期长，产出的业务价值却难以衡量。

数字化平台建设的正确打开姿势 

数字化平台建设应当从战略层出发，基于业务能力蓝图的整体设计，指导数字化平台的建设。

这里的业务能力指的是针对某一个问题域制定的解决方案集合，其中包含相应场景、功能、实体，以及最终生产出来的数据。而业务能力的全集，即整体范围内的解决方案总和，也就是整个数字化平台建设的底图——业务能力蓝图。

反模式：从战术层面入手的平台设计

在业务线多、业务场景复杂的情况下，如果我们沿用市面上流行的各种从具体业务入手的建模法来进行业务能力设计，通常会发生以下三种情况：

1. 过程繁杂，展开的粒度不好把控。架构师容易迷失在业务操作人员制定的方案细节中，很难发现场景中要解决的根本问题是什么。

2. 建模和设计的结果孤立。整体设计基于的输入非常具象，过程缺乏全局视角，也未能从战略设计层面出发建模，往往最后得到一堆独立零散的模型以及一系列用途特定的业务能力，难以跨业务统一。

3. 因为企业本身对于一些业务及业务实体缺乏规章制度管理，从而会导致在基于具体流程场景的建模过程中无法识别这类业务实体，从而导致最终的设计中很大概率会存在业务能力缺失。

当然，我们不是全盘否定战术层面的建模方法，只是提出做企业级的能力建模，尤其是在囊括多种业务的企业中做能力建模，不能直接套用战术手段，直接从业务场景入手。更不要简单将能力想象成完全可分解可组合的积木，从而一味在业务实体级别寻找基础能力。

“三个锦囊”助力复杂业务环境中的企业级业务能力设计

那么，在复杂业务中，探索企业级业务能力的正确方式是怎样的呢？

这里的核心思路在于：

• 首先从战略设计入手，自顶向下探索，对问题域进行恰当的识别，通过子域“分而治之”；

• 在划分子域之后，需要进行解决方案域的顶层设计，也就是业务能力的设计；

• 最终形成业务能力蓝图，指导数字化平台实施以及落地。

在整个战略设计过程中，有三个关键点要时刻铭记：进行足够且适度的抽象；问题域识别先行；注重顶层设计。

接下来，我们就来看一下每个锦囊具体该怎么使用。

锦囊1：足够的抽象

在复杂业务环境中，我们需要抽象思考能够承载所有业务要素的运作模型是什么样的，这样才不会一直陷入战术细节而忽略对业务本质及通用逻辑的思考。

首先，为了保证足够的抽象性，建模用到的元素必须足够的精简。

在这里我们只用到了三类元素（见下图1）：

• 业务干系方（人）：业务运作过程中参与的重要角色；

• 业务要素（物）：业务运作过程中所需要的重要资源；

• 业务活动（事）：业务运作过程中，基于业务要素或者干系方，具体发生的动作。

 

图1：业务元逻辑模型图

 除了建模元素需要精简，建模的语言也需要通过抽象达到统一。比如，有些资管业务会投资到地产项目，有些资管业务会投资到市场证券产品，还有些资管业务会投资到信托产品上。在这种多业务的情况下，需要思考这些投资对象（不同的名词）有没有一个通用名称（同一个名词）？在这个例子中，这些投资对象在业务上的统称就是「投资标的」。建模时针对这种情况可以使用泛化关系表示（见下图2）：

图2：泛化关系图与代码示例

抽象始于具象内容，在具象内容之上再基于这样层层抽象，就可以对不同业务条线建模，还可以再次抽象提取一些更高阶的、企业级更宏观统一的模型。

锦囊2：问题域识别先行

问题域代表了需要解决的现实问题的边界。当一个问题域复杂度过高或者关注点过多时，就需要被递归的分割为多个小的问题域，也就是划分子域。这个过程中需要把整体问题域想象成一个立体结构，从纵横两个维度出发，对问题域进行识别和划分。

• 面向要素的问题域识别法（Element-oriented Decomposition）

面向要素的问题识别法：纵向对问题域进行划分，需要围绕运作逻辑中涉及的干系方及要素展开。

在下图3的示例中，围绕着每个业务干系方和要素（比如资金方、资产方、监督方等等）都识别出了业务关注和需要解决的问题域。

图3：基于业务元逻辑模型图的要素识别问题域（EoD）

• 面向切面的问题域识别法（Aspect-oriented Decomposition）

如下图4所示，这种识别模式下，需要提取各个问题域都关注的问题点，并且确保问题点在自身核心场景中可以分离出来。然后，将这些横切关注点归整到一起，成为一块独立的横切问题域。在金融行业，风控就是一个很典型的横切问题域，在其他问题域中，往往都需要去关注风险控制相关的问题，即如何在业务运作和资产资金管理过程中持续控制相关的风险。

图4：基于业务元逻辑模型图以风险切面识别问题域（AoD）

通常我们会把以上两种方法结合起来使用，它们是相互补充的关系。

锦囊3：解决方案顶层设计

解决方案顶层设计的核心是基于问题域的划分来明确业务能力的边界。比如在客户管理问题域中，资金端、资产端的客户管理的核心关注点实际上有很大差异，需要的业务能力也是不同的。

为了清晰表达业务能力内涵与边界，我们需要体系化的对业务能力进行高阶定义，需要明确这个业务能力所提供的核心价值、愿景，服务的对象、场景、业务实体，以及领域模型，也就是使用我们的业务能力全景画布（见图5）。

图5：业务能力全景画布

这里需要重点强调的是，能力全景图是不断变化的，就像我们所谨记的领域驱动设计第二条原则所说的：Iteratively explore models in a creative collaboration of domain practitioners and software practitioners（领域专家与技术专家协作，迭代地探索的模型）一样，能力全景图这一部分也会随着业务需求的不断提出、团队对于领域理解的不断深入而不断地演进、细化。

以上三个锦囊，就是面对复杂业务时，架构师团队该如何进行业务能力探索和规划的具体方法。

设计只是开始，建设没有终点

业务能力蓝图的设计只是一个开始，在蓝图指导下进行数字化平台建设的过程中，不仅仅是平台本身在演进，业务能力蓝图也会不断的完善和细化。

起点：业务驱动

当业务能力蓝图初步成型之后，就可以开始考虑平台的建设路径。平台的建设起点往往是业务驱动，也就是依托前台业务条线的实际需求驱动平台的具体建设。整个过程中，需要基于业务能力蓝图，针对这些需求涉及的平台能力，进行平台应用建设以及能力开放，最终使得前台业务能够在平台上运作起来。

在建设过程中，一方面需要具体分析需求中涉及哪些业务能力的使用、点亮或者是增强，从而对于已有的业务能力蓝图进一步的完善和细化；另一方面依据业务能力蓝图找到对应的系统应用，设计并构建需要开放的平台服务，从而不断丰富整个平台所具备的数字化业务能力。

而平台服务的构建、发布，以及开放是需要开发者在开放平台上完成的。需求分析中，依据服务旅程分析，开发者对于所需的API进行识别（见下图6）。

图6 基于场景识别API

其中，将用户支付订单场景通过服务旅程蓝图进行展开，可以识别出在“提交支付”环节需要调用支付功能，从而识别出相应的支付API。

在识别需要构建的API之后，开发者需要设计对应的request和response，形成swagger文档（见下图7）：

 

图7：详细设计API

接下来，在controller中进行相应的实现（见下图8）：

图8：实现API 

构建对应的API测试，引入mock server等方法来保证API功能完备（见图9）： 

 

图9：测试API

最终将API发布到开放平台上，供现有业务需求方（前台应用）使用，同时对开放平台范围内的所有开发者都可见，当其他开发者/需求方需要的时候，可以在自己的应用中使用已开放的API。开放平台上API的使用过程如下图10所示：

图10：基于开放平台的API使用过程

深化：平台自驱

业务驱动中对于业务能力往往都是点状需求，很难驱动出企业级的业务能力建设，尤其会缺失对于单个业务能力的具体内容规划。因此，当平台建设需要进一步深化的时候，需要加上辅助的平台建设手段——平台自驱，即依照业务能力蓝图，从平台能力自身视角出发，来规划应当提供哪些能力及服务。

通常在选择平台自驱的业务能力时，需要从业务辐射程度以及技术难度两个方向进行思考和比较，以确定平台自驱的优先级。

结语

数字化平台作为金融行业数字化转型战略落地的重要载体及引擎，直接决定了转型成败。金融机构应当在业务战略及目标的指导下，围绕业务能力设计业务能力蓝图作为平台建设的底图，并依据业务线及业务能力的依附关系和优先级，形成可落地的建设规划，在建设过程中同步引入先进的数字化技术，保障数字化转型有效有序的落地，最终实现数字化业务的成功。

作者简介：

黄雨青，Thoughtworks架构师，十年研发及咨询经验。专注于数字化转型下的企业架构、数字化业务平台、开放API、服务化转型等研发领域，先后为多个⾏业（金融、汽车等）的⼤型企业提供相关的技术及架构咨询落地业务。致⼒于以平台架构为核⼼，打造企业⾃身数字化能⼒。

钱平，第四范式架构师。十多年投行研发经验，为多家头部企业银行提供数字化转型、架构规划和智能化建设相关咨询，如企业战略规划、架构规划、企业平台的规划及落地建设、微架构转型、遗留系统上云迁移及转型过程中的各种技术赋能，以及创新实验室筹建等。