CN112748910B - 基于SaaS模式下的产品组装装配研发的***、方法及设备 - Google Patents

Abstract

本说明书实施例公开了基于SaaS模式下的产品组装装配研发的***。包括：根据预定领域对应划分出的多个已装配的组件集合、具有组件装配功能的装配平台；渠道服务领域组件集合向多个不同的对象提供服务入口和服务接触点；服务整合领域组件集合提供SOA的基础设施；产品服务领域组件集合提供多个不同的成员行对外的产品及服务，以及面向多个不同的成员行的运营服务；运营支撑领域组件集合提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；数据服务领域组件集合通过对内部、外部数据的存储与加工处理，提供多样化数据服务；装配平台响应于需求变更和研发人员的操作，对组件进行再组装，以更新已有的组件集合，或者生成扩展的组件集合。

Description

基于SaaS模式下的产品组装装配研发的***、方法及设备

技术领域

本说明书涉及计算机技术领域，尤其涉及基于软件即服务(Software as aService，SaaS)模式下的产品组装装配研发的***、方法及设备。

背景技术

近年来，随着利率市场化的不断推进和经济转型带来的影响，银行业的竞争日益加剧，灵活多变的产品需求越来越多，推动了银行产品管理体系的变革。银行产品是银行作为完整金融机构为客户提供完整金融服务的载体，各行对银行产品的快速创新和灵活定价提出越来越高的要求。目前，业界普遍暴露出产品创新能力不足、统一的产品创新标准缺失等问题，银行产品在传统模式下难以灵活应对市场变化，不能满足客户的差异化需求。如何提升产品创新能力和创新速度，统一管理产品信息，从而快速适应市场需求变化，及时响应客户的多样化产品需求，是中国每一家银行面临的课题。

在研发方面，传统银行标准需求背景下的***研发，瀑布式并无问题。在数字化时代下快速的市场响应、不确定的业务需求、不充分的业务沟通背景下，瀑布式产品研发相形见绌。

这些问题在中小银行尤其显著，当前中小银行发展的主要焦虑，除了资本、公司治理、内控机制等内在因素外，还面临着宏观经济国家目标压力、央行缩表、让利实体经济、金融强监管等宏观政策因素。客户竞争市场也发生了根本性的变化，一是产品需求侧的客户，客户粘性不仅是金融服务的诉求，而且是对极致体验的追求、对综合服务价格的追求、对“玩转金融产品”潮流时尚的追求。二是产品供给侧的银行，研发创新不足、面市周期长、产品定价高以及组合产品不足等现实，总结思变，研发能力主要差距体现在：一是流程节点之间定义不清晰，接口不尽统一；二是接力式和串行的产品开发流程“拥堵塞车”、“提速困难”；三是重复“发明轮子”，对失误纠偏、升级和改造难度大、风险高。

基于此，需要适用于金融机构尤其是中小银行的更高效的研发和应用方案。

发明内容

本说明书一个或多个实施例提供基于SaaS模式下的产品组装装配研发的***、方法、设备以及存储介质，用以解决如下技术问题：需要适用于金融机构尤其是中小银行的更高效的研发和应用方案。

为解决上述技术问题，本说明书一个或多个实施例是这样实现的：

本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的***，包括：根据预定领域对应划分出的多个已装配的组件集合、具有组件装配功能的装配平台，所述预定领域包括渠道服务领域、服务整合领域、产品服务领域、运营支撑领域、数据服务领域；

所述渠道服务领域对应的组件集合，向多个不同的对象提供服务入口和服务接触点；

所述服务整合领域对应的组件集合，提供面向服务的架构(Service OrientedArchitecture，SOA)的基础设施；

所述产品服务领域对应的组件集合，提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

所述运营支撑领域对应的组件集合，提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

所述数据服务领域对应的组件集合，通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

所述装配平台，响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的方法，包括：

向多个不同的对象提供服务入口和服务接触点；

提供SOA的基础设施；

提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

向多个不同的对象提供服务入口和服务接触点；

提供SOA的基础设施；

提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

向多个不同的对象提供服务入口和服务接触点；

提供SOA的基础设施；

提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

本说明书一个或多个实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过组件组装装配式的研发，变被动为主动、快速预研、灰度发布和迭代递增，有助于更高效地达成业务战略目标。

有助于快速响应客户需求。能够将通用业务及基础技术能力下沉，这些能力从业务***中剥离出来之后，业务应用就可以变得更轻、更专注，开发者就可以通过很少的代码把这些服务集合起来，封装成业务功能暴露给用户。业务***更小、更轻，意味着可以更频繁的上线，更快速的修改，更快、更简单的组合出新的功能推向市场，只有这样才能支持业务创新和敢于尝试。

