CN111008767B - 互联网金融技术架构评估方法、装置、电子设备和介质 - Google Patents

Abstract

本公开提供了一种互联网金融技术架构评估方法、装置、电子设备和介质，该互联网金融技术架构评估方法包括：对于互联网金融技术架构的一个业务，确定互联网金融技术架构的架构关联信息，架构关联信息包括多个版本业务的服务数量及服务组成情况，以及多个版本业务的业务请求数量；基于多个版本业务的服务数量确定服务数量变化信息，以及基于多个版本业务的业务请求数量确定业务请求数量变化信息；以及基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，以便于基于业务开发资源适配度分配业务开发资源。

Description

互联网金融技术架构评估方法、装置、电子设备和介质

技术领域

本公开涉及互联网技术领域，更具体地，涉及一种互联网金融技术架构评估方法、装置、电子设备和介质。

背景技术

为了适应数字化银行的发展要求，商业银行需要理解行业发展趋势，分析企业存在的威胁和机遇。商业银行经过系统地分析产品服务、市场营销、资源管理、业务支持等范畴的工作，梳理业务架构相关的流程、产品和业务实体，形成各类复杂的业务架构资产，并指导互联网技术(IT)架构建设。

在实现本公开构思的过程中，发明人发现现有技术中至少存在如下问题。商业银行业务架构和IT架构资产分类复杂，数据分散，不便于在IT架构建设过程中对开发资源进行合理分配。

发明内容

有鉴于此，本公开提供了一种有助于提升开发资源分配合理性的互联网金融技术架构评估方法、装置、电子设备和介质。

本公开的一个方面提供了一种由服务器端执行的互联网金融技术架构评估方法，其中，互联网金融技术架构包括至少一个版本，每个版本的互联网金融技术架构支持至少一个业务，每个版本的互联网金融技术架构的各业务包括至少一个服务，上述方法包括：对于互联网金融技术架构的一个业务，确定互联网金融技术架构的架构关联信息，架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量；基于多个版本业务的服务数量确定服务数量变化信息，以及基于多个版本业务的业务请求数量确定业务请求数量变化信息；以及基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，以便于基于业务开发资源适配度分配业务开发资源。

本公开实施例提供的互联网金融技术架构评估方法，基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，为金融科技部门客观、合理地评价各业务的发展情况，以及科技资源投入提供分析方法与参考依据。

根据本公开的实施例，各版本业务包括复用服务或者复用服务以及以下至少一种：更新服务和新增服务；确定互联网金融技术架构的架构关联信息包括：按照版本确定业务请求数量以及以下至少一种：复用服务数量、更新服务数量和新增服务数量；基于多个版本业务的服务数量确定服务数量变化信息包括：基于多个版本业务的复用服务数量确定复用服务数量变化信息，和/或，基于多个版本业务的更新服务数量确定更新服务数量变化信息，和/或，基于多个版本业务的新增服务数量确定新增服务数量变化信息；以及上述方法还包括：在确定互联网金融技术架构的架构关联信息之后，基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种，以及业务请求数量变化信息确定服务开发便捷度，以基于服务开发便捷度调整服务开发资源。

根据本公开的实施例，基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种，以及业务请求数量变化信息确定服务开发便捷度包括：基于第一服务开发便捷度和/或第二服务开发便捷度确定服务开发便捷度；其中，第一服务开发便捷度是基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种与业务请求数量变化信息的比值确定的；以及第二服务开发便捷度是基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种与服务数量变化信息的比值确定的。

根据本公开的实施例，基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度包括：基于业务服务比基线、业务请求数量和服务数量变化信息确定业务开发资源适配度。

根据本公开的实施例，评估方法还包括：对于各版本的互联网金融技术架构的多个业务，确定多个业务的业务请求数量变化信息；基于多个业务的业务请求数量变化信息确定业务的热点度；以及基于业务的热点度分配业务开发资源。

根据本公开的实施例，评估方法还包括：在基于多个业务的业务请求数量变化信息确定业务的热点度之后，确定热点度大于等于热点阈值的业务与业务架构中热点业务的匹配度；以及基于热点业务的匹配度确定互联网金融技术架构与业务架构的匹配度。

