A structured management method for agile business architecture system

Abstract

This invention belongs to the field of software technology and provides a structured management method for agile business architecture systems. The method includes: forming a design-state architecture based on the hierarchical type of the business architecture system; deploying and maintaining the business architecture system based on the design-state architecture to form a runtime architecture; designing a structured standard model for the design-state architecture during its design phase; managing configuration items in the runtime state through automated and manual data collection; establishing a ledger-based recording standard, including ledger templates and version management for both design-state and runtime states; and establishing a visual verification standard to achieve timed comparison and difference handling between the design-state and runtime architecture versions. This invention aims to solve the problems of lacking structured management, ledger-based recording, visual management, and consistency management in the current management process of agile business system architectures.

Description

Technical Field

[0001] This invention relates to the field of software technology, and in particular to a structured management method for agile business architecture systems. Background Technology

[0002] Within financial enterprises, there are generally stable business processes based on traditional technology stacks and agile business processes based on microservices. Rapidly increasing business demands are primarily geared towards agile business processes. The architecture management of agile business systems faces the following challenges during construction:

[0003] First, there is a lack of structured management capabilities for agile business system architecture. Currently, there are significant differences in the management of agile business system architecture among various enterprises, and there is no relatively unified standard. Some enterprises divide agile system architecture based on domain models, but the granularity of the division and the information of the elements vary greatly; some enterprises manage agile system architecture according to the management ideas of stable business system architecture, which makes it impossible to reflect the characteristics and advantages of agile business system architecture.

[0004] Second, there is a lack of ledger-based recording capabilities for agile business system architecture. Currently, there are several problems with the ledger-based recording of agile business system architecture in enterprises: (1) Agile system architecture is rarely managed and recorded according to design state and operation state; (2) The management and recording of agile system architecture lacks a structured recording method and mostly adopts document recording method; (3) There is a lack of effective management of agile system architecture versions and it is not possible to track system architecture version changes well.

[0005] Third, there is a lack of visualization capabilities for agile business system architecture. According to the survey, due to management and technical reasons, few companies have implemented agile business system architecture visualization. However, architecture visualization is of great use to various roles such as architects, developers, security personnel, and operations personnel, for example, for architecture evolution, analysis of the impact of changes, and location of security attack incidents.

[0006] Fourth, there is a lack of a mechanism for comparing the design and runtime architectures of agile business systems. In actual production, due to a lack of management, the runtime architecture of a business system often changes significantly from its initial design after multiple modifications. However, the design architecture is not updated synchronously, or for various reasons, the actual architecture of some business systems does differ from the design architecture. If these differences between the design and runtime architectures are not identified and adjusted in a timely manner, they can pose hidden dangers to the business system. For example, a business system initially positioned at a lower level may undergo modifications that significantly impact production operations. If this situation is not quickly and accurately identified, and the corresponding resource support cannot keep up, it could potentially lead to production incidents. Summary of the Invention

[0007] In view of the above technical problems, this invention provides a structured management method for agile business architecture systems, aiming to solve the problems of lack of structured management, ledger-based recording, visual management, and consistency management between the design and runtime states of agile business architecture systems in the current management process. It realizes structured management, ledger recording, visual verification, and architecture consistency management of agile business architecture systems.

[0008] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0009] According to one aspect of the present invention, a structured management method for an agile business architecture system is disclosed, the method comprising:

[0010] Based on the determined hierarchical type of the business architecture system, a design-state architecture is formed. The design-state architecture includes requirements definition, architecture design, software design, development, and testing. The architecture design includes domain partitioning, component partitioning, interface definition, and data flow design. The business architecture system formed based on the design-state architecture is then deployed and maintained to form a runtime architecture.

[0011] During the design phase, the architecture is designed with a structured standard model. The standard model adopts a five-layer structure, which includes system, subsystem, application, service, and computing node in order of hierarchy. The configuration items of each layer are defined. When planning the standard model, the model instances, access logic architecture, computing node information, and the creation, modification and deletion processes of the model instances are planned.

[0012] During execution, the runtime architecture employs an automated data collection method combined with a manual data collection method to manage the configuration items involved in the service and computing nodes.

[0013] Establish ledger recording standards for the design-state architecture and the runtime architecture, including establishing principles and management specifications for ledger recording, wherein the management specifications include ledger templates and version management requirements for the design-state architecture and the runtime architecture;

[0014] Establish a visualization verification standard for the system architecture, including setting the target object for visualization, determining the data acquisition method, designing visualization elements, setting the element information of the target object for visualization, selecting visualization tools, implementing dynamic and interactive display, and using the version of the design-state architecture as the baseline version and the version of the runtime architecture as the runtime version. Establish a timed comparison mechanism between the baseline version and the runtime version. If the comparison finds that the version information is inconsistent, generate a version difference work order and execute the processing.

[0015] Furthermore, when building and managing the design state, the following operations are performed:

[0016] Requirements analysis includes one or more of the following: business requirements, user requirements, system requirements definition, functional requirements, non-functional requirements, security requirements, technical requirements, data requirements, integration requirements, testability requirements, change management requirements, priorities, and dependencies.

[0017] Architecture design includes the relationships between the system, subsystems, and applications;

[0018] Interface definition, including: defining the interaction interfaces between different components or services;

[0019] Technology selection includes choosing the appropriate technology stack and tools for development.

[0020] Furthermore, when building and managing the runtime state, the following operations are performed:

[0021] Deployment environment: The designed software components are deployed to the production environment. The runtime architecture includes the access architecture and the deployment architecture. The access architecture represents the access relationships between various components within the business system, and the deployment architecture represents how the business system architecture is deployed in the environment.