有助于降低成本提高效率。有助于自动运维的实施，通过服务治理，运维人员从重复枯燥的日常操作中解放出来，将更多的时间和精力投入到自动化平台的建设中，让自动化运维能力以服务的形式暴露出来，达到降低成本和提高效率的目的。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的***的结构示意图；

图2为本说明书一个或多个实施例提供的一种应用场景下，包含AI中台在内的部分具体架构的示意图；

图3为本说明书一个或多个实施例提供的一种应用场景下，AI中台的具体架构的示意图；

图4为本说明书一个或多个实施例提供的一种应用场景下，图1中的***的部分具体架构的示意图；

图5为一种应用场景下，基于图1中的***实现的一种单实例多成员行的架构图；

图6为本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的方法的流程示意图；

图7为本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的设备的结构示意图。

具体实施方式

本说明书实施例提供基于SaaS模式下的产品组装装配研发的***、方法、设备以及存储介质。

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1为本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的***的结构示意图。

图1中的***包括：根据预定领域对应划分出的多个已装配的组件集合、具有组件装配功能的装配平台，预定领域包括渠道服务领域、服务整合领域、产品服务领域、运营支撑领域、数据服务领域。渠道服务领域对应的组件集合，向多个不同的对象提供服务入口和服务接触点；服务整合领域对应的组件集合，提供SOA的基础设施；产品服务领域对应的组件集合，提供多个不同的成员行对外的产品及服务，以及面向多个不同的成员行的运营服务；运营支撑领域对应的组件集合，提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；数据服务领域对应的组件集合，通过对内部、外部数据的存储与加工处理，提供多样化数据服务；装配平台，响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

通过组件组装装配式的研发，变被动为主动、快速预研、灰度发布和迭代递增，有助于更高效地达成业务战略目标。

在本说明书一个或多个实施例中，将该***应用于金融机构，比如，上述的成员行包括金融机构，对象包括金融机构的客户、金融机构自身的员工、联盟的员工。以更具体的银行为例。

银行IT架构建设目标概况为以下几点：

高性能：应具有海量处理性能，满足对亿级用户数量的支撑，具有千万级日均交易量的处理能力。高弹性：应具备高效、快速的扩展能力，实现架构整体容量和单位处理性能快速提升。高可用性：应具备高可用性，在满足银行业监管对于恢复点目标与恢复时长目标要求的基本前提下，面向社会提供7×24小时不间断的银行服务。高规范性：应具备高度标准性，由标准化的物理及逻辑单元构成，从而实现自动化运维和规模化管理。低成本：应实现较高的性价比，充分运用低端计算资源和开源技术，有效的降低架构建设和后续运营的相关成本投入。低风险：应具备高冗余性和高密封舱化，全架构均应采用2N级高冗余度的设计，杜绝单点风险；在极端故障场景下，应能尽量缩小故障的影响范围。

以上就是银行IT的组件化***的设计思想。具体实践需要将需求场景领域化，将场景领域模块化，以符合***需求为衡量，以稳定领域最大复用为目的，使其可以通过组合拆分来构建整个***的独立解决方案。基于此，具体对于图1的***：

渠道服务领域对应的组件集合，提供成员行客户、成员行员工、联盟员工的服务入口和服务接触点，同时提供外部合作伙伴的服务接入和业务合作的管理。通过多渠道的分类、整合和统一接入，实现联盟成员行各类客户与用户，以及外部合作伙伴对银行金融服务和业务管理的访问。渠道服务主要提供基于展现和交互式操作的企业级访问服务，以及面向客户、成员行营运、合作伙伴机构之间的产品服务整合，实现产品和营销在渠道的快速发布。

服务整合领域对应的组件集合，提供SOA的基础设施，满足服务治理与集成的要求，支持服务资产化的落地实现。新规划的混合式企业服务总线，包含集中式集成和分布式集成两种技术，形成联盟范围内整体集成方案。

产品服务领域对应的组件集合，提供成员行对外的金融产品及服务，以及面向成员行的运营服务。产品服务以银行产品为基础，支持产品的管理、销售、控制和运营。产品服务领域底层提供业务共享中台支撑，提供各类产品服务所需的公共服务能力，提升领域内的组件重用性，支持产品的快速上线。

数据服务领域对应的组件集合，通过对内部、外部数据的存储与加工处理，提供及时、可靠、丰富的多样化数据服务。

运营支撑领域对应的组件集合，提供联盟内部管理的运营支撑应用服务能力。