本公开的一个方面提供了一种互联网金融技术架构评估装置，包括：架构关联信息确定模块、变化信息确定模块和适配度确定模块。其中，架构关联信息确定模块用于确定互联网金融技术架构的架构关联信息，架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量；变化信息确定模块用于基于多个版本业务的服务数量确定服务数量变化信息，以及基于多个版本业务的业务请求数量确定业务请求数量变化信息；以及适配度确定模块用于基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，以便于基于业务开发资源适配度分配业务开发资源。

根据本公开的实施例，架构关联信息确定模块具体用于按照版本确定业务请求数量以及以下至少一种：复用服务数量、更新服务数量和新增服务数量；变化信息确定模块具体用于基于多个版本业务的复用服务数量确定复用服务数量变化信息，和/或，基于多个版本业务的更新服务数量确定更新服务数量变化信息，和/或，基于多个版本业务的新增服务数量确定新增服务数量变化信息；以及上述装置还包括：开发便捷度确定模块，该开发便捷度确定模块用于基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种，以及业务请求数量变化信息确定服务开发便捷度，以基于服务开发便捷度调整服务开发资源。

根据本公开的实施例，评估装置还包括：多变化信息确定模块、热点度确定模块和资源分配模块。其中，多变化信息确定模块用于确定多个业务的业务请求数量变化信息；热点度确定模块用于基于多个业务的业务请求数量变化信息确定业务的热点度；以及资源分配模块，用于基于业务的热点度分配业务开发资源。

根据本公开的实施例，评估装置还包括：匹配度确定模块和匹配模块，其中，匹配度确定模块用于确定热点度大于等于热点阈值的业务与业务架构中热点业务的匹配度；以及匹配模块用于基于热点业务的匹配度确定互联网金融技术架构与业务架构的匹配度。

本公开的另一方面提供了一种电子设备，包括一个或多个处理器以及存储装置，其中，存储装置用于存储可执行指令，可执行指令在被处理器执行时，实现如上的所述方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，计算机程序包括计算机可执行指令，指令在被执行时用于实现如上所述的方法。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的互联网金融技术架构评估方法、装置、电子设备和介质的应用场景；

图2示意性示出了根据本公开实施例的可以应用互联网金融技术架构评估方法、装置、电子设备和介质的示例性系统架构；

图3示意性示出了根据本公开实施例的互联网金融技术架构评估方法的流程图；

图4示意性示出了根据本公开实施例的互联网金融技术架构的评估中间结果示意图；

图5示意性示出了根据本公开另一实施例的互联网金融技术架构的评估中间结果示意图；

图6示意性示出了根据本公开另一实施例的互联网金融技术架构评估方法的流程图；

图7示意性示出了根据本公开另一实施例的互联网金融技术架构评估方法的流程图；

图8示意性示出了根据本公开实施例的互联网金融技术架构评估装置的框图；以及

图9示意性示出了根据本公开实施例的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。

本公开实施例提供了一种互联网金融技术架构评估方法、装置、电子设备和介质。该评估方法包括变化信息确定过程和适配度确定过程。在变化信息确定过程中，首先，确定互联网金融技术架构的架构关联信息，其中，架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量，然后，基于多个版本业务的服务数量确定服务数量变化信息，以及基于多个版本业务的业务请求数量确定业务请求数量变化信息。在完成变化信息确定过程后进入适配度确定过程，基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，以便于基于业务开发资源适配度分配业务开发资源。

图1示意性示出了根据本公开实施例的互联网金融技术架构评估方法、装置、电子设备和介质的应用场景。

如图1所示，为基于业务架构构建的互联网技术(IT)架构，该IT架构可以包括应用模型和数据模型，其中，应用模型包括逻辑应用和物理应用，逻辑应用为基于业务架构的逻辑设计的应用，物理应用为实际落地应用(即实际的服务、数据等)。例如，物理应用可以包括交易服务(简称ATS)、组件服务(简称ACS)和对象服务(简称BOS)，交易服务通过交互组件(包括交互界面、导航、输入输出组件、以及交互组件与交易服务之间的调用关系等)为用户提供服务，如查询、支付等，一个交易服务对应实体与服务之间的一次交互动作。组件服务用于组装对象服务，以供交易服务调用。对象服务用于封装业务规则，以基于业务规则对数据集合中与实体相关的数据进行读操作和/或写操作，可以实现服务与数据解耦。数据模型包括数据对象和数据实体。其中，物理应用是否能和逻辑应用对应起来，需要通过检测进行验证，以确保商业银行战略的顺利落地执行。此外，在业务开发过程中，需要投入大量的研发资源，如人力资源、资金资源等，如何使得投入的研发资源与当前的IT架构的待加强业务和商业银行战略相匹配，也成为亟待解决的问题。