[0022] Configure system parameters according to the needs of the operating environment;

[0023] Monitoring and optimization: Based on the visual monitoring of the operational status of business systems, performance optimization and troubleshooting are performed.

[0024] Furthermore, the system configuration items include: system name, system code, service catalog and SLA, system owner, system importance level, system business positioning, system scope and boundaries, business system architecture requirements, service lifecycle, information security requirements, business continuity, resource management, and security level; the subsystem configuration items include: subsystem name, subsystem code, system owner, system importance level, subsystem functions and SLA, information security requirements, performance baseline, monitoring baseline, service window, maintenance strategy and window, user and permission management, testing strategy, and change management requirements; the application configuration items include: application name, application code, application owner, application functions and service description, application environment configuration, application security strategy, application performance indicators, application monitoring indicators, fault handling strategy, application release method, application version, and application technology stack; the service configuration items include: service name, owner, IP address, port, service interface, calling service, and called service; the computing node configuration items include: node name, IP address, owner, operating system, configuration, environment, type, and service process.

[0025] Furthermore, in the standard model, the system, the subsystem, the application, the service, and the computing node have the following relationships:

[0026] The system comprises several subsystems, each subsystem comprising several applications, each application comprising several services, and each service comprising several computing nodes;

[0027] A subsystem can only belong to one system, and an application belongs to one subsystem;

[0028] The SLA of the system affects the SLA of the subsystem;

[0029] The importance level of the system affects the importance level of the subsystem;

[0030] The system's architectural design principles influence the subsystems' requirements access principles, technology stack usage principles, data access principles, and access control principles.

[0031] The information security requirements of the system affect the security requirements and controls of the subsystems.

[0032] The system's business continuity plan affects the service windows, maintenance strategies and windows, as well as quality assurance and testing of the subsystems;

[0033] The change management requirements of the subsystem affect the application's release method, application version management, and version release history;

[0034] The performance baseline of the subsystem affects the performance metrics of the application.

[0035] The monitoring baseline of the subsystem affects the monitoring metrics of the application.

[0036] Furthermore, the specific planning process for the design-state architecture diagram includes:

[0037] Based on the positioning of the business system, planning is carried out from five levels: system, subsystem, application, service, and computing node;

[0038] In the planning process at the five levels, for each of the five levels of models, we determine the new model instances that need to be created and the existing model instances that need to be reused.

[0039] After determining the model instance, the required computing node information is calculated, including the type, configuration, and number of computing nodes.

[0040] The access logic is planned, which includes network partitions, request access links, and data links. The access logic can be represented in the computing node information to form the design state architecture diagram.

[0041] Furthermore, the configuration items involved in the runtime management service and computing nodes, and the automated and manual data collection methods employed, include:

[0042] By obtaining network link information from the operating system, the access relationships between computing nodes are calculated. At the same time, by combining the relationships between computing nodes and services in the CMDB, the calling relationships between services are calculated, and then the calling relationships between applications, between subsystems, and between systems are calculated.

[0043] By obtaining the call information between interfaces from APM and combining it with the relationship between interfaces and applications in CMDB, the call relationship between interfaces between applications can be calculated. At the same time, based on the characteristics of APM, the running path of each business request in the system architecture can be calculated.

[0044] By collecting the link relationships between computing nodes and databases or storage services in the OS, and combining them with the relationships between computing nodes and services in the CMDB, the call relationships between applications and databases or storage services can be calculated.

[0045] By using the service query interface provided by the message middleware and combining the association between the middleware, applications, and consumers recorded in the CMDB, the access relationship between applications interacting through the message middleware can be calculated.

[0046] By collecting file mount point service information from the OS and combining it with the relationship between compute nodes and applications in the CMDB, the access relationships between several applications that interact through the file mount service can be calculated.

[0047] By connecting to a data service platform or component, the computing nodes that interact with data through the data service can be obtained. Combined with the relationship between computing nodes and applications recorded in the CMDB, the applications that interact through the data service platform can be calculated.

[0048] By connecting to the CDC data synchronization tool, we can identify which databases have data synchronization tasks and, combined with the relationships between databases and applications recorded in the CMDB, calculate the inter-application access relationships that occur based on database data synchronization tasks.

[0049] Furthermore, the principles followed in the ledger-based record-keeping include:

[0050] Clearly define the objects and scope of the records. The objects to be recorded include relevant instances of the system, subsystem, application, service, and compute node. The scope of the records includes the configuration items and relationships of the system, subsystem, application, service, and compute node.

[0051] Standardize the content and format of the records. The configuration items that need to be recorded in the ledger of the system, subsystem, application, service and computing node are entered according to the preset format, and the relationship between related instances needs to be associated.

[0052] Standardizing the recording process requires providing corresponding process support when recording the creation, modification, and deletion of system, subsystem, application, service, and computing node instances in the ledger;

[0053] The standardization of ledger media requires the establishment of a unified electronic tool for ledger recording;

[0054] The ease of querying and analysis requires providing multiple methods for querying and analyzing ledger records;

[0055] Security and confidentiality are ensured by implementing corresponding security measures for accessing, recording, and modifying the ledger. These security measures include at least one of the following: role-based access control, secondary authentication, and encrypted data storage.

[0056] Furthermore, the indicator items of the ledger template in the design state include:

[0057] Initial version information, system, subsystem, application, service, compute node, version number, release date, requirement ID, developers, feature description, compatibility information, performance metrics, technology stack information, system architecture topology, physical architecture topology, deployment guidelines, rollback plan, monitoring and maintenance, test and verification results, and other notes;

[0058] The version management requirements for the ledger template in the design state include the following settings:

[0059] Initialize version specifications, define version control system, set up version change process, standardize architecture topology, version change tracking mechanism, backup and archiving.

[0060] Furthermore, the indicator items of the ledger template in the running state include:

[0061] The associated design-state version number, system, subsystem, application, service, compute node, version number, latest update time, system architecture topology, and physical architecture topology;

[0062] The runtime version management requirements include:

[0063] Implement a role-based access control model to control the configuration permissions and data collection permissions of automated data collection tools, ensuring that only authorized users can operate and maintain the tools;

[0064] After the application version is released and changes are made, the relevant service instance and compute node information is automatically collected and compared with the design architecture;

[0065] Periodically collect the service instances and compute nodes of the business system through scheduled tasks to obtain the latest runtime configuration information;

[0066] Configure tools that continuously collect runtime information appropriately and monitor their running status to ensure that the tools function properly;

[0067] Analyze and adjust automated data collection methods that impact the stability and performance of business systems;

[0068] Establish a runtime architecture version change process in the process management system. When the architecture in the design state is inconsistent with that in the runtime state, the version change and update shall be based on the architecture in the design state.

[0069] The technical solution disclosed herein has the following beneficial effects:

[0070] This method enables full lifecycle management of agile business system architecture. On the one hand, it addresses the different needs of various roles in managing agile business system architecture, such as root cause analysis, architecture evolution, and correlation impact analysis. On the other hand, by managing the consistency between the design and runtime states of agile business system architecture, it increases the tools for managing the business system, thereby contributing to improvements in stability, security, and performance of agile business systems. Attached Figure Description

[0071] Figure 1 This is a flowchart illustrating a structured management method for an agile business architecture system as described in the embodiments of this specification.

[0072] Figure 2This is a framework diagram of the design state and the running state in the embodiments of this specification;

[0073] Figure 3 This is a diagram showing the relationships between the five layers in the embodiments of this specification;

[0074] Figure 4 Create flowcharts for the examples in the embodiments of this specification;

[0075] Figure 5 This is a flowchart illustrating the changes made to examples in the embodiments of this specification;

[0076] Figure 6 This is a flowchart illustrating the deletion process in the embodiments of this specification;

[0077] Figure 7 This is a flowchart illustrating the design-state architecture version change in the embodiments of this specification;

[0078] Figure 8 This is a flowchart illustrating the runtime architecture version change in the embodiments of this specification;

[0079] Figure 9 This is a flowchart illustrating the processing of version differences in the embodiments of this specification. Detailed Implementation

[0080] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure may be practiced with one or more of the specific details omitted, or other methods, components, apparatus, steps, etc., may be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0081] Furthermore, the accompanying drawings are merely illustrative of this disclosure. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0082] like Figure 1 As shown in the embodiments of this specification, a structured management method for an agile business architecture system is provided. This method may specifically include the following steps S101 to S107:

[0083] In step S101, a design-state architecture is formed based on the determined hierarchical type of the business architecture system. The design-state architecture includes requirements definition, architecture design, software design, development, and testing. The architecture design includes domain partitioning, component partitioning, interface definition, and data flow design. The business architecture system formed based on the design-state architecture is then deployed and maintained to form a runtime architecture.

[0084] Among them, such as Figure 2 As shown, the Agile Business System Architecture Structured Management Specification aims to establish a standard system to better describe the digital architecture of an agile business system. The overall framework must be centered on the architecture lifecycle perspective, including project initiation, architecture design, development, and testing as the design phase, and deployment and operation as the runtime phase, adhering to the following principles:

[0085] Achieve full lifecycle management: Based on the entire lifecycle process, starting from product business requirements, delivering the design-state architecture to the production environment, and thus building the runtime architecture;

[0086] Build views for different roles: construct architectural features from the perspectives of business personnel, architects, developers, testers, and operations personnel;

[0087] Model and IT architecture matching: Viewing resource and service relationships from the perspective of business systems to generate application architecture, deployment architecture, and runtime architecture.

[0088] In step S102, when designing the design-state architecture, a structured standard model is designed. The standard model adopts a five-layer structure, which includes system, subsystem, application, service, and computing node in order of hierarchy, and the configuration items of each layer are defined. When planning the standard model, its model instances, access logic architecture, computing node information, and the creation, modification and deletion process of the model instances are planned.

[0089] Design-state architecture refers to the process by which architects and development teams design and plan the structure and components of a software system during software development. This stage focuses on the overall design of the system architecture, including domain partitioning, component partitioning, interface definition, and data flow design. Design-state architecture requires defining metadata models for the system, subsystems, and applications (service units), clarifying the architecture type, architecture layers, and logical relationships between services. Key activities in design-state architecture include: requirements analysis, which analyzes one or more of the following: business requirements, user requirements, system requirements, functional requirements, non-functional requirements, security requirements, technical requirements, data requirements, integration requirements, testability requirements, change management requirements, priorities, and dependencies; architecture design, including the relationships between the system, subsystems, and applications; interface definition, including defining the interaction interfaces between different components or services; and technology selection, including choosing the appropriate technology stack and tools for development.

[0090] Runtime architecture refers to the deployment and operation of a system, requiring preparation of deployment resources, cluster environment, and architecture visualization. Runtime architecture also plays a role in various operational scenarios, such as emergency switchover, fault location, health status checks, scaling up / down, and capacity prediction. Its key activities include: Deployment: Deploying the designed software components to the production environment. Runtime architecture includes access architecture and deployment architecture. The access architecture expresses the access relationships between components within a sensitive business system; the deployment architecture indicates how the sensitive business system architecture is deployed in the environment; Configuration: Configuring system parameters according to the needs of the runtime environment; Monitoring and Optimization: Monitoring the system's operational status, performing performance optimization, and troubleshooting.