装配平台，包括基于银行业基础组件和基本技术组件之上构建的应用开发框架。在模块的复用性上，将一些基础的或者通用的功能模块独立抽取出来，形成独立的组件库，组件库的各个组件可独立维护，并按需组装到不同的应用中。整体的软件产品逐步拆解为业务组件、产品部件、原子零件。装配平台根据用户需求和研发需求将大、小、形、色各种原子件组合起来，通过装配手势象“搭积木”一样组织成为新的产品。

业务组件是企业中能够独立或者半独立运作的一部分，通常包括流程、人员、组织、技术等要素。按分类来说，包括原子组件、复合组件、插槽组件、拓展组件和适配组件。这些组件的集合，构成了企业视角的标准化和统一化的生产成果库。产品部件是描述客户与银行互动的每一个结构体。串起来就是一个完整的金融活动。产品零件是描述产品部件的业务属性、管理属性和度量属性。大小粗细取决于具体的拆解方式。

装配平台按照***需求或者稳定领域需求，遵守技术文档、组件的自描述、功能和对外契约，定义产品线实施工艺，充分利用企业公共的、共享的能力资源实现产品装配。

在本说明书一个或多个实施例中，图1提到组件主要指业务组件，这里业务组件具有如下特点：

功能独立。业务组件是独立的业务模块，在企业***中承担特定的职责。组件可以是企业自己完成或者由合作伙伴完成。企业组件化的过程也是内部和外部专业化的过程，企业可以通过组件化建立价值网络，重复利用外部资源提升自己的竞争力。

服务解耦。组件内部各个活动之间是紧密关联的，与外部其他组件的关联程度较低。所以，组件是可以独立运作的，使得专业化分工和外包成为可能。

黑箱特征。每个业务组件的输入和输出都高度标准化。组件不能直接使用其他组件内部的活动或者资源，只能根据组件之间的标准接口提出服务请求而获得所需的服务。

组件重用。组件一般都拥有自己的资源，完成特定的活动提供价值的时候也会消耗资源。也存在没有资源的组件，它们只能通过调用其他组件的方法完成自己的功能。

便于组装。组件设计充分考虑到应用颗粒度及装配复用性能，大小粗细和提供的功能取得相对的平衡，拿来即用、便于组装为最优模型。在业务组件能力上面，集中精力和资源做明确的企业战略重点的业务组件，把它们做到最具有活力，从而获得更高的回报，这就是专业化的组件能力。

在本说明书一个或多个实施例中，将数据架构或者业务架构向服务中台架构转变。以数据架构为例。

数据架构是业务架构与应用架构的纽带，数字化时代下数据架构提供卓越的大数据支持力。企业的数据架构可以帮助企业消除信息孤岛，建立一个共享、通用、一致和广泛的企业数据基础平台。数据架构的最终目的是使得企业的数据管理有序，数据价值充分发挥，即数据可管理、可利用、有价值，还能促生新的商业模式。数据架构向数据服务中台架构转型，其本质就是通过企业级的数据治理，提供自由、灵动、可信、多样化的数据服务，这就意外着对企业数据架构再造和数字赋能。在架构设计理论中，数据架构也经常被统称或者映射为其他的名字，例如概念数据模型、企业数据模型、企业信息模型等。

企业数字化转型第一个动作就在于企业数据架构转型。业务流程到数据化的过程，在现实世界中由“活动+对象+关系”来描述。在特定的商业领域，梳理重点业务活动，提炼业务对象及其属性，并总结业务对象的相互关系，从而确定与业务流程相适应的企业级数据服务中台。本说明书提供的数据服务中台具体有如下特点：

业务通用。架构既要有通用性，也要符合企业的业务特征，不会太泛泛，也不会太刻板而不支持业务的扩展。

全局治理。数据项要完整、一致，应该支持企业所有业务信息的处理，而且不能有重复和矛盾。经常见的是同一个数据项，由于使用的名字不同，或者定义的部门不同而重复，从而导致数据不一致和冗余，会引起一系列的数据打架和信息质量问题。

数据标准。要有企业级统一的标准，如机构、客户、产品、渠道、介质、交易等。好的架构会制定这些标准，从而提高企业的数据利用质量。这也是主数据管理范畴。

逻辑抽象。架构有一定的稳定性和前瞻性。还具有很强的灵活性，能够支持业务的不断发展，能够适应组织架构和流程的变化，与数据的存储地点、存储形态、存储数量、应用的技术等无关，不会随着它们的变化而变化。

在本说明书一个或多个实施例中，不仅是数据服务中台，还建立了业务共享中台，形成“双中台的架构”，在图1的***中，产品服务领域对应的组件集合比如包括业务共享中台，数据服务领域对应的组件集合比如包括：数据服务中台。

