基于业务能力的中台系统构建方法、装置、设备和介质

技术领域

本申请涉及中台技术领域，特别是涉及一种基于业务能力的中台系统构建方法、装置、设备和介质。

背景技术

随着业务不断发展，很多组织（例如企业等）的业务种类越来越多，为了支撑前台越来越多的业务，通常会在后台不断建设庞大的系统，然而，此举导致后台越发不稳定，反而无法对业务的变化进行快速响应，并且在不断建设过程中，也存在大量的重复建设以及资源浪费的问题。目前，很多组织通过在前台与后台之间搭建中台来解决上述问题，其中，中台类似一个为前台和后台提供服务的公共服务平台。

然而，目前的中台普遍存在服务无法有效、及时地支撑业务需求的问题。

发明内容

本申请针对上述不足或缺点，提供了一种基于业务能力的中台系统构建方法、装置、设备和介质，本申请实施例能够使中台服务有效、及时地支撑业务需求。

本申请根据第一方面提供了一种基于业务能力模型的中台系统构建方法，在一些实施例中，该方法包括：

获取目标对象的目标业务模式相关的所有业务能力的定义数据；

根据上述所有业务能力的定义数据构建业务能力模型；

根据业务能力模型为每一业务能力制定对应的服务；每一业务能力对应一项或多项服务；

根据业务能力模型为每一业务能力对应的服务开发服务代码以及配置运行环境；

对每一服务的服务代码进行测试，完成中台系统的构建。

在一些实施例中，获取目标对象的目标业务模式相关的所有业务能力的定义数据之前，方法还包括：

确定目标业务模式的业务流程和关键活动；

根据业务流程和关键活动确定目标业务模式相关的所有业务能力。

在一些实施例中，根据业务流程和关键活动确定目标业务模式相关的所有业务能力之后，方法还包括：

使用预先指定的业务能力框架对目标业务模式相关的所有业务能力进行定义，得到上述所有业务能力的定义数据。

在一些实施例中，根据上述所有业务能力的定义数据构建业务能力模型，包括

对上述所有业务能力进行层次划分和关系梳理，确定各业务能力对应的层次以及各业务能力之间的关系；层次用于描述不同粒度和细节程度的业务能力；关系用于描述业务能力间的相互关联、依赖或互动；

根据业务功能、业务流程或专业领域对上述所有业务能力进行归类，确定各业务能力对应的类别；

基于各业务能力对应的层次、类别以及各业务能力之间的关系进行业务能力建模，得到业务能力模型。

在一些实施例中，对上述所有业务能力进行归类，包括：

根据业务功能、业务流程或专业领域对上述所有业务能力进行归类。

在一些实施例中，根据业务能力模型为每一业务能力制定对应的服务，包括：

获取预设需求数据，预设需求数据包括复用性需求数据、独立性需求数据、可拓展性需求数据中的一项或多项；

根据业务能力模型中的业务能力层次确定服务颗粒度；

根据预设需求数据、服务颗粒度为每一业务能力制定对应的服务；

定义映射矩阵，通过映射矩阵记录各业务能力和各服务间的对应关系。

在一些实施例中，上述方法还包括：对构建好的中台系统进行优化。

在一些实施例中，测试包括以下的一项或多项：业务场景模拟测试；业务能力覆盖率检查；性能测试和安全测试。

在一些实施例中，优化包括以下的一项或多项：根据定期收集的业务团队反馈数据对相关服务进行优化；定期回顾与调整业务能力模型；为服务开发用于业务能力扩展和变化的接口和/或模块。

在一些实施例中，通过微服务架构和服务网格为每一业务能力对应的服务开发服务代码。

在一些实施例中，完成中台系统的构建之后，上述方法还包括：

对历史业务能力模型进行调整，得到当前业务能力模型；

对比当前业务能力模型和历史业务能力模型，根据对比结果确定调整幅度；或，检测是否出现特定事件，根据检测结果确定调整幅度；调整幅度为微调、中度调整或大规模调整；

若调整幅度为微调或中度调整，则对调整范围内的业务能力对应的服务进行设计；

若调整幅度为大规模调整，则重新设计当前业务能力模型中的所有业务能力对应的服务。