本公开实施例提供的互联网金融技术架构评估方法、装置、电子设备和介质，为金融科技部门客观、合理地评价各业务的发展情况，以及科技资源投入，科技便捷开发能力分析提供分析方法与参考依据。

图2示意性示出了根据本公开实施例的可以应用互联网金融技术架构评估方法、装置、电子设备和介质的示例性系统架构。需要注意的是，图2所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图2所示，根据该实施例的系统架构200可以包括终端设备201、202、203，网络204和服务器205。网络204可以包括多个网关、路由器、集线器、网线等，用以在终端设备201、202、203和服务器205之间提供通信链路的介质。网络204可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备201、202、203通过网络204与其他终端设备和服务器205进行交互，以接收或发送信息等，如接收服务请求、发送处理结果等。终端设备201、202、203可以安装有各种通讯客户端应用，例如银行类应用、政务类应用、监控类应用、网页浏览器应用、搜索类应用、办公类应用、即时通信工具、邮箱客户端、社交平台软件等应用(仅为示例)。

终端设备201、202、203包括但不限于智能手机、虚拟现实设备、增强现实设备、平板电脑、膝上型便携计算机等等。

服务器205可以接收请求，并对请求进行处理。例如，服务器205可以为后台管理服务器、服务器集群等。后台管理服务器可以对接收到的信息请求(如业务开发资源适配度请求)、模型管理请求等进行分析处理，并将处理结果(如业务开发资源适配度信息、业务开发资源分配建议信息、模型处理的结果等)反馈给终端设备。

需要说明的是，本公开实施例所提供的构建方法一般可以由服务器205执行。相应地，本公开实施例所提供的构建装置一般可以设置于服务器205中。本公开实施例所提供的构建方法也可以由不同于服务器205且能够与终端设备201、202、203和/或服务器205通信的服务器或服务器集群执行。

应该理解，终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图3示意性示出了根据本公开实施例的互联网金融技术架构评估方法的流程图。

在一个实施例中，互联网金融技术架构包括至少一个版本，每个版本的互联网金融技术架构支持至少一个业务，每个版本的互联网金融技术架构的各业务包括至少一个服务，对于互联网金融技术架构的一个业务，如图3所示，该由服务器端执行的互联网金融技术架构评估方法可以包括操作S301～操作S305。

在操作S301，确定互联网金融技术架构的架构关联信息，架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量。

在本实施例中，可以通过统计、查询等方式确定互联网金融技术架构的架构关联信息。例如，可以对业务的业务请求历史数据进行查询、统计等得到多个版本业务的业务请求数量。又例如，可以对互联网金融技术架构中的服务进行统计，得到服务的数量，然后根据服务所属的业务再次进行分类统计，即可得到多个版本业务的服务数量。此外，还可以针对互联网架构建立架构关联信息数据库，该架构关联信息数据库为实时更新的数据库，通过查询该架构关联信息数据库即可得到所需的架构关联信息。

在操作S303，基于多个版本业务的服务数量确定服务数量变化信息，以及基于多个版本业务的业务请求数量确定业务请求数量变化信息。

图4示意性示出了根据本公开实施例的互联网金融技术架构的评估中间结果示意图。

如图4所示，可以基于操作S301得到的架构关联信息确定版本1至版本4的IT架构中，业务1至业务4分别包括的服务数量和各自的业务请求量。图4示出的图表为便于理解本公开的技术方案，对数据进行图表化处理后得到的，服务器端可以无需进行上述图表化处理，直接对数据进行处理。当然，用户通过客户端向服务器端发送上述数量变化信息请求时，为了使得查询结果更加直观，也可以对上述数量变化信息进行图表化处理，并将上述数量变化信息和可视化图表发送给客户端。