业务共享中台是对银行最基本的业务能力抽象提炼，成为公用性的组件，作为可以供银行各种产品服务共享和调用的部分，在业务共享中台之上，银行产品服务可以实现快速开发和灵活定制，从而提升银行基础能力的重用性，防止在不同产品应用***中重复发明轮子。

数据服务中台的主要设计思想是通过建设联盟集中、可信的数据中心，为成员行和联盟数据应用及分析挖掘提供标准的、口径一致的数据接口和服务，达到“统一采集、统一存储、统一加工、统一服务、一次加工多次使用”的目标。数据服务中台定位和业务共享中台一样，就是实现和承担数据能力中基础的、可重用、可共享的部分。各种数据应用，在数据服务中台之上建设，能够充分利用数据服务中台的共享服务，而不是每个数据应用都从源端的数据基础上开发。

业务共享中台和数据服务中台，将成为联盟承载产品服务和数据服务的基础，两个中台的建设在统一架构治理下，有步骤有计划地推进，分块分阶段建设，并在应用开发、数据服务过程中，不断地沉淀、抽象、提炼可重用的部分，这需要长期的投入、持续地改进，以及与各成员行的密切协同。

在本说明书一个或多个实施例中，业务共享中台或者数据服务中台包括以下组件：机构组件、客户组件、签约组件、产品组件、账户组件、渠道组件、交易组件、总账组件。这些组件由相应的部件构成，部件又由相应的零件构成，列举则这些组件分别涉及一个业务领域，从数据的角度而言，构成这些组件的部件比如为数据库中的实体表，构成部件的零件比如是实体表中的字段。

在本说明书一个或多个实施例中，数据服务中台依托于预先进行的数据接入分拣处理。

在数据接入分拣处理中，实现了：对源***数据清洗校验保证数据准确性和一致性；根据集群应用导向，分拣所需***、表、字段，实现数据规模最小化；源***数据精细化分析，产出分类标签，为技术开发人员扫清使用障碍；设立隔离层，起到承上启下的作用，屏蔽上游***变更影响；根据分拣目录及成员行，制定不同用户权限，实现数据访问合规化。

更直观地，示例性地提供了一些不同层级的分拣策略：

***级的分拣策略包括：未集中管理的***不进；纯外购***且无法得到提供商支持的***不进；规划上即将被其他***替代的***不进；本身不产生数据，而是由其他***提供数据的不进；属于集市应用，将来有可能变成中台下游应用的不进；非核心的、相对独立且与银行业务无直接关系的***不进；等等。

表级的分拣策略包括：空表不进；技术控制类表不进；中间数据表不进；临时表不进；备份数据表不进；失效表不进；没有明确含义的表不进；无需求应用的表不进；等等。

字段级分拣策略包括：冗余字段不进；中间计算结果字段不进；未启用字段不进；没有明确含义的字段不进；等等。

在本说明书一个或多个实施例中，图1中的***还包括：人工智能(ArtificialIntelligence，AI)中台，基于数据服务中台的支撑，向所产品服务领域对应的组件集合和所述运营支撑领域对应的组件集合提供服务，比如，为业务共享中台提供更具人工智能的服务。AI中台包括：特征层、模型层、AI能力层、应用编程接口(Application ProgrammingInterface，API)组件层、工具层等。AI中台的AI能力包括但不限于：智能推理、智能语音、智能视觉、知识图谱、自然语言处理。

更直观地，本说明书一个或多个实施例还提供了一种应用场景下，包含AI中台在内的部分具体架构的示意图，以及AI中台的具体架构的示意图，分别如图2、图3所示。

在图2中，底层的数据资产为AI中台和数据服务中台提供数据支撑，AI中台连接数据服务中台，AI中台通过算法库(机器学习、图计算等)和知识库(标签、图谱等)实现AI能力，并基于这些能力和数据服务中台、数据资产，实现更高层的应用，比如，智能风控、智能营销、生物识别等。

在图3中，AI中台下接数据集(比如，提供内部数据、政府数据、监管数据等)，上接业务应用域，在一些具体的业务场景中发挥作用，比如，用于检测流动性风险、大额风险、服务于网贷业务场景、***业务场景等。在AI平台内部，工具层为其他各层提供工具，比如，图计算平台、流式计算平台、数据挖掘和分析平台等，特征层处于AI平台的底部，模型层根据特征层提供的特征(比如，司法信息、产品标签、用卡特征、出行特征等)工作，进而实现AI能力层，然后通过相应的API组件层提供给上层使用。