本申请根据第二方面提供了一种基于业务能力模型的中台系统构建装置，在一些实施例中，该装置包括：

定义数据获取模块，用于获取目标对象的目标业务模式相关的所有业务能力的定义数据；

模型构建模块，用于根据上述所有业务能力的定义数据构建业务能力模型；

服务制定模块，用于根据业务能力模型为每一业务能力制定对应的服务；每一业务能力对应一项或多项服务；

开发模块，用于根据业务能力模型为每一业务能力对应的服务开发服务代码以及配置运行环境；

测试优化模块，用于对每一服务的服务代码进行测试，完成中台系统的构建。

本申请根据第三方面提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任一实施例中提供的基于业务能力模型的中台系统构建方法的步骤。

本申请根据第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一实施例中提供的基于业务能力模型的中台系统构建方法的步骤。

在本申请的上述实施例中，在构建中台系统时，先根据对目标对象的目标业务模式进行解析而获得的各种业务能力的定义数据来构建业务能力模型，以实现对该目标业务模式相关的业务能力的变化进行充分考虑，之后根据该业务能力模型来为各业务能力制定对应的服务，以及为各种服务开发相应的代码和配置相应的运行环境，并对各服务的代码进行测试和优化，从而完成中台系统的构建，使得构建好的中台系统中的各项服务能有效、及时地支撑业务需求。

附图说明

图1为本申请根据一个或多个实施例提供的一种基于业务能力模型的中台系统构建方法的流程示意图；

图2为本申请根据一个或多个实施例提供的确定业务能力的流程示意图；

图3为本申请根据一个或多个实施例提供的构建业务能力模型的流程示意图；

图4为本申请根据一个或多个实施例提供的为业务能力制定服务的流程示意图；

图5为本申请根据一个或多个实施例提供的一种基于业务能力模型的中台系统构建装置的结构框图；

图6为本申请根据另一个或多个实施例提供的一种基于业务能力模型的中台系统构建装置的结构框图；

图7为本申请根据一个或多个实施例提供的计算机设备的内部结构图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施例方式作进一步地详细描述。应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请的描述中，需要理解的是，术语“第一”、“第二”、“第三”等仅用于区别类似的对象，而不必用于描述特定的顺序或先后次序，也不能理解为指示或暗示相对重要性。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

目前的中台系统普遍存在系统中的服务无法有效、及时地支撑业务需求的问题。发明人意识到该问题主要是因为目前在设计中台服务（即中台系统中的服务）时，没有充分考虑到业务能力的变化而导致的，基于此，本申请提供了一种基于业务能力模型的中台系统构建方法，该方法通过在中台系统的构建过程引入业务能力模型，通过业务能力模型来制定中台服务，从而使设计好的中台服务能够有效、及时地支撑业务需求。

具体地，在当今世界，各个企业面临着激烈的市场竞争，以及快速变化的业务环境，企业需要对其业务模式进行持续的优化和创新以应对这些挑战。在这种背景下，业务架构（business structure，BA）成为企业用来理解、设计和优化其业务模式的关键工具。其中，业务能力模型是业务架构中重要的一环，它能描述企业执行其业务所需要的全部能力，能帮助企业了解其业务的运作方式，确定优化方向，并提供持久的业务视图。发明人意识到可以利用业务能力模型的特性来帮助设计中台服务，通过将业务能力作为中台服务的设计基础，使得中台服务能够根据业务能力的变化进行快速调整，进而使得目标对象能够更好地应对快速变化的业务环境，能够有效、及时地支撑业务需求。需要说明的是，尽管业务能力模型在企业管理和改进中起着重要的作用，然而，目前的业务能力模型通常不会考虑中台服务的设计和实现，如何利用业务能力模型来设计中台服务进而完成中台系统的构建是需要克服的困难。针对该困难，本申请实施例也相应提供了一套完整的、可操作的操作流程，能够指导目标对象在实际操作中根据业务能力模型构建中台系统。

下面通过一些实施例来对该方法进行详细说明。

请参见图1，图1所示为该方法包括的步骤，即步骤S110至S150，该方法可以由服务器来执行。以下是对该方法的各步骤的说明。

S110：获取目标对象的目标业务模式相关的所有业务能力的定义数据。