[0091] In summary, the relationship between design-state and runtime architectures is as follows: Complementarity: Design-state architecture provides the blueprint and guidance for runtime architecture, while runtime architecture is the concrete implementation and verification of design-state architecture. Iteration: During software development, both design-state and runtime architectures iterate and evolve gradually based on changes in business requirements. Design-state architecture focuses more on static architectural design principles, emphasizing design according to management requirements, while runtime architecture focuses more on the dynamic behavior and performance of the system, emphasizing the discovery of the architecture running in the production environment.

[0092] In the design phase, the structured standard model of agile business system architecture can be managed using a five-layer architecture model: system, subsystem, application, service, and compute node. Specifically, a system refers to a comprehensive whole comprising several subsystems that work together to support specific business goals or missions; a subsystem is a component of the system, typically responsible for a portion of its functions or business processes; an application is a collection of resources within a subsystem, bound to specific infrastructure resources to provide specific business functions or services; a service is a collection of software processes within an application, implementing business functions through their execution; and a compute node is the infrastructure that hosts services and provides computing power, generally including cloud servers, physical machines, and containers. Therefore, each of these five layers bears different responsibilities and functions, requiring corresponding configuration management items (CI) and model relationships, as well as appropriate management standards to ensure their effective operation and maintenance.

[0093] The system configuration items include: system name, system code, service catalog and SLA, system owner, system importance level, system business positioning, system scope and boundaries, business system architecture requirements, service lifecycle, information security requirements, business continuity, resource management, and security level. The subsystem configuration items include: subsystem name, subsystem code, system owner, system importance level, subsystem functions and SLA, information security requirements, performance baseline, monitoring baseline, service window, maintenance strategy and window, user and permission management, testing strategy, and change management requirements. The application configuration items include: application name, application code, application owner, application functions and service description, application environment configuration, application security strategy, application performance indicators, application monitoring indicators, fault handling strategy, application deployment method, application version, and application technology stack. The service configuration items include: service name, owner, IP address, port, service interface, calling service, and called service. The computing node configuration items include: node name, IP address, owner, operating system, configuration, environment, type, and service process.

[0094] like Figure 3 As shown, in the standard model, the system, the subsystem, the application, the service, and the computing node have the following relationships:

[0095] The system comprises several subsystems, each containing several applications, each application containing several services, and each service containing several computing nodes. A subsystem can only belong to one system, and an application belongs to one subsystem. The system's Service Level Agreement (SLA) affects the SLA of its subsystems. The system's importance level affects the importance level of its subsystems. The system's architectural design principles affect the subsystems' requirements access principles, technology stack usage principles, data access principles, and access control principles. The system's information security requirements affect the subsystems' security requirements and controls. The system's business continuity plan affects the subsystems' service windows, maintenance strategies and windows, as well as quality assurance and testing. The subsystems' change management requirements affect the application's release methods, application version management, and version release history. The subsystems' performance baseline affects the application's performance metrics. The subsystems' monitoring baseline affects the application's monitoring metrics.

[0096] The specific planning process of the design-state architecture diagram includes: planning from five levels—system, subsystem, application, service, and computing node—based on the positioning of the business system; determining the new model instances and the existing model instances to be reused for each of the five levels; calculating the required computing node information after determining the model instances, including the type, configuration, and quantity of computing nodes; and planning the access logic, which includes network partitioning, request access links, and data links, and can be represented in the computing node information to form the design-state architecture diagram.

[0097] And, the process of creating model instances is as follows: Figure 4 As shown, the change process is as follows: Figure 5 As shown, the deletion process is as follows: Figure 6 As shown.

[0098] In step S103, the runtime architecture, during execution, employs an automated data collection method combined with a manual data collection method to manage the configuration items involved in the service and computing nodes;

[0099] The configuration items involved in the runtime management service and compute nodes, and the automated and manual data collection methods employed, include: calculating the access relationships between compute nodes using network link information obtained from the operating system; simultaneously calculating the call relationships between services by combining the relationships between compute nodes and services in the CMDB; and further calculating the call relationships between applications, subsystems, and systems; calculating the call relationships between interfaces by obtaining call information between interfaces from APM and combining it with the relationships between interfaces and applications in the CMDB; and calculating the runtime path of each business request in the system architecture based on the characteristics of APM; and calculating the connection relationships between applications and databases or storage services by combining the link relationships between compute nodes collected from the OS and the relationships between compute nodes and services in the CMDB. The system identifies the call relationships between services; by using the service query interface provided by the message middleware and combining it with the associations between middleware, applications, and consumers recorded in the CMDB, the access relationships between applications interacting through the message middleware are calculated; by using file mount point service information collected from the OS and combining it with the relationships between compute nodes and applications in the CMDB, the access relationships between several applications interacting through the file mount service are calculated; by connecting to the data service platform or components, the compute nodes interacting through the data service are obtained, and by combining it with the relationships between compute nodes and applications recorded in the CMDB, the applications interacting through the data service platform are calculated; by connecting to the CDC data synchronization tool, the databases with data synchronization tasks are obtained, and by combining it with the relationships between databases and applications recorded in the CMDB, the access relationships between applications based on database data synchronization tasks are calculated.

[0100] In step S104, the ledger recording standards for the design-state architecture and the runtime architecture are formulated, including the formulation of the principles and management specifications to be followed in the ledger recording. The management specifications include the ledger templates and version management requirements for the design-state architecture and the runtime architecture.