在本说明书一个或多个实施例中，装配平台包括：产品装配中心，基于智能前端平台(比如，EasyFace等)，采用统一的流程式产品参数生效方式，实现组件至产品的组装装配，有助于实现产品的快速生效，降低运维风险，增强敏捷运营和运维支撑能力；定价识别引擎，根据产品参数，识别组件及产品的定价信息，有助于确定更为符合监管要求的定价。创新性体现在：

统一管理产品信息，趋向标准化、规范化：装配平台统一管理全部成员行的产品信息，包括产品模型和可售产品信息。产品模型在设计时，采用面向对象的设计方法，使得产品模型具备组件化、结构化的特点，类似汽车零件，易于装配和管理。这使得产品管理更标准化、规范化。

建立标准的产品模型，提高工作协同效率：产品装配模型是产品***协同和工作协同的统一基础。装配平台根据产品装配模型的要求，配置出统一格式的相关可售产品的结构化参数，并推送至各产品应用***。各产品应用***的功能，将按照产品装配模型中部件的规划设计实现，与结构化参数协同完成产品服务功能。产品需求分析、产品***设计和产品***测试等日常工作环节，都可以在统一的产品装配模型规范约束下开展，提高了各阶段工作的协同效率，避免在各阶段的工作环节中对关键人员的依赖，提高工作效率。

共享统一的产品模型，提升产品创新效率：某一类可售产品的产品模型是在目前所有成员行的基础上，融合所有描述此类产品的业务和技术参数的集合，通过组件化、结构化的方式，配置出来的模型，符合所有行对该类产品的需求。成员行在提出产品需求时，能够快速的定位模型支撑能力，确认采用配置型还是突破型的产品创新模式，一般为配置型，大大缩短成员行的产品创新的速度，提高产品创新效率。

可视化的产品配置界面，降低参数变更风险：有别于手工变更产品参数的方式，装配平台将通过可视化的产品装配界面完成产品、利率、费率等参数配置；同时，为了进一步提高配置准确性，在装配参数时，还增加了产品审核的操作，有效的降低产品参数变更的风险。

建立统一的产品发布流程，减少人工干预降低风险：装配平台建立了统一的产品发布流程，从数据库表层面区分产品发布的流程，减少人工干预产品生效的流程，降低误操作的风险，提高产品变更的效率。

建立实时生效产品机制，快速响应产品需求：装配平台增加实时生效产品参数的机制，能够快速满足成员行提出的紧急需求，提高客户满意度，有利于银行业务的发展。

建立实时分析产品机制，有效降低变更风险：在成员行对其可售产品、利率、费率等参数变更时，装配平台实时提供自动关联性分析功能，特别是利率调整的关联性分析功能。通过关联性分析报告，确保利率调整后，成员行所有可售产品利率定价，都符合监管要求。

在本说明书一个或多个实施例中，产品装配中心包括以下结构层：产品元模型、单一产品模型、部件类、元件类、产品参数。采用了双模型的设计方案：产品元模型，为描述产品模型的模型，结构统一；单一产品模型，为根据产品的业务功能特征，进行归纳总结分类，分为多个组件，以结构化、组件化的方式定义一个结构相对稳定非直接面向客户的模型，定义过程中可支持产品研发人员通过可视化的交易界面进行快速定义与配置。

在本说明书一个或多个实施例中，产品装配中心支持通过可视化界面配置，并动态展示。产品装配中心包括可售产品装配模块，支持业务人员通过可视化界面对可售产品、部件实例与元件实例进行快速参数化配置并发布产品，还支持对预定义的部件实例与元件实例的快速选择与复用。

可售产品装配模块动态注入产品模型变更形成的模型元数据，并对产品模型的层级结构与参数定义进行智能解析，可动态构建可售产品、部件实例与元件实例的可视化装配页面，并可根据模型元数据的调整实现实时的自适应扩展。

可售产品装配模块内建的产品装配规则引擎能够通过产品装配模型元数据的注入，形成动态校验规则，实时自动地对装配的实例内容进行产品信息的完整性与准确性检核，最大程度消除操作风险；校验规则可通过变更模型元数据的配置实时调整。

可售产品的发布通过主副本同步的方式，可实现实时发布。可售产品的发布引擎以可售产品为单位生效完成装配的实例配置，将实例化数据从装配态数据库“搬运”至运行态数据库。产品发布时通过产品模型元数据的注入与对模型结构的解析，发布引擎可自动解析主本数据并装载至副本数据中；可通过T+0生效的方式，实现实时生效产品。