目标对象是指需要构建中台系统的对象，目标对象通常有复杂的业务需求，因而需要构建中台系统。目标对象可以是企业、学校、机构等组织。中台系统是为目标对象的前台系统和后台系统提供服务的公共服务系统。

目标对象可以有一种或多种业务模式，目标业务模式可以是目标对象的其中一种业务模式。

业务能力是指目标对象在特定领域内完成相关任务的能力，例如，以目标对象是电网企业为例，该业务能力可以包括发电、输配电和供电等等。目标对象的业务通常可以划分为多个领域，特定领域是指其中的某一个或若干个领域。

业务能力的定义数据是预先定义好的，业务能力的定义数据可以存于数据库中，当需要构建中台系统时，从数据库中获取。

在一些实施例中，获取目标对象的目标业务模式相关的所有业务能力的定义数据之前，如图2所示，该方法还包括：

S101：确定目标业务模式的业务流程和关键活动；

S102：根据业务流程和关键活动确定目标业务模式相关的所有业务能力。

在业务能力的定义数据之前，需要确定出与目标对象的目标业务模式相关的所有业务能力。可以通过对目标对象的目标业务模式进行深度解析，进而确定该目标业务模式的业务流程和关键活动，利用该业务流程和关键活动确定出所有可能的业务能力，作为目标业务模式相关的所有业务能力。

相应地，根据业务流程和关键活动确定目标业务模式相关的所有业务能力之后，该方法还包括：使用预先指定的业务能力框架对目标业务模式相关的所有业务能力进行定义，得到上述所有业务能力的定义数据。

其中，可以使用诸如TOGAF（The Open Group Architecture Framework）、BIZBOK（Guide to the Business Architecture Body of Knowledge，业务架构知识体系指南）、APQC（American Productivity and Quality Center，美国生产力和质量中心）等的业务能力框架来识别业务能力以及描述业务能力，从而实现对所有可能的业务能力进行收集和分类。其中，在定义业务能力时，需要使每个业务能力有清晰的定义和预期的输出，该定义和输出的相关数据即是上述的业务能力的定义数据。例如，业务能力“电网维护与修复”，其定义可以是“负责电网的日常维护和突发事件（如故障、自然灾害等）后的快速修复”，预期输出可以是“减少故障发生率，缩短故障修复时间，确保电网的稳定运行”。又例如，业务能力“智能电表管理”，其定义可以是“通过智能电表收集用户用电数据，进行数据分析和用电行为预测”，预期输出可以是“准确地收集和管理用户用电数据，提供用电行为分析，优化电力供应计划”。

S120：根据上述所有业务能力的定义数据构建业务能力模型。

该业务能力模型可以选用成熟可靠且合适的构建方式来进行构建。例如，采用业务架构和组织变革中相对常见的，定义-分类分层-关系建模-评估优化的流程来构建模型。

在一些实施例中，请参见图3所示，根据上述所有业务能力的定义数据构建业务能力模型，包括：

S121：对上述所有业务能力进行层次划分和关系梳理，确定各业务能力对应的层次以及各业务能力之间的关系。

构建业务能力模型时，需要确定业务能力的层次结构和关系。

在业务能力模型中，上述的层次用于描述不同粒度和细节程度的业务能力，其能帮助目标对象理解从高层到底层的业务能力的不同细节和重要性。可以预先定义好多个层次，然后将各个业务能力划分到对应的层次中，可理解地，每个对应于高层次的业务能力会对应一个或多个对应于下一层次的业务能力。示例性地，以目标对象是电网企业，其目标业务模式对应的业务能力包括“输电”、“配电”、“跨区域输电”、“城市配电”、“变电站管理”和“电表读取”，以及该层次分为一级业务分类（也可称为宏观层次）、二级业务分类（也可称为中间层次）和三级业务分类（也可称为微观层次）为例，其中，一级业务分类用于描述目标对象的主要业务领域（或核心功能），该层次中的业务能力可以包括“输电”、“配电”等，二级业务分类用于描述该主要业务领域下的子领域（或该核心功能下的子领域）的，该层次中的业务能力可以包括“跨区域输电”、“城市配电”等，三级业务分类用于描述实际的业务活动或任务，该层次中的业务能力可以包括“变电站管理”、“电表读取”等。上述的关系用于描述业务能力间的相互关联、依赖或互动，在一些实施方式中，该关系具体包括依赖关系、互动关系和继承关系等多个类别。其中，依赖关系是指一项业务能力需要得到另一项业务能力的支持才能执行，例如“电表读取”这一业务能力需要依赖“智能监控系统”这一业务能力；互动关系是指两项或多项业务能力需要合作以完成某个任务，例如“电网维护”和“电网规划”这两项业务能力之间即存在互动关系；继承关系是指一项业务能力继承另一项业务能力的某些特性或功能，例如“特高压输电”这一业务能力继承了“输电”业务能力的特性。