在操作S305，基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，以便于基于业务开发资源适配度分配业务开发资源。

参考图4所示，由于业务请求数量(参考图4中曲线：业务1、业务2、业务3和业务4)能表征用户对该业务的需求热度，对于需求热度高的业务，用户群体越大，服务所需应对的用户习惯差异、文化差异等越多，相应地也需要投入更多业务开发资源以支持业务需求。此外，对于需求热度高的业务，也更容易演化出延伸业务需求，同样需要投入更多业务开发资源以支持业务需求。因此，可以基于服务数量变化量和业务请求数量变化量等确定业务开发资源与当前IT架构和服务数量的适配度。例如，当业务请求数量在持续上升，且改变量大于第一阈值时，可以确定该业务的服务数量的第一范围和服务数量新增量的第二范围，如果该业务的当前服务数量和/或新增量不处于上述第一范围和上述第二范围，则可以确定业务开发资源适配度不满足需求，可以通过增加针对该业务投入的业务开发资源或者减少针对该业务投入的业务开发资源，来使得业务开发资源与当前IT架构和服务数量相适配。其中，上述第一范围和上述第二范围仅为示例性说明，还可以设置更多个范围来细化管理。上述第一范围和上述第二范围可以是通过实验(如基于针对多种业务的用户体验度和业务的服务数量等确定)、标定(如由专家标定业务对应的第一范围和第二范围)、仿真模拟或统计(如按照业务领域统计一些成熟度高的业务的服务数量)等方法确定的，在此不做限定。

需要说明的是，不同业务的业务请求数量也能反映出各业务的热度，可以基于不同业务的业务请求数量调整分配给各业务的业务开发资源。如图4中业务3的业务热度较低，但是服务的数量较多，可以减少对业务3投入的业务开发资源。

在一个具体实施例中，基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度包括：基于业务服务比基线、业务请求数量和服务数量变化信息确定业务开发资源适配度。其中，业务服务比基线为针对不同业务的业务服务数量和业务请求数量比值的均值，该均值可以体现针对某个业务的业务服务数量和业务请求数量比例的合理值，可以通过上述实验、标定、仿真模拟或统计等方式确定。具体地，由于不同的业务可能在不同的区域的启动的时间不同，可以针对同一业务在用户使用成熟地域的业务服务比基线作为新启动该业务的区域的业务服务比基线。

参考图4所示，业务1的业务请求数量较多，属于热点业务，其包括的服务数量的变化趋势基本与业务请求数量的变化趋势相符合，且在业务请求数量出现下降后，业务服务数量没有明显上涨，可以看出其业务开发资源的投入基本合理。业务2投入的业务服务数量比较对等。业务3的业务请求数量一直处于低位，但是，对应的业务服务数量过多，占用过多的资源，需要进行调整。业务4处于平稳状态。

本公开实施例提供的互联网金融技术架构评估方法，基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，使得可以基于业务开发资源适配度分配业务开发资源，提升业务开发资源分配的合理性，提高投入产出比。

在另一个实施例中，为了进一步提升业务开发资源分配的合理性。可以对业务服务进行细化，根据细化结果来确定业务开发便捷度。

具体地，细化结果可以如下所示，各版本业务包括复用服务或者复用服务以及以下至少一种：更新服务和新增服务。

相应地，确定互联网金融技术架构的架构关联信息可以包括：按照版本确定业务请求数量以及以下至少一种：复用服务数量、更新服务数量和新增服务数量。

基于多个版本业务的服务数量确定服务数量变化信息可以包括：基于多个版本业务的复用服务数量确定复用服务数量变化信息，和/或，基于多个版本业务的更新服务数量确定更新服务数量变化信息，和/或，基于多个版本业务的新增服务数量确定新增服务数量变化信息。

图5示意性示出了根据本公开另一实施例的互联网金融技术架构的评估中间结果示意图。

如图5所示，各业务在各个版本的业务请求数量可以表征用户需求变化的频度。