在本说明书一个或多个实施例中，服务整合领域对应的组件集合或者所述产品服务领域对应的组件集合包括以下总线：企业服务总线，用于与所述渠道服务领域的全渠道进行交互；联盟成员企业服务总线；用于与所述联盟的成员的渠道进行交互。比如，服务整合领域对应的组件集合可以采用混合式的上述总线，总线包含集中式集成和分布式集成两种技术，形成联盟范围内整体集成方案。从而，有助于以提高对联盟外的服务效率和对联盟内的管理沟通效率。

在本说明书一个或多个实施例中，在组装式研发思想的指引下，要实现组装式研发，离不开组装平台，这个组装平台可以更形象地称之为组装工厂，比如，基于图1中***实现组装工厂，下面提到的一些流程方案均可以在图1中的相应模块上执行(比如，装配平台等)，其是实现组装式研发的新基建。有了这个工厂，就可以搭建产品装配线，制定产品标准，部署人员将原料按照新的组装工艺生产出所需产品。

组装式研发思想落地过程中，有了工厂，还得有产品装配线。新的研发模式是面向全生命周期的组装工艺，全生命周期组装是指通过一站式开发支持服务，对设计、编码、单元测试等开发行为进行规范化管理，对开发过程中的开发资产进行统一配置管理。核心企业级组装研发工具就是这个装配线，它实现开发资源管理、开发过程管理、单元测试管理、资源在线交付等功能，并能不断扩展对外部工具及组件的支持，还可以提供消息通知功能。

新工厂、新生产装配条线出来后，在装配条线上装配新产品时，生产工艺流程中各架构融合属于新模式的一个特色。业务战略、业务需求、业务目标、业务方案决定了业务架构，业务架构可以按照五级建模标准完成业务流程建模；业务架构又决定了使用那些数据和服务，因此确定了数据架构与应用架构，这样就形成了一个自上而下逐级关联相互耦合的体系，从而做到了各种架构的融合。

有了工厂、装配条线，各架构强融合的生产工艺，接下来介绍装配产品所使用的原材料，也就是核心的数据组件。数据组件位于数据架构下，供应用架构、业务架构调用，核心组件的数量还是十分的庞大。

核心数据组件主要分为两部分：包括应用数据组件、数据库组件和数据库元件。应用数据组件主要包括常量、平台接口、输入输出接口、文件接口等数据，其中输入输出接口、文件接口、内部服务函数接口组件数量比较大；数据库组件主要是指核心表结构。按照业务功能划分主要包括公共客户、存款、贷款国结、支付结算、卡、会计和平台；数据库元件主要包括表的数量、字段数量、记录数量；在一种实际应用场景下进行了合计，数据库表一共1100多张，字段数共20000多个，记录总数超过66亿。

有了新工厂、新生产装配条线、各架构强融合的生产工艺和工厂的源材料输入后，还需要对原材料的质量有较强的管控。在组装式研发模式下，要将联盟数据标准引入到组装工厂中，可识别的识别的数据标准比如包括数据类型、标准主题、命名、码值等，在一种实际应用场景下，核心***梳理出600多项标准，6000多项码值。引入后，组装工厂会继承联盟数据相关标准，在数据架构、应用架构、业务架构中做进一步管控，真正做到了数据标准与各架构的绑定，实现了数据标准的强管控，强一致性。组装工厂会逐步接入联盟制定的相关数据标准，支持不断扩展。

有了工厂、装配条线、生产工艺、原材料和原材料质量管控标准后，还有一项重要的认知：就是人才的管理。打个比方：装备再好，使用的人不行，一样打不了胜仗。在一些方案中，专家精英主要分布在各单元内部，对自己业务领域内比较专注，其他业务领域却不够熟悉，通用性不足，公共人员相对较少。而在基于组装式研发模式下，普通研发人员不再花费大量时间研究深奥的编程技术性问题，而是更关注业务流程的设计，降低对编程技术的依赖，缩短学习成本，适用面更普及，可在各个业务领域快速入手，因此可增大公共人员数量，缩减对高精尖人员的需求。所以，实现新的人员分层，是实现组装工艺的基石，是提升效率和质量的保障。

在本说明书一个或多个实施例中，对组装流程进一步地介绍，数据架构是基础，在此基础之上才可以构建应用架构，所以先介绍一下数据组件的组装过程。数据架构下对应三种数据组件：实体对应数据库表，对象对应应用程序接口数据，基元数据对应数据字典。

数据库表的组装流程包括以下：第一步，从联盟数据管控平台将表导出，并转换成中间文件；第二步，将中间文件导入到装配条线数据架构相应的层级下；通过这两步就完成了数据库表的组装。另外，也可以直接在装配条线数据架构中创建来进行组装。对于对象与基元数据的组装流程，与数据库表组装类似，只要准备好数据文件，就可直接导入数据架构相应的层级下，同样，也可以直接在装配条线数据架构中创建来进行组装。