S122：根据业务功能、业务流程或专业领域对上述所有业务能力进行归类，确定各业务能力对应的类别。

对上述所有业务能力进行归类的方式有多种，可以根据实际需求来选择合适的方式进行实施，并且还可以根据实际情况进行调整和优化所选用的归类方式。

在一些实施方式中， 可以将上述的所有业务能力按照其所属的业务功能进行分类和整理。例如，以电网企业为例，可以将所有业务能力相应划分为诸如“输电”、“发电”、“供电”等业务功能上。通过按照业务功能来对所有业务能力进行归类，可以帮助目标对象从整体上把握各项业务能力，并为持续改进和协调发展提供依据。

在另一些实施方式中，可以将上述的所有业务能力按照其在业务流程中的作用和关系进行分类和整理。目标对象在执行目标业务模式下的业务时，各个业务活动往往是相互依赖、相互影响的，按照业务流程来对业务能力进行归类，可以将目标对象的业务执行过程划分为不同的业务流程，以电网企业为例，可以包括发电流程、输电流程、用户用电流程等。通过按照业务流程来对所有业务能力进行归类，可以帮助目标对象更好地理解和组织目标业务模式下的各项业务活动，提高业务的执行效率和质量。

在又一些实施方式中，可以将上述的所有业务能力按照其所属的专业领域进行分类和整理。具体地，在目标对象的运作过程中，存在许多不同的专业领域。例如，以电网企业为例，可以包括“电力”、“智慧电网”等专业领域。通过按照专业领域来对所有业务能力进行归类，可以帮助目标对象在各个专业领域中更好地发展业务能力，提高业务水平和市场竞争力。

上述归类方式能够为构建清晰、结构化的业务能力模型提供框架。

此外，通过对业务能力进行合理划分和归类，可以优化资源的使用，在后续的为业务能力制定服务以及开发、测试、优化服务代码的环节中，能够起到减少冗余服务的开发和维护、节省开发和运营成本的效果。

S123：基于各业务能力对应的层次、类别以及各业务能力之间的关系进行业务能力建模，得到业务能力模型。

其中，可以使用诸如Archimate（一种整合多种架构的可视化业务分析模型语言）、UML（Unified Modeling Language，统一建模语言）、BPMN（Business Process ModelingNotation，业务流程建模标注）等建模工具来构建业务能力模型。

通过上述步骤所构建的业务能力模型主要包含以下几个部分：

（1）业务能力层次结构：这部分数据用于明确各个业务能力的层次关系，例如，从一级业务分类（例如“输电”或“配电”）到二级业务分类（例如“跨区域输电”和“城市配电”）再到三级业务分类（例如“变电站管理”和“电表读取”）。

（2）业务能力定义数据：包含每个业务能力的定义以及预期输出。

（3）业务能力间的关系：这部分数据用于描述业务能力之间如何相互关联、依赖或互动。该关系的种类例如可以包括依赖关系、互动关系和继承关系。

（4）业务流程映射：用于显示业务能力是如何嵌入到整个业务流程中的，比如从“发电”到“输电”到“用户用电”。

（5）业务能力的归类：包含每个业务能力对应的按照指定的归类方式（如按业务功能、业务流程或专业领域的划分方式）确定的类别。

在一些实施例中，为了便于目标对象了解哪些业务能力是关键能力，在构建模型时，可以为各业务能力标注表示优先级或重要性的信息，因此，构建好的模型还包括（6）优先级或重要性标注数据，其中包括每个业务能力对应的优先级或重要性。