[0101] Ledger-based record keeping is a systematic and standardized record management method. It involves recording detailed information and data for specific objects or matters according to certain standards and procedures. This method helps improve management efficiency, data accuracy and completeness, enhance data traceability, strengthen risk control, promote compliance, facilitate data tracking and in-depth data analysis, facilitate knowledge sharing and inheritance, support continuous improvement, and enhance transparency.

[0102] The principles followed in the ledger-based recording include: clearly defining the recording objects and scope; the recording objects include relevant instances of systems, subsystems, applications, services, and computing nodes; the recording scope includes the configuration items and relationships of systems, subsystems, applications, services, and computing nodes; standardizing the recording content and format; entering the configuration items that need to be recorded in the ledger for systems, subsystems, applications, services, and computing nodes according to a preset format, and associating the relationships between relevant instances; and standardizing the recording process, requiring the creation, modification, and deletion of system, subsystem, application, service, and computing node instances to be recorded in the ledger. In addition to providing supporting processes, the system should also include standardized ledger media, requiring the establishment of unified electronic tools for ledger recording; ease of querying and analysis, necessitating multiple methods for querying and analyzing ledger records; security and confidentiality, with corresponding security measures for accessing, recording, and modifying ledgers, including at least one of role-based access control, two-factor authentication, and encrypted data storage; regulatory compliance, ensuring compliance with relevant laws and regulations during ledger recording to guarantee the legality of record acquisition and storage; and record retention requirements, specifying the retention period for ledger records to meet potential query and auditing needs.

[0103] In addition, version control requires standardized management. Since the architecture itself is also a digital asset, it can be version-controlled. The version management of agile business system architecture can refer to the model of business system code version management, but the two are different. On the one hand, it needs to manage and track changes at the system architecture design level, that is, design-level architecture version iteration management. On the other hand, it needs to obtain the actual deployment architecture and access architecture of the business system at runtime through automatic collection, that is, runtime architecture version iteration management.

[0104] Therefore, the indicator items of the ledger template in the design state include: initial version information, system, subsystem, application, service, compute node, version number, release date, requirement ID, developers, function description, compatibility information, performance indicators, technology stack information, system architecture topology, physical architecture topology, deployment guidelines, rollback plan, monitoring and maintenance, test and verification results, and other instructions. The following are the definitions of each indicator: Initial Version Information: Records the system's initial version number and time; System: The system involved; Subsystem: The subsystem involved; Application: The application involved; Service: Information on the services involved; Compute Node: Information on the compute nodes involved; Version Number: A unique identifier used to distinguish different architecture versions; Release Date: Records the date the architecture version was officially released; Requirement ID: The business requirement ID corresponding to this version; Developers: Information on the personnel involved in the development of this version; Function Description: Describes the new functions, optimized and deleted functions included in this version architecture, and how these changes improve the system's performance, security, or other key attributes; Compatibility Information: Describes the compatibility of the new version architecture with the previous version and other system components, including forward compatibility and incompatible content; Performance Metrics: Provides performance benchmark test results, such as response time, throughput, resource consumption, etc., to evaluate the performance of the new version; Technology Stack Information: Technical architecture information for this version, including but not limited to development language, development framework, component type, database type, middleware type, data dictionary, main algorithms, and dependent peripheral systems; System Architecture Topology: System architecture topology diagram for this version, including but not limited to descriptions of systems, subsystems, applications, and service nodes, access relationships, and hierarchical structure; Physical Architecture Topology: Physical architecture topology diagram for this version, showing the physical deployment topology and changes compared to the previous version; Deployment Guidelines: Steps and requirements for deploying the new version architecture, including environment configuration, data migration, and system upgrades; Rollback Plan: Design a rollback plan to quickly restore the system to a previous stable version if problems occur during the deployment of the new version; Monitoring and Maintenance: Changes in monitoring and maintenance for the current version of this system architecture; Test and Verification Results: Test reports for this version; Other Notes: Other information that needs to be explained for management and user reference.

[0105] Furthermore, design-state version control relies primarily on manual operation, typically formulated and maintained by architects and development leads, adhering to the principle of "whoever designs, builds, and maintains." If adjustments to the design-state architecture are needed based on actual system requirements, approval is required before updates can be made. Once updated, a new design-state architecture version is generated for the entire system. Therefore, the version management requirements for the aforementioned design-state ledger template include the following settings: initializing version specifications, defining a version control system, setting up version change processes, standardizing architecture topology, establishing a version change tracking mechanism, and backup and archiving. The system architecture initialization version specification includes: the architecture design prototype approved at the architecture review meeting (which should include, but is not limited to, the participation of relevant roles in business architecture, system architecture, technical architecture, data architecture, and infrastructure architecture) is the initial design version of the system architecture; the system architecture version system defines a version control system for the architecture design state, which can adopt the major version number.minor version number pattern, with the version number updated each time the architecture changes; architecture topology standardization requires providing visual architecture topology diagrams and standardized document descriptions for the "system architecture topology" and "physical architecture topology" in the design state architecture version ledger model, and subsequent architecture version changes need to be iterated based on the standardized architecture topology information of the previous version; and system architecture version changes... Systematic tracking mechanism: Records the differences between each architecture version and the historical record of each architecture version decision, including the process of determining the initial system architecture version, the specific reasons for the approval or rejection of architecture version changes, and the personnel involved in the architecture version review. These records help team members and stakeholders clearly understand the current status and historical changes of the architecture, thereby improving project transparency and understanding the history of architecture evolution; Backup and archiving: Regularly backs up the system architecture data in the ledger and related system architecture documents to ensure that specific system architecture version information can be restored in the event of data loss or corruption; Adherence to standards and industry practices: Follows industry standards and practices in designing and maintaining the system architecture, avoiding unconventional approaches, and ensuring the stability and scalability of the system architecture.

