CN115629740B - 一种架构管理平台的架构模型 - Google Patents

Abstract

本发明提出的一种架构管理平台的架构模型，属于信息技术领域，包括：企业层，用于根据企业业务目标，建立企业级IT目标、架构原则、决策和技术规范；分区层，用于根据企业业务主题，对系统进行解构分层；根据企业级IT目标，形成IT能力主题；子系统层，用于进一步分解系统，利用逻辑应用组件承接业务应用，利用逻辑子系统承接业务组件并根据IT主题进行整体设计；功能组件层，用于将系统进一步分解为逻辑功能组件和逻辑构件；构件层，用于根据实际系统构建和运营操作控制的要求，建立逻辑功能构件，数据表和物理功能构件。本发明能够实现架构服务的数字化、可视化，摆脱每个系统定制的方式，提升业务连续性。

Description

一种架构管理平台的架构模型

技术领域

本发明涉及信息技术领域，更具体的说是涉及一种架构管理平台的架构模型。

背景技术

软件架构用来处理软件高层次结构的设计与实施，它以精心选择的形式将若干结构元素进行装配，从而满足系统的主要功能和性能需求。软件架构设计的首要问题是如何表示系统架构，即如何对软件架构建模。常用的架构模型可以归类为三种架构模型：3/N层架构、“框架＋插件”架构、地域分布式架构。

随着数字化转型带来的更大IT管理规模、更复杂企业级IT架构、更频繁业务与IT变更、更短时间要求，架构资产的数字化建设的必要性愈发突显。现有的架构模型多以文档等非结构化形式，存在更新不及时、数据不联动、效果不直观以及业务、开发、运维脱节，管控和实施的脱节，设计和录入脱节等问题。

发明内容

针对现有技术中存在的问题，本发明的目的在于提供一种架构管理平台的架构模型，能够将业务能力、交易实现、服务配置、运维方式等进行有机的结合，实现架构服务的数字化、可视化，从标准模型的视角形成切换方案，摆脱每个系统定制的方式，提升业务连续性。

本发明为实现上述目的，通过以下技术方案实现：

一种架构管理平台的架构模型，包括：企业层、分区层、子系统层、功能组件层和构件层。所述企业层，用于根据企业业务目标，建立企业级IT目标、架构原则、决策和技术规范；所述分区层，用于根据企业业务主题，对系统进行解构分层；根据企业级IT目标，形成IT能力主题；所述子系统层，用于在分区层对系统进行解构分层的基础上，进一步分解系统，利用逻辑应用组件承接业务应用，利用逻辑子系统承接业务组件并根据IT主题进行整体设计；所述功能组件层，用于将系统进一步分解为逻辑功能组件和逻辑构件；所述构件层，用于根据实际系统构建和运营操作控制的要求，建立逻辑功能构件，数据表和物理功能构件。

进一步，所述企业层包括：

企业业务系统，用于定义业务系统的总体目标和驱动要素；

企业逻辑IT系统，用于定义企业IT目标和企业架构原则；

企业物理IT 系统，用于定义业务系统的部署与运行保障策略；

业务控制系统，用于定义业务系统的业务连续性体系。

进一步，所述分区层包括：

业务领域设置单元，用于设置构成业务系统的业务能力、组织单元、流程对象的业务领域和产品对象的生产线；

分层单元，用于通过应用建模和数据建模对业务系统进行分类，生成技术规范、IT解决方案、分层设计、元数据分类和数据应用模型；

分部单元，用于根据运行节点对象对业务系统的运行区域进行划分，并根据功能对业务系统划分为多个功能分区；

布局单元，用于对业务系统进行两地三中心布局，并进行数据中心定位，根据布局结果运行业务系统。

进一步，所述子系统层包括：

分解单元，用于将产品对象分解为基础产品，将流程对象分解为用户视角业务领域、业务组件和C模型；

逻辑子系统，用于将分层单元的分类结果分解为逻辑业务子系统，生产逻辑应用、现状系统迁移策略、数据架构领域中元数据的细化部分和逻辑业务子系统模型；

物理子系统，用于运营节点分解为物理业务子系统和物理子系统部署实例，将功能分区对象分解为资源池；技术服务和技术组件；

物理子系统运行单元，用于物理子系统的部署，并生成物料子系统多中心部署结果。

进一步，所述功能组件层包括：

事件建模单元，用于对分解单元的分解结果进行事件建模，生成流程对象的事件、活动、任务，以及产品对象的产品组件；

逻辑功能组件，用于将逻辑应用细化为应用事件、系统工作流和系统用例，将逻辑业务子系统细化为服务、接口、批量数据传输、逻辑功能组件、响应码；

部署单元，用于将物理子系统部署实例细化为基础设施部署单元及应用和数据部署单元，将资源池对象细化为部署节点；