各业务在各个版本的服务复用数量(基础服务量、复用服务量)，新增服务数量、修改服务数量可以表征研发便捷度。如上所述，IT架构包括交易服务、组件服务和对象服务，其中，对象服务用于封装业务规则，以基于业务规则对数据集合中与实体相关的数据进行操作。组件服务用于组装对象服务，以供交易服务调用。交易服务通过调用组件服务实现业务功能，并将业务功能的处理结果输出给交互组件，其中，一个交易服务对应实体与服务之间的一次交互动作。这种封装调用的IT架构，包括多个可以复用的组件服务，可以复用的组件服务覆盖的业务领域越大，则在开发新业务或对已有业务进行迭代更新时，可以直接调用上述可以复用的组件服务来实现新业务或对业务进行迭代更新，而无需再重新开发该新业务或新功能的业务组件，有效地降低业务开发用时和资源消耗。

具体地，可以根据业务请求数量变化趋势、新增服务占比、修改服务占比等，分析该业务便捷研发的程度。特别是在业务发展频繁变化的情况下，复用服务(即上述可以复用的组件服务)越多，或者既有服务修改量占比较少，说明便捷开发的成熟度越高。

同时，多个业务之间比对服务数量的值，可以分析业务频繁变化的热点领域，便于确定投入的业务开发资源是否满足了业务发展需求。

相应地，上述方法还包括：在确定互联网金融技术架构的架构关联信息之后，基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种，以及业务请求数量变化信息确定服务开发便捷度，以基于服务开发便捷度调整服务开发资源。

如图5所示，业务1和业务4的复用服务的数量和占比都在提升，表明业务开发便捷度在不断提升。业务4的业务开发环境最优。

业务2和业务3的复用服务占比也在提升，但是提升较缓慢，且存在较多新增服务，有待继续优化IT架构的复用服务。业务1至业务3中存在大量修改服务，这表明已有的复用服务中存在不合适的组件服务，该组件服务需要进行细化，得到核心组件服务，提升其复用率，且降低复用服务的修改率。需要说明的是，复用服务的确定过程是一个不断迭代的过程，当发现新业务的开发过程中，相关的组件服务不能直接调用(不能完全适配)时，则表明该相关的组件服务的粒度可能过大，还可以进一步进行细化，提高该相关的组件服务的复用率，提升开发便捷度。

在一个实施例中，基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种，以及业务请求数量变化信息确定服务开发便捷度包括：基于第一服务开发便捷度和/或第二服务开发便捷度确定服务开发便捷度。

其中，第一服务开发便捷度是基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种与业务请求数量变化信息的比值确定的。如业务请求数量大量增加时，新增服务数量没有大量增加，而复用服务数量大量增加，则表明服务开发便捷度较高，无需新开发大量新增服务即可实现新业务或新功能的开发。

第二服务开发便捷度是基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种与服务数量变化信息的比值确定的。如上述实施例中，新增服务数量与业务服务数量的比值，可以体现服务开发便捷度。

图6示意性示出了根据本公开另一实施例的互联网金融技术架构评估方法的流程图。

如图6所示，对于各版本的互联网金融技术架构的多个业务，评估方法还可以包括操作S601～操作S605。

在操作S601，确定多个业务的业务请求数量变化信息。

在操作S603，基于多个业务的业务请求数量变化信息确定业务的热点度。

在操作S605，基于业务的热点度分配业务开发资源。

具体地，业务请求数量的变化信息可以反映出该业务的用户需求度的变化信息，对于新增业务请求数量高的业务，可以多分配一些业务开发资源，进行新功能的开发、业务信息交互便捷度改善、功能优化等以满足用户需求。

图7示意性示出了根据本公开另一实施例的互联网金融技术架构评估方法的流程图。

如图7所示，评估方法还可以包括：在执行操作S603：基于多个业务的业务请求数量变化信息确定业务的热点度之后，还可以包括操作S701～操作S703。

在操作S701，确定热点度大于等于热点阈值的业务与业务架构中热点业务的匹配度。

业务架构构建过程中，会存在顶层设计的战略性业务，这些业务应该是热点业务。IT架构中热点业务是否与上述战略性业务相吻合，需要进行检测。

在操作S703，基于热点业务的匹配度确定互联网金融技术架构与业务架构的匹配度。