[0106] Additionally, the process management system should include procedures for system design-state architecture version changes. Triggering reasons include: 1) a planned architectural adjustment by the system administrator; and 2) inconsistencies between the design-state and runtime architectures, with the runtime architecture taking precedence. In these cases, the design-state architecture version change procedure should be followed. Specifically, as follows... Figure 7As shown, the system owner submits a system architecture change request through the process management system, including but not limited to the planned change time, reasons for the change, impact assessment of the change, change plan and steps, verification methods, and rollback plan. The architecture team discusses and resolves the change request at the architecture review meeting (which should include, but is not limited to, relevant roles in business architecture, system architecture, technical architecture, data architecture, and infrastructure). If the change request is approved, a new architecture version number will be assigned for this architecture version change and updated in the system design-state architecture version ledger. If it is not approved, it will be returned to the system owner. For applications that are approved, a business system change process is initiated, and the application form for the design-state architecture version adjustment and the new architecture version number are linked. The change to the design-state architecture version is implemented through the execution of the business system change process.

[0107] The runtime architecture primarily relies on automated discovery techniques to obtain the access and deployment architecture of the business system in its actual operating environment. The runtime version also has an inherent logic: its associated design-state architecture. This design-state architecture is fundamental to the runtime architecture, and normally, the runtime architecture of the same version should be consistent with the design-state architecture. Furthermore, from a practical production perspective, the five-layer model supports the actual operation of the business system through compute nodes and service instances deployed on each compute node. Information from these two models can be automatically collected. Therefore, the metrics of the runtime ledger template include: associated design-state version number, system, subsystem, application, service, compute node, version number, latest update time, system architecture topology, and physical architecture topology. Among them, the associated design state version number: runtime associated design state version information; system: the system involved; subsystem: the subsystem involved; application: the application involved; service: the service information involved (collected automatically); compute node: the compute node information involved (collected automatically); version number: a unique identifier used to distinguish different architecture versions; latest update time: the latest date when the current version architecture was discovered; system architecture topology: the system architecture topology diagram of this version, mainly reflecting the actual access architecture (collected automatically); physical architecture topology: the physical architecture topology diagram of this version, mainly reflecting the actual physical deployment architecture (collected automatically).

[0108] The runtime version management requirements include: implementing a role-based access control model to control the configuration and data collection permissions of automated data collection tools, ensuring that only authorized users can operate and maintain the tools; automatically collecting relevant service instance and compute node information after application version release changes and comparing it with the design-state architecture; periodically collecting service instances and compute nodes of the business system through scheduled tasks to obtain the latest runtime configuration information; properly configuring tools for continuously collecting runtime information and monitoring their running status to ensure normal operation; analyzing and adjusting automated data collection methods that affect the stability and performance of the business system; establishing a runtime architecture version change process in the process management system, and when the design-state and runtime architectures are inconsistent, version changes and updates are based on the design-state architecture. Additionally, the relevant processes for system runtime architecture version changes are as follows: Figure 8 As shown.

[0109] In step S105, a visualization verification standard for the system architecture is established, including setting the target object for visualization, determining the data acquisition method, designing visualization elements, setting the element information of the target object for visualization, selecting visualization tools, implementing dynamic and interactive display, and taking the version of the design state architecture as the baseline version and the version of the runtime architecture as the runtime version. A timed comparison mechanism between the baseline version and the runtime version is established. If the comparison finds that the version information is inconsistent, a version difference work order is generated and processed.

[0110] Visualizing the architecture of agile business systems is a technology that presents the various components and workflows of a business system graphically. It makes complex and abstract system architecture information intuitive and easy to understand and analyze. Especially for agile business systems, which often adopt a microservice architecture for design and development, referencing the five-layer model of system, subsystem, application, service, and compute node, compared to the monolithic model of stable business systems, the architecture of agile business systems, when visualized, can more intuitively present the access relationships, hierarchical structure, and business data flow between various business systems and within each service.

[0111] The explanation for step S105 is as follows: Determine the target objects for visualization: Agile business system architecture involves many objects, and most agile business systems in the securities and fund industry are currently developed using microservices. Therefore, instances of the five-layer model (system, subsystem, application, service, and computing node) can be identified as the target objects for visualization; Data acquisition: Architecture visualization is essentially a runtime architecture display. Therefore, the data required for visualization can be obtained from runtime architecture data information. If any data is missing, it can be supplemented manually; Design visualization elements: Design intuitive graphic elements to represent the relationships between the target objects, such as using different shapes, colors, and lines; Visualize target object element information: Name, function, hierarchy, capacity indicators, performance indicators, health status, upstream target objects, downstream target objects, etc.; Select appropriate visualization tools: Select appropriate visualization tools or platforms according to requirements. These tools and platforms can provide the visualization objects and topology views that the agile business system architecture needs to display; Implement dynamic and interactive display: Provide dynamically updated visualization displays that support user interaction, such as zooming, panning, filtering, and in-depth viewing of details.