进一步地，在构建模型时若有使用特定的建模工具，如上述的Archimate，则构建好的模型中还包括（7）工具相关的元素和/或标记。

本实施例基于各业务能力对应的层次、类别以及各业务能力之间的关系来构建业务能力模型，有助于使各业务能力及其对应的服务之间的对应关系清晰明了，这种明确性能帮助目标对象更好地理解其业务能力，并清楚地知道如何通过中台服务来实现其业务能力。

S130：根据业务能力模型为每一业务能力制定对应的服务；每一业务能力对应一项或多项服务。

本步骤需要根据业务能力模型来设计中台服务，具体是将抽象的业务能力模型中的各个业务能力转化为相应的实际可运行使用的服务。在一些实施方式中，根据业务能力模型为每一业务能力制定对应的服务，如图4所示，包括：

S131：获取预设需求数据，预设需求数据包括复用性需求数据、独立性需求数据、可拓展性需求数据中的一项或多项；

S132：根据业务能力模型中的业务能力层次确定服务颗粒度；

S133：根据预设需求数据、服务颗粒度为每一业务能力制定对应的服务；

S134：定义映射矩阵，通过映射矩阵记录各业务能力和各服务间的对应关系。

设计中台服务时，需要考虑多种因素，例如复用性、独立性、可拓展性等因素。其中，复用性是指设计的中台服务能够在多种场景下使用；独立性是指服务之间是松耦合的，某一服务发生变更时不会影响到其他服务的正常运行；可拓展性是指随着业务的变化和增长，容易为服务增加新的功能或进行修改。上述的复用性需求数据包括一个或多个业务能力对应的关于复用性的描述数据；独立性需求数据包括一个或多个业务能力对应的关于独立性的描述数据；可拓展性需求数据包括一个或多个业务能力对应的关于可拓展性的描述数据。

例如，关于业务能力“电表读取”，假设该业务能力对应服务S1“智能电表数据采集”和服务S2“电表数据异常检测”，各需求数据可以是：

复用性：服务S1和服务S2可以用于居民和工业用电场景；

独立性：服务S1和服务S2是松耦合的，两者能独立进行；

可拓展性：服务S2可以随时添加新的异常检测算法。

又例如，关于业务能力“电网维护”，假设该业务能力对应服务S3“定期维护计划生成”和服务S4“故障响应与修复”，各需求数据可以是：

复用性：服务S3和服务S4适用于各种规模和类型的电网；

独立性：服务S3的维护计划变更不会影响服务S4的故障响应机制；

可拓展性：服务S4可以增加新的故障类型和修复方案。

本实施例在利用业务能力模型设计中台服务时，不仅考虑了如功能完备、性能优良等服务的功能性因素，还考虑了如复用性、独立性、可拓展性等服务的非功能性因素，有助于提高后续开发的服务代码的质量。

本实施例还根据业务能力的层次来确定服务的颗粒度，业务能力的层次也可称为业务能力层次。在设计中台服务时，由于考虑到业务能力的层次，能够使设计出的中台服务在不同层次上支持业务流程，提升了业务处理的灵活性。

可以将所有业务能力的集合记为B={B1,B2,...,Bn}，将所有服务的集合记为S={S1,S2,...,Sm}，集合B中的业务能力和集合S中的服务之间的对应关系可以通过定义好的大小为n×m的映射矩阵 M 来表示，其中，如果业务能力Bi 对应到服务Sj，那么Mij=1；否则Mij=0。对于每一个业务能力Bi，其对应的服务集合为：SBi={Sj∣Mij=1,1≤j≤m}。业务能力Bi 可能与一个或多个服务Sj 对应，为了实现Bi需要SBi中的所有服务。

进一步地，业务能力的层次 L 与服务颗粒度的对应关系可以表示为：Pk=1/ Lk。其中，Pk表示服务的颗粒度（Pk的值越大，其表示的颗粒度越小，反之，Pk的值越小，其表示的颗粒度越大），Lk表示业务能力的层次（Lk的值越大，其表示的层次越高，反之，Lk的值越小，其表示的层次越低）。通过该公式可知，业务能力的层次越高，相应的服务颗粒度越大。