如果IT架构中的热点业务与业务架构中的热点业务相吻合，则表明IT架构能满足商业银行的战略性需求，否则，需要对IT架构进行调整，使得IT架构与业务架构相适配。当IT架构与业务架构相适配时，便于采用统一的方法、统一的语言、统一的机制、统一的系统来管理业务架构和IT架构，实现商业银行业务架构、IT架构各类资产的统一管理和集中维护，并最终确保商业银行战略的顺利落地执行。

本公开的另一方面提供了一种互联网金融技术架构评估装置。

图8示意性示出了根据本公开实施例的互联网金融技术架构评估装置的框图。如图8所示，该评估装置800可以包括：架构关联信息确定模块810、变化信息确定模块820和适配度确定模块830。

其中，架构关联信息确定模块810用于确定互联网金融技术架构的架构关联信息，架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量。

变化信息确定模块820用于基于多个版本业务的服务数量确定服务数量变化信息，以及基于多个版本业务的业务请求数量确定业务请求数量变化信息。

适配度确定模块830用于基于服务数量变化信息和业务请求数量变化信息确定业务开发资源适配度，以便于基于业务开发资源适配度分配业务开发资源。

具体地，架构关联信息确定模块810具体用于按照版本确定业务请求数量以及以下至少一种：复用服务数量、更新服务数量和新增服务数量。

变化信息确定模块820具体用于基于多个版本业务的复用服务数量确定复用服务数量变化信息，和/或，基于多个版本业务的更新服务数量确定更新服务数量变化信息，和/或，基于多个版本业务的新增服务数量确定新增服务数量变化信息。

相应地，上述装置800还可以包括：开发便捷度确定模块。

其中，开发便捷度确定模块用于基于复用服务数量变化信息、更新服务数量变化信息和新增服务数量变化信息中至少一种，以及业务请求数量变化信息确定服务开发便捷度，以基于服务开发便捷度调整服务开发资源。

在另一个实施例中，评估装置800还包括：多变化信息确定模块、热点度确定模块和资源分配模块。

其中，多变化信息确定模块用于确定多个业务的业务请求数量变化信息。

热点度确定模块用于基于多个业务的业务请求数量变化信息确定业务的热点度。

资源分配模块用于基于业务的热点度分配业务开发资源。

在另一个实施例中，评估装置800还可以包括：匹配度确定模块和匹配模块。

匹配度确定模块用于确定热点度大于等于热点阈值的业务与业务架构中热点业务的匹配度。

匹配模块用于基于热点业务的匹配度确定互联网金融技术架构与业务架构的匹配度。

需要说明的是，装置部分实施例中各模块/单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再一一赘述。

根据本公开的实施例的模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，架构关联信息确定模块810、变化信息确定模块820和适配度确定模块830中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，架构关联信息确定模块810、变化信息确定模块820和适配度确定模块830中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，架构关联信息确定模块810、变化信息确定模块820和适配度确定模块830中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图9示意性示出了根据本公开实施例的电子设备的方框图。图9示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，根据本公开实施例的电子设备900包括处理器901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。处理器901例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 903中，存储有电子设备900操作所需的各种程序和数据。处理器901、ROM902以及RAM 903通过总线904彼此通讯连接。处理器901通过执行ROM 902和/或RAM 903中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除ROM 902和RAM 903以外的一个或多个存储器中。处理器901也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备900还可以包括输入/输出(I/O)接口905，输入/输出(I/O)接口905也连接至总线904。电子设备900还可以包括连接至I/O接口905的以下部件中的一项或多项：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被处理器901执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 902和/或RAM 903和/或ROM 902和RAM 903以外的一个或多个存储器。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (5)

1.一种由服务器端执行的互联网金融技术架构评估方法，其中，所述互联网金融技术架构包括至少一个版本，每个版本的互联网金融技术架构支持至少一个业务，每个版本的互联网金融技术架构的各业务包括至少一个服务，所述方法包括：对于互联网金融技术架构的一个业务，

确定互联网金融技术架构的架构关联信息，所述架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量；

所述确定互联网金融技术架构的架构关联信息包括：

按照版本确定业务请求数量以及以下至少一种：复用服务数量、更新服务数量和新增服务数量；

基于多个版本业务的服务数量确定服务数量变化信息包括：

基于多个版本业务的复用服务数量确定复用服务数量变化信息，和/或，基于多个版本业务的更新服务数量确定更新服务数量变化信息，和/或，基于多个版本业务的新增服务数量确定新增服务数量变化信息；以及