部署运行单元，用于建立部署单元与存储有运行脚本的软件包的关系，以进行部署运行控制。

进一步，所述构件层包括：

解析单元，用于通过对象细化分解机制将产品对象分解为产品条件、将流程对象分解为步骤；

逻辑构件，用于将逻辑功能组件分解为逻辑构建，根据逻辑业务子系统的数据生产数据库表；

物理构件，用于将部署单元细化为软硬件产品和配置数据；

配置单元，用于获取部署单元运行控制的配置数据和参数。

进一步，所述分区层，还用于根据横向的业务主题和能力映射的C模型以及纵向的数据架构相关规范、原则，形成C’模型；所述子系统层，还用于根据横向的组件与C模型的实体关系矩阵以及纵向的C模型，形成子系统C模型的关系矩阵及服务清单；所述功能组件层和构件层，还用于根据横向任务和数据实体CRU关系矩阵和纵向子系统C模型的关系矩阵及服务清单生成子系统数据流图、数据接口清单和数据表结构。

进一步，所述分区层和子系统层，还用于通过逻辑子系统转化为物理子系统基于两地三中心、逻辑业务子系统的功能分布，识别物理子系统所属部署实例、分析物理子系统部署实例与运营节点关系、分析每个部署实例承载逻辑子系统功能的所需资源、预估物理子系统的运维管理；所述功能组件层，还用于生成逻辑子系统的部署方案，包括基础设施资源池和云服务之前的访问关系；所述构件层，还用于根据逻辑部署方案生成物理部署方案、设备清单、软件清单、参考实施规范形成基础设施参数配置清单和应用层参数配置清单。

对比现有技术，本发明有益效果在于：本发明提供了一种架构管理平台的架构模型，通过建立IT4IT模型、四态五层框架，能够从概念态、逻辑态、物理态到运行态满足业务需求，纵向按照五层分解，进行自顶向下的逐层深化设计；实现了业务、体验、应用、数据、技术、安全各架构一体化，并分别对应到四态五层框架；通过数据和流程模型梳理，实现了企业级架构资产复用。

本发明通过建立IT4IT模型，采用统一的语言、统一的标准，真正做到“书同文、车同轨”，使业务、架构、开发、运维能相互理解、有效衔接。

本发明通过一套管理流程、一套实施工艺实现全生命周期的标准化管控，将业务能力、交易实现、服务配置、运维方式等进行有机的结合，实现架构服务的数字化、可视化，从架构的视角阐述业务连续性，从标准模型的视角形成切换方案，摆脱每个系统定制的方式，提升业务连续性。

本发明以架构服务作为驱动力，从资源供给、应用的组装交付、数据治理、安全管控、业务连续性、运维管理及应急处置等场景，提供全视角、全链路、全透明的管控和服务能力。

本发明实现了模型标准的统一化，相关专业团队可以在一套语言体系、一个架构平面下对话，互相理解，互为补充；架构资产通过全链路、全生命周期、穿透式的管理模式和技术手段，概念态、逻辑态、物理态、运行态的数据互为参照，可信度高。在此基础上，结合图表、拓扑等可视化的呈现，逐级的钻取、切换等交互操作，版本、交易线、两地三中心部署架构、配置以及告警、变更、发布等运行态信息的集成，充分释放架构资产价值；同时也促进IT人员的架构意识，推动架构管理数字化的生态建设。

由此可见，本发明与现有技术相比，具有突出的实质性特点和显著的进步，其实施的有益效果也是显而易见的。

附图说明

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

图1是本发明具体实施方式的模型结构图。

图中，1、企业层；2、分区层；3、子系统层；4、功能组件层；5、构件层；11、企业业务系统；12、企业逻辑IT系统；13、企业物理IT系统；14、业务控制系统；21、业务领域设置单元；22、分层单元；23、分部单元；24、布局单元；31、分解单元；32、逻辑子系统；33、物理子系统；34、物理子系统运行单元；41、事件建模单元；42、逻辑功能组件；43、部署单元；44、部署运行单元；51、解析单元；52、逻辑构件；53、物理构件；54、配置单元。

具体实施方式

下面结合附图对本发明的具体实施方式做出说明。

如图1所示的一种架构管理平台的架构模型，包括：企业层1、分区层2、子系统层3、功能组件层4和构件层5。

企业层1，用于根据企业业务目标，建立企业级IT目标、架构原则、决策和技术规范。

具体的，企业层1包括：企业业务系统11、企业逻辑IT系统12、企业物理IT系统13和业务控制系统14。

企业业务系统11，用于定义业务系统的总体目标和驱动要素。

企业逻辑IT系统12，用于定义企业IT目标和企业架构原则。

企业物理IT 系统13，用于定义业务系统的部署与运行保障策略。