例如，以业务能力“电表读取”为例，先确定其对应的业务能力的层次，假设其对应的层次是三级业务分类（本示例共有三个业务能力层次，从高到低分别是一级业务分类、二级业务分类和三级业务分类），其对应的层次是三级业务分类，因而在制定其对应的服务时，需设定其对应的服务的颗粒度相对较小，以使得其对应的服务能聚焦于特定任务。为其制定的服务可以如下所示：

高层次服务：用电数据管理（这是一个宽泛的服务，可以包括数据收集、存储、分析等）；

中层次服务：电表数据采集与分析；

微观层次服务：智能电表数据采集、电表数据异常检测。

又例如，业务能力“电网维护”，由于它涉及电网的整体运营，因而通常归于较高的层次，如一级或者二级业务分类，因此，其对应的服务的颗粒度相对较大。为其制定的服务可以如下所示：

高层次服务：电网运营管理（可以包括维护、规划、监控等）；

中层次服务：电网维护策略规划、故障响应管理；

微观层次服务：定期维护计划生成、故障响应与修复。

S140：根据业务能力模型为每一业务能力对应的服务开发服务代码以及配置运行环境。

其中，在一些实施方式中，可以引入以业务能力为驱动的开发方法来为服务开发代码，进而确保代码的结构和逻辑与业务能力紧密匹配。

在另一些实施方式中，考虑到业务能力模型是使用业务术语来进行描述，而技术实现却更注重系统架构和编程接口，因而利用业务能力模型设计中台服务时，容易出现业务能力模型和技术实现之间映射不准确的问题；此外，业务能力模型可能涉及多个业务领域和数据源，如何保证数据的同源性以及事务的完整性也是亟需解决的问题，为此，本实施方式采用微服务架构和服务网格来对每个业务能力对应的服务进行单独设计和开发，其中，采用微服务架构进行开发时，允许将一个复杂应用程序分解为多个独立运行的微服务，每个微服务都是单一的和可独立部署的，这意味着不同的微服务可能使用不同的数据源和数据库；而服务网格是一种用于处理服务到服务之间的通信的基础设施层，在微服务架构中，不同的服务可能需要访问不同的数据源或参与同一事务，为此，使用服务网格来帮助管理复杂的数据流和事务。本实施方式通过采用微服务架构和服务网格来开发各业务能力对应的服务，能够实现准确地将抽象的业务能力模型转化为实际可运行的服务，以及确保多个操作（通常是数据操作）能作为一个单一的工作单元被正确、完整地执行，即工作单元中的所有操作要么完全不被执行，要么完全被执行，并且执行后能保证数据的一致性。该运行环境具体可以包括服务代码运行所需的（1）计算机硬件设备（如处理器、内存、存储空间等）、（2）操作系统（如Linux、Unix等）、（3）依赖库和/或软件框架、（4）网络设置和配置（如网络协议、端口号等）、（5）其他服务或API接口等等。

S150：对每一服务的服务代码进行测试，完成中台系统的构建。

上述的测试包括以下的一项或多项：业务场景模拟测试；业务能力覆盖率检查；性能测试和安全测试。其中，业务场景模拟测试可以模拟实际的业务操作，确保服务能够在各种场景下满足业务需求；业务能力覆盖率检查可以检查已实现的服务是否覆盖了所有预定的业务能力；性能测试需要基于核心业务流程进行，可以确保服务在高峰业务时期的服务能力不受影响；安全测试可以对服务代码进行评估和验证，以发现潜在的安全漏洞、弱点和风险，以便预防和应对可能出现的安全威胁和攻击。

在构建好中台系统之后，可以定期对构建好的中台系统进行优化。其中，优化包括以下的一项或多项：

（1）根据定期收集的业务团队反馈数据对相关服务进行优化。通过与业务团队进行合作，定期收集团队人员的反馈数据，以便根据定期收集的业务团队反馈数据对相关服务进行针对性优化。

（2）定期回顾与调整业务能力模型。随着业务的发展，定期回顾和调整业务能力模型，可以确保服务与业务保持同步。

（3）为服务开发用于业务能力扩展和变化的接口和/或模块。对于可能的业务能力扩展和变化，设计服务时预留相应的接口和模块，便于未来的扩展和调整。