在确定互联网金融技术架构的架构关联信息之后，基于所述复用服务数量变化信息、所述更新服务数量变化信息和所述新增服务数量变化信息中至少一种，以及所述业务请求数量变化信息确定服务开发便捷度，以基于所述服务开发便捷度调整服务开发资源；

基于所述多个版本业务的服务数量确定服务数量变化信息，以及基于所述多个版本业务的业务请求数量确定业务请求数量变化信息；

基于所述服务数量变化信息和所述业务请求数量变化信息确定业务开发资源适配度，以便于基于所述业务开发资源适配度分配业务开发资源；其中，所述基于所述服务数量变化信息和所述业务请求数量变化信息确定业务开发资源适配度包括：

基于业务服务比基线、所述业务请求数量和所述服务数量变化信息确定业务开发资源适配度，其中，所述业务服务比基线用于表征业务服务数量和业务请求数量比值的均值；

各版本业务包括复用服务或者复用服务以及以下至少一种：更新服务和新增服务；

对于各版本的互联网金融技术架构的多个业务，

确定所述多个业务的业务请求数量变化信息；

基于所述多个业务的业务请求数量变化信息确定业务的热点度；

在基于所述多个业务的业务请求数量变化信息确定业务的热点度之后，

确定热点度大于等于热点阈值的业务与业务架构中热点业务的匹配度；以及

基于所述热点业务的匹配度确定所述互联网金融技术架构与所述业务架构的匹配度；以及

基于所述业务的热点度分配业务开发资源。

2.根据权利要求1所述的评估方法，其中，所述基于所述复用服务数量变化信息、所述更新服务数量变化信息和所述新增服务数量变化信息中至少一种，以及所述业务请求数量变化信息确定服务开发便捷度包括：

基于第一服务开发便捷度和/或第二服务开发便捷度确定所述服务开发便捷度；其中，

所述第一服务开发便捷度是基于所述复用服务数量变化信息、所述更新服务数量变化信息和所述新增服务数量变化信息中至少一种与所述业务请求数量变化信息的比值确定的；以及

所述第二服务开发便捷度是基于所述复用服务数量变化信息、所述更新服务数量变化信息和所述新增服务数量变化信息中至少一种与所述服务数量变化信息的比值确定的。

3.一种互联网金融技术架构评估装置，包括：

架构关联信息确定模块，用于确定互联网金融技术架构的架构关联信息，所述架构关联信息包括多个版本业务的服务数量，以及多个版本业务的业务请求数量；所述架构关联信息确定模块具体用于按照版本确定业务请求数量以及以下至少一种：复用服务数量、更新服务数量和新增服务数量；变化信息确定模块具体用于基于多个版本业务的复用服务数量确定复用服务数量变化信息，和/或，基于多个版本业务的更新服务数量确定更新服务数量变化信息，和/或，基于多个版本业务的新增服务数量确定新增服务数量变化信息；以及所述装置还包括：开发便捷度确定模块，用于基于所述复用服务数量变化信息、所述更新服务数量变化信息和所述新增服务数量变化信息中至少一种，以及所述业务请求数量变化信息确定服务开发便捷度，以基于所述服务开发便捷度调整服务开发资源；

变化信息确定模块，用于基于所述多个版本业务的服务数量确定服务数量变化信息，以及基于所述多个版本业务的业务请求数量确定业务请求数量变化信息；

适配度确定模块，用于基于所述服务数量变化信息和所述业务请求数量变化信息确定业务开发资源适配度，以便于基于所述业务开发资源适配度分配业务开发资源；

多变化信息确定模块，用于确定所述业务请求数量变化信息；

热点度确定模块，用于基于所述业务请求数量变化信息确定业务的热点度；

资源分配模块，用于基于所述业务的热点度分配业务开发资源；

匹配度确定模块，用于确定热点度大于等于热点阈值的业务与业务架构中热点业务的匹配度；以及

匹配模块，用于基于所述热点业务的匹配度确定所述互联网金融技术架构与所述业务架构的匹配度。

4.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现根据权利要求1～2任一项所述的方法。

5.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时实现根据权利要求1～2中任一项所述的方法。

Images