除了数据组件以外，还有其调用层，应用组件的组装流程。应用组件按业务领域分，分为存款、贷款国结、卡、支付结算、会计、公共客户、平台等；按组件类型分，分为联机服务、批量服务、记账组件、功能组件等。应用组件的组装流程包括：第一步，在组装工厂应用架构下创建应用组件；按照五级建模流程部署组件归属目录；第二步，在组装式程序中，通过直接输入组件名称，即可智能模糊匹配组件，实现快速调用，当要从大量组件中筛选时，智能模糊匹配要比拖、拉、拽，更高效。

在本说明书一个或多个实施例中，在一种应用场景下，一个组装式研发程序的具体组装流程(其比如应用于图1的***中，通过装配平台实现)包括：

第一步，在应用架构下，先设计应用域，核算中心作为试点项目，这里应用域就设计成了核算中心，当然，试点项目成功后，以后可以把存款、贷款国结、卡、支付结算、会计、公共客户等应用域逐步添加进来。第二步，在应用域下，要设计相关组件，为了标准化组件的设计，制定了一些规范，目前组件包括三类：联机、公共函数、批量；联机组件主要是与联机、外部接口相关的一类程序；批量组件主要是与日终批量相关的一类程序；公共函数主要是***内部使用的一些记账组件和功能组件。第三步，在相应组件下，设计相关的应用程序分组，应用程序分组是对组件功能的进一步精细化划分，它主要按照功能进行划分，因此可以按功能块集中管理一组相关的程序。第四步，在应用程序分组下，设计相关的应用程序，应用程序分为两大类，服务程序和批量程序，这些最基础的组件设计出来后，就可以按照需求进行组装设计了。

以上四步展示了核心组装式研发的一个组装流程，第四步应用程序设计对应业务流程建模中的四级任务建模和五级步骤建模。组装式研发与传统编码相比有以下优势：业务流程图形化显示，更清晰；只需要拖、拉、拽、选择就可编写应用程序，开发效率有一定提升；所有数据必须先定义才能使用，保证了数据架构与应用架构的一致性；实时监测程序编写错误，实时纠正，减少了后期调试时间。

组装式研发还可以自动生成COBOL代码。生成代码非常简单，组装式应用程序全部设计完毕后，选择翻译代码功能即可自动生成代码。除了可以生成COBOL代码外，还可以生成JAVA、C#代码，为未来联盟核心迁移分布式也能提供一种途径。另外，在组装式应用程序设计时，可以实时查看翻译的代码，提前发现问题。通过业务基础平台产出的代码，是经过平台验证和检核的，理论上不会有低级编译错误，生成的代码是可以直接编译、调试、运行的。另外，平台本身支持自动代码检查功能，并且可以丰富和完善。关于生成代码的版本控制，业务基础平台对接联盟版本管理***实现代码自动检入检出，达到与目前版本控制流程的融合。

根据前面的说明，本说明书一个或多个实施例还提供了一种应用场景下，图1中的***的部分具体架构的示意图，如图4所示。

在图4中，列举的成员行客户渠道、成员行员工渠道、联盟员工渠道、业务合作管理、全渠道接入与整合涉及的总线属于渠道服务领域；产品服务整合(包括面向客户、面向成员行运营、面向合作机构等)，以及渠道公共服务属于服务整合领域；企业服务总线，业务共享中台，以及列举的一些银行业产品(存款贷款等基础产品、理财产品、代销产品、网络融资等)属于产品服务领域；联盟产品目录和服务计费等联盟运营管理、联盟企业管理属于运营支撑领域；数据服务门户、数据服务中台、数据存储与计算、数据集成与分发等属于数据服务领域。

图5为一种应用场景下，基于图1中的***实现的一种单实例多成员行的架构图。单实例可以指代一个联盟，多成员行可以指代联盟的多个成员行，在成员行侧，每家成员行都可能有不同***接入，而在联盟侧，都是用一套***，支撑多家成员行的业务。

在图5中，在联盟侧，通过企业服务总线加文件总线进行全渠道接入，接入对象包括成员行业务接触渠道、成员行外联业务渠道、成员行用户渠道、联盟员工渠道、三方业务合作渠道等；不仅如此，还独立地通过成员行企业服务总线加文件总线进行联盟内成员行接入，接入对象包括成员行用户渠道、成员行专有业务***、成员行数据平台及应用等。

需要说明的是，简明起见，这里仅列举了图4、图5中的部分内容，省略未提及的图4、图5中的其他内容也属于本说明书的实质内容，通过图4、图5可以直观地看到。