[0112] In the comparison specification between design-state and runtime architectures, the design-state architecture version primarily describes the architectural information of the business system from a management perspective. The system topology diagram and physical deployment diagram reflect the expected service request access relationships and compute node deployment during the business system's design. Therefore, the design-state business system architecture version is also the baseline version that conforms to management requirements and architectural design. The runtime architecture version, mainly based on automatic discovery technologies, obtains the access architecture and deployment architecture in the actual operating environment, acquiring the service request access relationships and compute node deployment during the actual operation of the business system. Therefore, the runtime business system architecture version is the runtime version. Generally speaking, during the architecture design and management process, the runtime architecture of the same version of the business system should be consistent with the design-state architecture, without deviation. However, in reality, there may be discrepancies between the runtime version collected and the baseline design version. In this case, it is necessary to analyze the runtime architecture and design-state architecture for the same version number. A timed comparison mechanism should be set up, scheduled during off-peak business hours (e.g., the latter half of each day), to periodically scan the runtime system architecture and compare it with the design-state version architecture information recorded in the ledger. When a discrepancy is found between the version information of the design architecture and the runtime architecture of a business system, the process platform will automatically generate a work order for the version difference between the design architecture and the runtime architecture.

[0113] In cases where version differences exist, such as Figure 9 As shown, the following situations are handled as follows:

[0114] Scenario 1: The design architecture is accurate, but the runtime architecture has deviated from the design architecture due to the system owner not initiating an architecture change management process for some reason. Routine daily changes may indeed lead to changes in the system architecture. This situation is difficult to detect and is also very harmful to the system architecture. It is necessary to adjust the runtime architecture in a timely manner to keep it consistent with the design architecture. The system development owner needs to explain the reasons for the deviation, summarize the experience, and achieve closed-loop management.

[0115] Scenario 2: If the design-state architecture is not comprehensive enough during the design process, and some design aspects are omitted or deviated, then the design-state architecture needs to be adjusted in a timely manner based on the runtime architecture. That is, the baseline version should be corrected by using the runtime version, and the personnel involved in the relevant architecture design evaluation need to summarize their experience to achieve closed-loop management.

[0116] Therefore, in step S107, the visualization verification of the architecture and the mutual verification between the design architecture and the runtime architecture can ensure that the actual runtime architecture of the business system conforms to the baseline version of the design architecture. On the other hand, it can ensure that the design architecture of the business system is more accurate under the verification of the runtime architecture, so as to provide a reference for the implementation of more high-value scenarios based on the reliable design architecture.

[0117] As can be seen from the above embodiments, the present invention realizes the management of the entire lifecycle of the agile business system architecture. On the one hand, it meets the different needs of personnel in different roles for the management of the agile business system architecture, such as root cause analysis, architecture evolution, and correlation impact analysis. On the other hand, by managing the consistency between the design state and the runtime state of the agile business system architecture, it increases the leverage for managing the business system, thereby helping to improve the stability, security, and performance of the agile business system.

[0118] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

Claims

1. A structured management method for an agile business architecture system, characterized in that, The method includes: Based on the determined hierarchical type of the business architecture system, a design-state architecture is formed. The design-state architecture includes requirements definition, architecture design, software design, development, and testing. The architecture design includes domain partitioning, component partitioning, interface definition, and data flow design. The business architecture system formed based on the design-state architecture is then deployed and maintained to form a runtime architecture. The design-state architecture, during its design phase, includes a structured standard model. This standard model employs a five-layer structure, hierarchically comprising systems, subsystems, applications, services, and compute nodes. Configuration items for each layer are defined. When planning the standard model, its model instances, access logic architecture, and compute node information are planned, along with the creation, modification, and deletion processes for these model instances. The specific planning process for the design-state architecture includes: planning from five levels—system, subsystem, application, service, and compute node—based on the positioning of the business system; determining the new model instances and existing model instances to be reused for each level; calculating the required compute node information, including the type, configuration, and quantity of compute nodes; and planning the access logic architecture, which includes network partitions, request access links, and data links. This access logic architecture can be represented in the compute node information to form the design-state architecture. During execution, the runtime architecture employs an automated data collection method combined with a manual data collection method to manage the configuration items involved in the service and computing nodes. Establish ledger recording standards for the design-state architecture and the runtime architecture, including establishing principles and management specifications for ledger recording, wherein the management specifications include ledger templates and version management requirements for the design-state architecture and the runtime architecture; Establish a visualization verification standard for the system architecture, including setting the target object for visualization, determining the data acquisition method, designing visualization elements, setting the element information of the target object for visualization, selecting visualization tools, implementing dynamic and interactive display, and using the version of the design-state architecture as the baseline version and the version of the runtime architecture as the runtime version. Establish a timed comparison mechanism between the baseline version and the runtime version. If the comparison finds that the version information is inconsistent, generate a version difference work order and execute the processing.

2. The structured management method for an agile business architecture system according to claim 1, characterized in that, When building and managing the design-state architecture, perform the following operations: Requirements analysis includes one or more of the following: business requirements, user requirements, system requirements, functional requirements, non-functional requirements, security requirements, technical requirements, data requirements, integration requirements, testability requirements, change management requirements, priorities, and dependencies. Architecture design includes the relationships between the system, subsystems, and applications; Interface definition, including: defining the interaction interfaces between different components or services; Technology selection includes choosing the appropriate technology stack and tools for development.

3. The structured management method for an agile business architecture system according to claim 1, characterized in that, When building and managing the runtime architecture, perform the following operations: The deployment environment involves deploying the designed software components into the production environment. The runtime architecture includes an access architecture and a deployment architecture. The access architecture represents the access relationships between various components within the business system, while the deployment architecture represents how the business system architecture is deployed within the environment. Configure system parameters according to the needs of the operating environment; Monitoring and optimization: Based on the visual monitoring of the operational status of business systems, performance optimization and troubleshooting are performed.