业务控制系统14，用于定义业务系统的业务连续性体系。

分区层2，用于根据企业业务主题，对系统进行解构分层；根据企业级IT目标，形成IT能力主题。

具体的，分区层2包括：业务领域设置单元21、分层单元22、分部单元23和布局单元24。

业务领域设置单元21，用于设置构成业务系统的业务能力、组织单元、流程对象的业务领域和产品对象的生产线。

分层单元22，用于通过应用建模和数据建模对业务系统进行分类，生成技术规范、IT解决方案、分层设计、元数据分类和数据应用模型。

分部单元23，用于根据运行节点对象对业务系统的运行区域进行划分，并根据功能对业务系统划分为多个功能分区。

布局单元24，用于对业务系统进行两地三中心布局，并进行数据中心定位，根据布局结果运行业务系统。

子系统层3，用于在分区层对系统进行解构分层的基础上，进一步分解系统，利用逻辑应用组件承接业务应用，利用逻辑子系统承接业务组件并根据IT主题进行整体设计。

具体的，子系统层3包括：分解单元31、逻辑子系统32、物理子系统33和物理子系统运行单元34。

分解单元31，用于将产品对象分解为基础产品，将流程对象分解为用户视角业务领域、业务组件和C模型。

逻辑子系统32，用于将分层单元的分类结果分解为逻辑业务子系统，生产逻辑应用、现状系统迁移策略、数据架构领域中元数据的细化部分和逻辑业务子系统模型。

物理子系统33，用于运营节点分解为物理业务子系统和物理子系统部署实例，将功能分区对象分解为资源池；技术服务和技术组件。

物理子系统运行单元34，用于物理子系统的部署，并生成物料子系统多中心部署结果。

功能组件层4，用于将系统进一步分解为逻辑功能组件和逻辑构件。

具体的，功能组件层4包括：事件建模单元41、逻辑功能组件42、部署单元43和部署运行单元44。

事件建模单元41，用于对分解单元的分解结果进行事件建模，生成流程对象的事件、活动、任务，以及产品对象的产品组件。

逻辑功能组件42，用于将逻辑应用细化为应用事件、系统工作流和系统用例，将逻辑业务子系统细化为服务、接口、批量数据传输、逻辑功能组件、响应码。

部署单元43，用于将物理子系统部署实例细化为基础设施部署单元及应用和数据部署单元，将资源池对象细化为部署节点。

部署运行单元44，用于建立部署单元与存储有运行脚本的软件包的关系，以进行部署运行控制。

构件层5，用于根据实际系统构建和运营操作控制的要求，建立逻辑功能构件，数据表和物理功能构件。

具体的，构件层5包括：解析单元51、逻辑构件52、物理构件53和配置单元54。

解析单元51，用于通过对象细化分解机制将产品对象分解为产品条件、将流程对象分解为步骤。

逻辑构件52，用于将逻辑功能组件分解为逻辑构建，根据逻辑业务子系统的数据生产数据库表。

物理构件53，用于将部署单元细化为软硬件产品和配置数据。

配置单元54，用于获取部署单元运行控制的配置数据和参数。

作为示例的，从数据架构视角来看，在本发明公开的架构管理平台的架构模型中，分区层2还用于根据横向的业务主题和能力映射的C模型以及纵向的数据架构相关规范、原则，形成C’模型；子系统层3还用于根据横向的组件与C模型的实体关系矩阵以及纵向的C模型，形成子系统C模型的关系矩阵及服务清单；功能组件层4和构件层5还用于根据横向任务和数据实体CRU关系矩阵和纵向子系统C模型的关系矩阵及服务清单生成子系统数据流图、数据接口清单和数据表结构。

作为示例的，从数据架构视角来看，在本发明公开的架构管理平台的架构模型中，分区层2和子系统层3，还用于通过逻辑子系统转化为物理子系统基于两地三中心、逻辑业务子系统的功能分布，识别物理子系统所属部署实例、分析物理子系统部署实例与运营节点关系、分析每个部署实例承载逻辑子系统功能的所需资源、预估物理子系统的运维管理；功能组件层4，还用于生成逻辑子系统的部署方案，包括基础设施资源池和云服务之前的访问关系；构件层5，还用于根据逻辑部署方案生成物理部署方案、设备清单、软件清单、参考实施规范形成基础设施参数配置清单和应用层参数配置清单。

作为示例的，从安全架构视角来看，在本发明公开的架构管理平台的架构模型中，分区层2还用于形成安全架构的能力清单、解决方案。子系统层3，还用于形成子系统级的安全架构清单。功能组件层4和构件层5，还用于形成功能组件、构建层的安全架构视图和关系矩阵。