前面对***的组成和工作原理进行了示例性说明，在实际应用中，对组成部分的划分方案是多样的，并不限于上面的例子，只要能够执行相应的步骤即可。基于同样的思路，本说明书一个或多个实施例还提供了一种基于SaaS模式下的产品组装装配研发的方法的流程示意图，如图6所示。

图6中的流程可以包括以下步骤：

S602：向多个不同的对象提供服务入口和服务接触点。

S604：提供面向服务的架构SOA的基础设施。

S606：提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务。

S608：提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力。

S610：通过对内部、外部数据的存储与加工处理，提供多样化数据服务。

S612：响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

基于同样的思路，本说明书一个或多个实施例还提供了上述方法对应的设备，如图7所示。

图7为本说明书一个或多个实施例提供的一种基于SaaS模式下的产品组装装配研发的设备的结构示意图，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

向多个不同的对象提供服务入口和服务接触点；

提供SOA的基础设施；

提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

处理器与存储器之间可以通过总线通信，设备还可以包括与其他设备通信的输入/输出接口。

基于同样的思路，本说明书一个或多个实施例提供了一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

向多个不同的对象提供服务入口和服务接触点；

提供SOA的基础设施；

提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (8)

1.一种基于SaaS模式下的产品组装装配研发的***，其特征在于，包括：根据预定领域对应划分出的多个已装配的组件集合、具有组件装配功能的装配平台，所述预定领域包括渠道服务领域、服务整合领域、产品服务领域、运营支撑领域、数据服务领域；

所述渠道服务领域对应的组件集合，向多个不同的对象提供服务入口和服务接触点；

所述服务整合领域对应的组件集合，提供面向服务的架构SOA的基础设施；

所述产品服务领域对应的组件集合，提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

所述运营支撑领域对应的组件集合，提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

所述数据服务领域对应的组件集合，通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

所述装配平台，响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合；

所述成员行包括金融机构，所述对象包括所述金融机构的客户、所述金融机构自身的员工、所述联盟的员工；

所述产品服务领域对应的组件集合包括：业务共享中台，其包括通过对所述金融机构的基本业务能力进行抽象提炼，形成的公共性的组件，用于所述金融机构的产品服务共享和调用；

所述数据服务领域对应的组件集合包括：数据服务中台，其通过建设联盟集中、可信的数据中心，为成员行和联盟数据应用及分析挖掘提供标准的、口径一致的数据接口和服务。

2.如权利要求1所述的***，其特征在于，所述业务共享中台或者数据服务中台包括以下组件：

机构组件、客户组件、签约组件、产品组件、账户组件、渠道组件、交易组件、总账组件。

3.如权利要求1所述的***，其特征在于，所述***还包括：

人工智能AI中台，基于所述数据服务中台的支撑，向所述产品服务领域对应的组件集合和所述运营支撑领域对应的组件集合提供服务；

所述AI中台包括：特征层、模型层、AI能力层、应用编程接口API组件层、工具层。

4.如权利要求1所述的***，其特征在于，所述装配平台包括：

产品装配中心，基于智能前端平台，采用统一的流程式产品参数生效方式，实现组件至产品的组装装配；

定价识别引擎，根据产品参数，识别组件及产品的定价信息。

5.如权利要求4所述的***，其特征在于，所述产品装配中心包括以下结构层：产品元模型、单一产品模型、部件类、元件类、产品参数；

所述产品元模型，为描述产品模型的模型；

所述单一产品模型，为根据产品的业务功能特征，进行归纳总结分类，分为多个组件，以结构化、组件化的方式定义一个结构相对稳定非直接面向客户的模型。

6.如权利要求1所述的***，其特征在于，所述服务整合领域对应的组件集合或者所述产品服务领域对应的组件集合包括以下总线：

企业服务总线，用于与所述渠道服务领域的全渠道进行交互；

联盟成员企业服务总线；用于与所述联盟的成员的渠道进行交互。

7.一种基于SaaS模式下的产品组装装配研发的方法，其特征在于，应用于如权利要求1所述的***，所述方法包括：

向多个不同的对象提供服务入口和服务接触点；

提供SOA的基础设施；

提供多个不同的成员行对外的产品及服务，以及面向所述多个不同的成员行的运营服务；

提供由多个不同的成员行形成的联盟内部的运营支撑应用服务能力；

通过对内部、外部数据的存储与加工处理，提供多样化数据服务；

响应于需求变更和研发人员的操作，对组件进行再组装，并根据再组装结果更新已有的组件集合，或者生成扩展的组件集合。

8.一种基于SaaS模式下的产品组装装配研发的设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求7所述的方法。