4. The structured management method for an agile business architecture system according to claim 1, characterized in that, The system configuration items include: system name, system code, service catalog and SLA, system owner, system importance level, system business positioning, system scope and boundaries, business system architecture requirements, service lifecycle, information security requirements, business continuity, resource management, and security level. The subsystem configuration items include: subsystem name, subsystem code, subsystem owner, subsystem importance level, subsystem functions and SLA, information security requirements, performance baseline, monitoring baseline, service window, maintenance strategy and window, user and permission management, testing strategy, and change management requirements. The application configuration items include: application name, application code, application owner, application functions and service description, application environment configuration, application security strategy, application performance indicators, application monitoring indicators, fault handling strategy, application deployment method, application version, and application technology stack. The service configuration items include: service name, owner, IP address, port, service interface, calling service, and called service. The computing node configuration items include: node name, IP address, owner, operating system, configuration, environment, type, and service process.

5. The structured management method for an agile business architecture system according to claim 1, characterized in that, In the standard model, the system, the subsystem, the application, the service, and the computing node have the following relationships: The system comprises several subsystems, each subsystem comprising several applications, each application comprising several services, and each service comprising several computing nodes; A subsystem can only belong to one system, and an application belongs to one subsystem; The SLA of the system affects the SLA of the subsystem; The importance level of the system affects the importance level of the subsystem; The system's architectural design principles influence the subsystems' requirements access principles, technology stack usage principles, data access principles, and access control principles. The information security requirements of the system affect the security requirements and controls of the subsystems. The system's business continuity plan affects the service windows, maintenance strategies and windows, as well as quality assurance and testing of the subsystems; The change management requirements of the subsystem affect the application's release method, application version management, and version release history; The performance baseline of the subsystem affects the performance metrics of the application. The monitoring baseline of the subsystem affects the monitoring metrics of the application.

6. The structured management method for an agile business architecture system according to claim 1, characterized in that, The configuration items involved in the runtime architecture in the management service and computing nodes, and the automated and manual data collection methods used, include: By obtaining network link information from the operating system, the access relationships between computing nodes are calculated. At the same time, by combining the relationships between computing nodes and services in the CMDB, the calling relationships between services are calculated, and then the calling relationships between applications, between subsystems, and between systems are calculated. By obtaining the call information between interfaces from APM and combining it with the relationship between interfaces and applications in CMDB, the call relationship between interfaces between applications can be calculated. At the same time, based on the characteristics of APM, the running path of each business request in the system architecture can be calculated. By collecting the link relationships between computing nodes and databases or storage services in the OS, and combining them with the relationships between computing nodes and services in the CMDB, the call relationships between applications and databases or storage services can be calculated. By using the service query interface provided by the message middleware and combining the association between the middleware, applications, and consumers recorded in the CMDB, the access relationship between applications interacting through the message middleware can be calculated. By collecting file mount point service information from the OS and combining it with the relationship between compute nodes and applications in the CMDB, the access relationships between several applications that interact through the file mount service can be calculated. By connecting to a data service platform or component, the computing nodes that interact with data through the data service can be obtained. Combined with the relationship between computing nodes and applications recorded in the CMDB, the applications that interact through the data service platform can be calculated. By connecting to the CDC data synchronization tool, we can identify which databases have data synchronization tasks and, combined with the relationships between databases and applications recorded in the CMDB, calculate the inter-application access relationships that occur based on database data synchronization tasks.

7. The structured management method for an agile business architecture system according to claim 1, characterized in that, The principles followed in the ledger-based record keeping include: Clearly define the objects and scope of the records. The objects to be recorded include relevant instances of the system, subsystem, application, service, and compute node. The scope of the records includes the configuration items and relationships of the system, subsystem, application, service, and compute node. Standardize the content and format of the records. The configuration items that need to be recorded in the ledger of the system, subsystem, application, service and computing node are entered according to the preset format, and the relationship between related instances needs to be associated. Standardizing the recording process requires providing corresponding process support when recording the creation, modification, and deletion of system, subsystem, application, service, and computing node instances in the ledger; The standardized format of ledger media requires the establishment of a unified electronic tool for the aforementioned ledger-based recording. The ease of querying and analysis requires providing multiple methods for querying and analyzing ledger records; Security and confidentiality are ensured by implementing corresponding security measures for accessing, recording, and modifying the ledger. These security measures include at least one of the following: role-based access control, secondary authentication, and encrypted data storage.

8. The structured management method for an agile business architecture system according to claim 1, characterized in that, The indicator items of the ledger template in the design-state architecture include: Initial version information, system, subsystem, application, service, compute node, version number, release date, requirement ID, developers, feature description, compatibility information, performance metrics, technology stack information, system architecture topology, physical architecture topology, deployment guidelines, rollback plan, monitoring and maintenance, test and verification results, and other notes; The version management requirements for the ledger template in the design-state architecture include the following settings: Initialize version specifications, define version control system, set up version change process, standardize architecture topology, version change tracking mechanism, backup and archiving.

9. The structured management method for an agile business architecture system according to claim 1, characterized in that, The metrics items of the ledger template in the runtime architecture include: The associated design-state version number, system, subsystem, application, service, compute node, version number, latest update time, system architecture topology, and physical architecture topology; The version management requirements for the runtime architecture include: Implement a role-based access control model to control the configuration permissions and data collection permissions of automated data collection tools, ensuring that only authorized users can operate and maintain the tools; After the application version is released and changes are made, the relevant service instance and compute node information is automatically collected and compared with the design architecture; Periodically collect the service instances and compute nodes of the business system through scheduled tasks to obtain the latest runtime configuration information; Configure tools that continuously collect runtime information appropriately and monitor their running status to ensure that the tools function properly; Analyze and adjust automated data collection methods that impact the stability and performance of business systems; Establish a runtime architecture version change process in the process management system. When the design architecture and the runtime architecture are inconsistent, the design architecture shall be used as the standard for version change and update.

Images