在本实施例中，需要对每一项服务都进行严格测试和优化，以保证各项服务能在各种情况下保持稳定运行，进而提高中台系统的稳定性和可靠性。

此外，本实施例以业务能力为导向，使得服务设计和业务目标紧密相连，这使得服务更易于管理和维护。业务人员通过业务能力模型可以直观地理解服务的功能和目标，而技术人员也可以通过业务能力模型更好地理解和维护服务。

进一步地，在一些实施例中，完成中台系统的构建之后，上述方法还包括：

对历史业务能力模型进行调整，得到当前业务能力模型；

对比当前业务能力模型和历史业务能力模型，根据对比结果确定调整幅度；或，检测是否出现特定事件，根据检测结果确定调整幅度；调整幅度为微调、中度调整或大规模调整；

若调整幅度为微调或中度调整，则对调整范围内的业务能力对应的服务进行设计；

若调整幅度为大规模调整，则重新设计当前业务能力模型中的所有业务能力对应的服务。

在本实施例中，考虑到目标对象的业务流程可能会发生变动，因而可以定期或不定期地对业务能力模型进行调整（即重新构建），通过持续性地对业务能力模型进行迭代，有助于使中台服务能持续地支持复杂、多变的业务流程。其中，可以再次执行S101-S102以及S110-S120的相关操作来重新构建业务能力模型。

该特定事件包括多种事件。在一些实施方式中，确定调整幅度的操作可以是，判断是否出现第一特定事件（该事件可以是预先设定好的，如企业战略调整或业务重组等事件），若是，则判定调整幅度是大规模调整，若否，则进一步判断是否出现第二特定事件（该事件可以是预先设定好的，如引入新的业务领域、业务能力出现合并和拆分的数量或在全部业务能力中的占比超过预设阈值等），如果是，则判定调整幅度是中度调整；如果不是，则判断是否出现第三特定事件（该事件同样可预先设定好，如，业务能力的定义数据出现更新、新增了优先级或重要性不高的业务能力等），如果判断出现第三特定事件，则判定调整幅度是微调，如果判断未出现第三特定事件，则判定不进行调整。

在另一些实施方式中，在调整业务能力模型之后，可以将历史业务能力模型和当前业务能力模型，即调整前和后的两个业务能力模型进行对比，以确定调整幅度。例如，可以通过对比来确定当前业务能力模型中的出现变更的业务能力（如新增的业务能力、更新了定义或预期输出的业务能力等）的数量和/或在所有业务能力中的占比，将该数量和/或占比和各个调整幅度对应的阈值（包括数量的阈值和/或占比的阈值）进行比较，判断该数量和/或占比是否都超过各个调整幅度对应的阈值（包括数量的阈值和/或占比的阈值），基于判断结果确定调整幅度。例如，调整幅度同样包括微调、中度调整和大规模调整，以数量为例，假设微调、中度调整和大规模调整对应的数量阈值分别是a、b、c，其中，0

其中，调整幅度可以预先定义多个，各个调整幅度设置有相应的处理逻辑，从而在确定出调整幅度后，可以执行对应的处理逻辑。例如，调整幅度可以包括微调（即小范围调整）、中度调整和大规模调整。

如果确定出的调整幅度是微调，相应的处理逻辑可以是对调整范围内的业务能力对应的服务进行设计（如制定和开发、重新制定和开发等）；如果确定出的调整幅度是中度调整，则可以只对调整范围内的业务能力对应的服务进行设计（如制定和开发、重新制定和开发等）；如果确定出的调整幅度是大规模调整，则可以重新设计当前所有业务能力对应的服务。

需要说明的是，关于上述任何一个实施例中提供的基于业务能力模型的中台系统构建方法所包括的各个步骤，除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，这些步骤中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

基于相同的发明构思，本申请还提供了一种基于业务能力模型的中台系统构建装置，该装置能执行上述实施例所提供的基于业务能力模型的中台系统构建方法。在一些实施例中，如图5所示，该装置包括以下模块：

定义数据获取模块110，用于获取目标对象的目标业务模式相关的所有业务能力的定义数据；

模型构建模块120，用于根据上述所有业务能力的定义数据构建业务能力模型；