本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中如U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质，包括若干指令用以使得一台计算机终端（可以是个人计算机，服务器，或者第二终端、网络终端等）执行本发明各个实施例所述方法的全部或部分步骤。本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于终端实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例中的说明即可。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统、系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，系统或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。

同理，在本发明各个实施例中的各处理单元可以集成在一个功能模块中，也可以是各个处理单元物理存在，也可以两个或两个以上处理单元集成在一个功能模块中。

结合附图和具体实施例，对本发明作进一步说明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所限定的范围。

Claims (3)

1.一种架构管理平台的架构模型，其特征在于，包括：企业层、分区层、子系统层、功能组件层和构件层；

所述企业层，用于根据企业业务目标，建立企业级IT目标、架构原则、决策和技术规范，具体包括：企业业务系统，用于定义业务系统的总体目标和驱动要素；企业逻辑IT系统，用于定义企业IT目标和企业架构原则；企业物理IT 系统，用于定义业务系统的部署与运行保障策略；业务控制系统，用于定义业务系统的业务连续性体系；

所述分区层，用于根据企业业务主题，对系统进行解构分层；根据企业级IT目标，形成IT能力主题，具体包括：业务领域设置单元，用于设置构成业务系统的业务能力、组织单元、流程对象的业务领域和产品对象的生产线；分层单元，用于通过应用建模和数据建模对业务系统进行分类，生成技术规范、IT解决方案、分层设计、元数据分类和数据应用模型；分部单元，用于根据运行节点对象对业务系统的运行区域进行划分，并根据功能对业务系统划分为多个功能分区；布局单元，用于对业务系统进行两地三中心布局，并进行数据中心定位，根据布局结果运行业务系统；

所述子系统层，用于在分区层对系统进行解构分层的基础上，进一步分解系统，利用逻辑应用组件承接业务应用，利用逻辑子系统承接业务组件并根据IT主题进行整体设计，具体包括：分解单元，用于将产品对象分解为基础产品，将流程对象分解为用户视角业务领域、业务组件和C模型；逻辑子系统，用于将分层单元的分类结果分解为逻辑业务子系统，生产逻辑应用、现状系统迁移策略、数据架构领域中元数据的细化部分和逻辑业务子系统模型；物理子系统，用于运营节点分解为物理业务子系统和物理子系统部署实例，将功能分区对象分解为资源池；技术服务和技术组件；物理子系统运行单元，用于物理子系统的部署，并生成物料子系统多中心部署结果；

所述功能组件层，用于将系统进一步分解为逻辑功能组件和逻辑构件，具体包括：事件建模单元，用于对分解单元的分解结果进行事件建模，生成流程对象的事件、活动、任务，以及产品对象的产品组件；逻辑功能组件，用于将逻辑应用细化为应用事件、系统工作流和系统用例，将逻辑业务子系统细化为服务、接口、批量数据传输、逻辑功能组件、响应码；部署单元，用于将物理子系统部署实例细化为基础设施部署单元及应用和数据部署单元，将资源池对象细化为部署节点；部署运行单元，用于建立部署单元与存储有运行脚本的软件包的关系，以进行部署运行控制；

所述构件层，用于根据实际系统构建和运营操作控制的要求，建立逻辑功能构件，数据表和物理功能构件，具体包括：解析单元，用于通过对象细化分解机制将产品对象分解为产品条件、将流程对象分解为步骤；逻辑构件，用于将逻辑功能组件分解为逻辑构建，根据逻辑业务子系统的数据生产数据库表；物理构件，用于将部署单元细化为软硬件产品和配置数据；配置单元，用于获取部署单元运行控制的配置数据和参数。

2.根据权利要求1所述的架构管理平台的架构模型，其特征在于：

所述分区层，还用于根据横向的业务主题和能力映射的C模型以及纵向的数据架构相关规范、原则，形成C’模型；

所述子系统层，还用于根据横向的组件与C模型的实体关系矩阵以及纵向的C模型，形成子系统C模型的关系矩阵及服务清单；

所述功能组件层和构件层，还用于根据横向任务和数据实体CRU关系矩阵和纵向子系统C模型的关系矩阵及服务清单生成子系统数据流图、数据接口清单和数据表结构。

3.根据权利要求1所述的架构管理平台的架构模型，其特征在于：

所述分区层和子系统层，还用于通过逻辑子系统转化为物理子系统基于两地三中心、逻辑业务子系统的功能分布，识别物理子系统所属部署实例、分析物理子系统部署实例与运营节点关系、分析每个部署实例承载逻辑子系统功能的所需资源、预估物理子系统的运维管理；

所述功能组件层，还用于生成逻辑子系统的部署方案，包括基础设施资源池和云服务之前的访问关系；

所述构件层，还用于根据逻辑部署方案生成物理部署方案、设备清单、软件清单、参考实施规范形成基础设施参数配置清单和应用层参数配置清单。

Images