服务制定模块130，用于根据业务能力模型为每一业务能力制定对应的服务；每一业务能力对应一项或多项服务；

开发模块140，用于根据业务能力模型为每一业务能力对应的服务开发服务代码以及配置运行环境；

测试模块150，用于对每一服务的服务代码进行测试，完成中台系统的构建。

在一些实施例中，上述装置还包括能力确定模块（图中未示出）。能力确定模块，用于在定义数据获取模块110获取目标对象的目标业务模式相关的所有业务能力的定义数据之前，确定目标业务模式的业务流程和关键活动；以及根据业务流程和关键活动确定目标业务模式相关的所有业务能力。

在一些实施例中，能力定义模块（图中未示出）。能力定义模块，用于在能力确定模块根据业务流程和关键活动确定目标业务模式相关的所有业务能力之后，使用预先指定的业务能力框架对目标业务模式相关的所有业务能力进行定义，得到上述所有业务能力的定义数据。

在一些实施例中，模型构建模块120，包括：

划分和梳理子模块，用于对上述所有业务能力进行层次划分和关系梳理，确定各业务能力对应的层次以及各业务能力之间的关系；层次用于描述不同粒度和细节程度的业务能力；关系用于描述业务能力间的相互关联、依赖或互动；

归类子模块，用于根据业务功能、业务流程或专业领域对上述所有业务能力进行归类，确定各业务能力对应的类别；

建模子模块，用于基于各业务能力对应的层次、类别以及各业务能力之间的关系进行业务能力建模，得到业务能力模型。

在一些实施例中，归类子模块，具体用于根据业务功能、业务流程或专业领域对上述所有业务能力进行归类。

在一些实施例中，服务制定模块130，包括：

获取子模块，用于获取预设需求数据，预设需求数据包括复用性需求数据、独立性需求数据、可拓展性需求数据中的一项或多项；

确定子模块，用于根据业务能力模型中的业务能力层次和颗粒度确定服务层次和颗粒度；

服务制定子模块，用于根据预设需求数据、服务层次和颗粒度为每一业务能力制定对应的服务；

记录子模块，用于定义映射矩阵，通过映射矩阵记录各业务能力和各服务间的对应关系。

在一些实施例中，如图6所示，上述装置还包括优化模块160。优化模块160，用于对构建好的中台系统进行优化。

在一些实施例中，测试包括以下的一项或多项：业务场景模拟测试；业务能力覆盖率检查；性能测试和安全测试。

在一些实施例中，优化包括以下的一项或多项：根据定期收集的业务团队反馈数据对相关服务进行优化；定期回顾与调整业务能力模型；为服务开发用于业务能力扩展和变化的接口和/或模块。

在一些实施例中，开发模块140，用于通过微服务架构和服务网格为每一业务能力对应的服务开发服务代码。

在一些实施例中，上述装置还包括调整迭代模块（图中未示出），调整迭代模块，用于：

对历史业务能力模型进行调整，得到当前业务能力模型；

对比当前业务能力模型和历史业务能力模型，根据对比结果确定调整幅度；或，检测是否出现特定事件，根据检测结果确定调整幅度；调整幅度为微调、中度调整或大规模调整；

若调整幅度为微调或中度调整，则对调整范围内的业务能力对应的服务进行设计；

若调整幅度为大规模调整，则重新设计当前业务能力模型中的所有业务能力对应的服务。

关于基于业务能力模型的中台系统构建装置的具体限定可以参见上文中对于基于业务能力模型的中台系统构建方法的限定，在此不再赘述。上述基于业务能力模型的中台系统构建装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

本申请在一些本实施例中还提供了一种计算机设备，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时可以实现上述任一实施例中提供的基于业务能力模型的中台系统构建方法的步骤。

在一些实施例中，该计算机设备的内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储各业务能力的定义数据等数据，具体存储的数据还可以参见上述方法实施例中的限定。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于业务能力模型的中台系统构建方法。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

本申请在另一些实施例中还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一实施例中提供的基于业务能力模型的中台系统构建方法的步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

本领域普通技术人员可以理解实现上述方法实施例中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink）、 DRAM（SLDRAM）、存储器总线（Rambus）、直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。