Multi-level management and control method and system based on extensible application architecture

Abstract

The invention provides a multi-level management and control method and system based on an extensible application architecture, and the method comprises the steps: obtaining a system target list based on an existing application platform in a target enterprise; based on the system target list and a hierarchical modeling method, constructing a target architecture model corresponding to each service function in an application platform; according to the target architecture model, constructing target blueprint data corresponding to the target enterprise; obtaining a system current situation list of each sub-department in the target enterprise, comparing the system current situation list with the target blueprint data, and obtaining a gap list between the system current situation list and the target blueprint data; and based on the gap list, generating application platform control adjustment recommendation information corresponding to the target enterprise. According to the invention, the repeated construction rate of applications is reduced and the data intercommunication efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of application architecture technology, and in particular to a multi-level management and control method and system based on a scalable application architecture. Background Technology

[0002] With the full arrival of the digital age, digital transformation has become a key path for enterprises to enhance competitiveness and achieve sustainable development. For multi-tiered, group-type enterprises, their organizational structures are complex, encompassing numerous subsidiaries and departments, with a wide and diverse range of businesses. Against this backdrop, building an efficient, collaborative, and highly scalable application architecture to support the orderly operation of the group's overall business and the optimal allocation of resources has become a core requirement in the process of enterprise digital transformation. Only through a reasonable architectural design can information barriers between subsidiaries and departments be broken down, enabling the smooth flow and sharing of business data, thereby improving the overall operational efficiency and decision-making capabilities of the group.

[0003] Currently, multi-level group-type operational management enterprises are employing various technologies to build application systems during their digital transformation. From a software perspective, they are introducing various software suites from different vendors, covering multiple business areas such as financial management, human resource management, and production operations management, attempting to meet the needs of different departments and business scenarios through diversified software. Regarding interface technology, various custom or standard interface protocols are used to achieve data interaction and functional integration between different systems. Simultaneously, some enterprises are also attempting to build a unified data platform for storing and managing the group's business data, hoping to improve data utilization efficiency in this way.

[0004] However, existing technologies have revealed numerous problems during application. On the software side, the numerous software brands introduced have led to system fragmentation, poor compatibility and integration between software programs, severe duplication of development, and significant resource waste. At the interface level, inconsistent interfaces and a lack of unified standards and specifications make cross-system integration extremely difficult and costly, with each cross-system integration requiring an average of two to three months of development. In terms of collaboration efficiency, cross-departmental data exchange is inefficient, severely impacting business collaboration. Furthermore, the existing architecture lacks scalability, making it difficult to adapt to the rapid development and changes in the group's business. The software lifecycle is generally only three to five years, failing to meet the company's long-term development needs. Therefore, there is an urgent need for a multi-level management and control method and system based on a scalable application architecture to solve these problems. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a multi-level management and control method and system based on a scalable application architecture.

[0006] This invention provides a multi-level management and control method based on a scalable application architecture, comprising: Based on the existing application platforms within the target enterprise, obtain a list of target systems; Based on the system target list and the hierarchical modeling method, construct the target architecture model corresponding to each business function in the application platform; Based on the target architecture model, construct the target blueprint data corresponding to the target enterprise; Obtain a list of the current status of systems in each sub-department of the target enterprise, and compare the list of current status of systems with the target blueprint data to obtain a list of gaps between the list of current status of systems and the target blueprint data; Based on the gap list, application platform management and control adjustment recommendation information is generated for the target enterprise.

[0007] According to the multi-level management and control method based on a scalable application architecture provided by the present invention, after generating application platform management and control adjustment recommendation information corresponding to the target enterprise based on the gap list, the method further includes: Add a new application platform to the target enterprise, and based on the new application platform, obtain a new system target list, and construct new target blueprint data according to the new system target list.

[0008] According to the multi-level management and control method based on a scalable application architecture provided by the present invention, the step of obtaining a system target list based on the existing application platform in the target enterprise includes: Data is collected from the system logs, configuration files, document content, and user feedback information of the existing application platforms in the target enterprise to obtain an application platform system list, an application platform system function list, an application platform interface list, a data responsibility list, and a technology stack list. The application platform system list includes the system list of application platforms that have been built or are under construction. Based on the application platform system list, the application platform system function list, the application platform interface list, the data responsibility list, and the technology stack list, determine the application dependencies, system call relationships, number of interfaces, and data flow information corresponding to the existing application platforms in the target enterprise; Based on the application dependencies, system call relationships, number of interfaces, and data flow information, the system target list is constructed.

[0009] According to the multi-level management and control method based on a scalable application architecture provided by the present invention, the step of constructing a target architecture model corresponding to each business function in the application platform based on the system target list and the layered modeling method includes: Based on the aforementioned hierarchical modeling method and preset hierarchical mode, the corresponding businesses and systems in the application platform system list, the application platform system function list, and the application platform interface list are decomposed level by level to obtain the hierarchical relationship and mapping relationship between each business and system; Based on the hierarchical relationship, the mapping relationship, and the application platform type, construct the target architecture model corresponding to each business function in the application platform.

[0010] According to a multi-level management and control method based on a scalable application architecture provided by the present invention, the step of constructing the target architecture model corresponding to each business function in the application platform according to the hierarchical relationship, the mapping relationship, and the application platform type includes: When the application platform type is determined to be a business process type, the application platform is layered according to the business process sequence based on the hierarchical relationship and the mapping relationship, and the target architecture model corresponding to each business function in the application platform is constructed. When the application platform type is determined to be a system function type, the application platform is functionally driven and layered according to business functions based on the hierarchical relationship and the mapping relationship, and the target architecture model corresponding to each business function in the application platform is constructed based on the obtained business function modules. When the application platform type is determined to be a data-driven type, the application platform is divided into business-driven layers according to the data responsibility and data flow direction based on the hierarchical relationship and the mapping relationship, so as to divide the application platform into corresponding data providers, data processors and data consumers; based on the data providers, the data processors and the data consumers, the target architecture model corresponding to each business function in the application platform is constructed.

[0011] According to the multi-level management and control method based on a scalable application architecture provided by the present invention, the step of constructing target blueprint data corresponding to the target enterprise based on the target architecture model includes: Based on the application platform system list, application platform system function list, application platform interface list, data responsibility list, and technology stack list corresponding to the target architecture model, obtain application layer division information, functional module boundary information, interface standard information, data responsibility attribution relationship, and technical support framework information. The target blueprint data is constructed based on the application hierarchy information, the functional module boundary information, the interface standard information, the data responsibility attribution relationship, and the technical support framework information.

[0012] According to a multi-level management and control method based on a scalable application architecture provided by the present invention, the step of comparing the current system status list with the target blueprint data to obtain a gap list between the current system status list and the target blueprint data includes: Based on the numbering information of each sub-department, the current status list of the system is compared with the corresponding department blueprint data in the target blueprint data to obtain the system overlap rate, uncovered business domain information, interface difference information, data responsibility conflict information and technology stack difference information corresponding to each sub-part. The gap list is constructed based on the system overlap rate, the information of the uncovered business domains, the interface difference information, the data responsibility conflict information, and the technology stack difference information.

[0013] This invention also provides a multi-level management and control system based on a scalable application architecture, comprising: The target list acquisition module is used to obtain the system target list based on the existing application platforms in the target enterprise; The hierarchical modeling module is used to construct the target architecture model corresponding to each business function in the application platform based on the system target list and the hierarchical modeling method. The blueprint construction module is used to construct target blueprint data corresponding to the target enterprise based on the target architecture model; The gap analysis module is used to obtain a list of the current status of the systems in each sub-department of the target enterprise, and compare the list of the current status of the systems with the target blueprint data to obtain a list of gaps between the list of the current status of the systems and the target blueprint data. The management and control recommendation module is used to generate application platform management and control adjustment recommendation information for the target enterprise based on the gap list.

[0014] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the multi-level management and control method based on the scalable application architecture described above.

[0015] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-level management method based on a scalable application architecture as described above.

[0016] The present invention provides a multi-level management and control method and system based on a scalable application architecture. It constructs a target architecture model using a layered modeling method based on the target enterprise's existing application platform system target list, thereby generating target blueprint data. Then, it compares the current status list of sub-department systems with the gap list of blueprint data, and finally generates application platform management and control adjustment recommendation information based on this, thereby reducing the application duplication rate and improving data interoperability efficiency. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the multi-level management and control method based on a scalable application architecture provided by this invention; Figure 2 This is a schematic diagram of the scalable application architecture provided by the present invention in a multi-level control scenario; Figure 3 This is a schematic diagram of the structure of a multi-level management and control system based on a scalable application architecture provided by the present invention; Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0020] Existing enterprise-level architecture methodologies and standards primarily revolve around the enterprise 4A architecture, aligning business architecture, data architecture, application architecture, and technical architecture in layers. This is supported by unified architecture governance mechanisms, review baselines, and version control, forming a multi-level capability decomposition and master-slave relationship management system. The common thread among these frameworks is that through layered architecture, visual management, and baseline-based management, they achieve a unified approach to vertical governance and horizontal collaboration, providing a comprehensive blueprint for subsequent system planning and implementation.

[0021] Although existing technologies have formed a certain framework in enterprise-level architecture methodologies, development processes, and systems engineering, they still have significant shortcomings when applied to scalable application architectures with multi-level control, mainly in the following aspects: Enterprise-level architecture methodologies, such as 4A, TOGAF, and Zachman, tend to focus on theoretical frameworks and macro perspectives, emphasizing layering, views, and baseline management. However, they lack operational methods for specific business implementation and often remain at the guiding and descriptive level, making them difficult to implement directly in real-world scenarios of multi-level collaboration within a group.

[0022] Integrated Product Development (IPD): While it can improve the overall efficiency of product development through end-to-end and cross-functional teams, its core focus is on the product development process. It lacks a mechanism to form unified specifications and interface standards at the enterprise application architecture and information system level, so it is difficult to fully support multi-level architecture scenarios across enterprises and systems.

[0023] Model-based systems engineering (MBSE) can achieve end-to-end traceability from requirements to implementation using models, but it has high implementation costs, relies on a unified modeling language and toolchain, and has high requirements for the organization's information infrastructure and personnel quality, making it difficult to promote within a group.

[0024] Existing technologies generally lack targeted solutions in areas such as data responsibility division, unified interface standards, real-time cross-system collaboration, and adaptation to the information technology innovation environment. They can often only solve local problems and are difficult to build an integrated application architecture that covers multiple levels, including headquarters, subsidiaries, and departments.

[0025] Figure 1 This is a flowchart illustrating the multi-level management and control method based on a scalable application architecture provided by the present invention, as shown below. Figure 1 As shown, this invention provides a multi-level management and control method based on a scalable application architecture, including: Step 101: Obtain a list of target systems based on the existing application platforms in the target enterprise.

[0026] In this invention, a comprehensive survey of the existing application platforms of the group and its subsidiaries can be conducted through various data collection methods, including interviews, questionnaires, system log analysis, and document collection. Interviews allow for communication with managers, technical personnel, and business personnel at different levels to gain a deeper understanding of system usage, existing problems, and expectations; questionnaires can broadly collect opinions and suggestions from various departments; system log analysis can uncover actual data on system operation, such as access frequency and error records; and document collection covers system documents, business process descriptions, and other materials.

[0027] Furthermore, based on the aforementioned data collection process, a series of lists are generated, including: a list of existing or under-construction systems (representing the relevant software systems of the application platform within the target enterprise) (i.e., the application platform system list), clearly defining the various existing systems within the enterprise and their construction status; a system function list (i.e., the application platform system function list), detailing the functions of each system; an interface list (i.e., the application platform interface list), recording the interface information for data interaction and function calls between systems; a data responsibility list, defining the responsible departments or organizations for different data; and a technology stack list, describing the technical framework, development language, and database used by the system. These lists are used to construct an application dependency matrix, clearly presenting the calling relationships between systems, the number of interfaces, and data flow, while also statistically analyzing system coverage and redundancy rates, providing a quantitative basis for subsequent design.

[0028] Step 102: Based on the system target list and the hierarchical modeling method, construct the target architecture model corresponding to each business function in the application platform.

[0029] In this invention, based on the organized system list, function list, and interface list, a target architecture model is established using a layered modeling method to achieve clear decomposition and mapping of business and systems.

[0030] Specifically, the goal of hierarchical modeling is to decompose complex business processes and systems step by step, so that the goals, business processes, applications and technologies form clear hierarchical relationships and mapping relationships, and ensure that the architecture has clear boundaries, traceability and scalability.

[0031] In this invention, the hierarchical modeling method can employ either top-down decomposition or a combination of bottom-up induction. Top-down decomposition starts with business objectives, progressively breaking them down to functions, interfaces, and configurations, ensuring consistency between the overall design and the top-level plan. Bottom-up induction starts with existing systems and functions, gradually abstracting business and application domains, ensuring that the modeling results are realistic. In this invention, both methods can be used in combination, achieving alignment between the plan and the current state through iteration.

[0032] In this invention, various hierarchical modeling methods can be employed, including: Business-driven layering uses business processes as the main thread to map application systems to business stages. For example, in the R&D stage of a manufacturing enterprise, demand management, design, simulation, process, and testing verification each correspond to different application modules. System construction is configured and integrated according to the process sequence to ensure that information flows completely along the main business line.

[0033] Function-driven layering takes system functions as its core and breaks down complex systems into independently reusable functional modules. For example, in a Product Lifecycle Management (PLM) platform, the system is divided into modules such as configuration management, change management, document management, and project management. Each module can run independently or be reused within the platform or across platforms, avoiding redundant development.

[0034] Data-driven layering, based on data responsibility and data flow, divides the system into data providers, processors, and consumers. For example, in a group's financial system, the headquarters acts as the node for aggregating and auditing financial data, subsidiaries act as data providers, and business systems act as data consumers. The entire architecture is divided and constructed around the data flow, focusing on solving the problems of data consistency and cross-level data reconciliation.

[0035] In this invention, the specific levels of the layered system can vary depending on the type of enterprise and the complexity of the architecture. For example, this invention adopts a six-level layering, progressively refining from application domains to operational configurations, suitable for large group enterprises requiring sophisticated management. Small and medium-sized enterprises can use a simplified three-layer model consisting of a business layer, application layer, and technology layer to reduce modeling complexity. Through layered modeling, a target architecture model covering business scope, application affiliation, functional modules, functional items, interfaces, and operational configurations is established, providing structured support for subsequent work.

[0036] Step 103: Based on the target architecture model, construct the target blueprint data corresponding to the target enterprise.

[0037] In this invention, based on the target architecture model obtained through layered modeling, a target architecture diagram is drawn to form target blueprint data. The blueprint data needs to include the following: application hierarchy, clearly defining the hierarchical position of different applications within the architecture; system module boundaries, defining the scope and responsibilities of each system module; interface specifications, specifying the protocol, data structure, and calling methods of the interfaces; data responsibility attribution, identifying the responsible department or organization for different data; and a technical support framework, describing the technical architecture and tools supporting system operation.

[0038] In this invention, the target blueprint data features scalability and modularity, ensuring that the blueprint can adapt to the future development and changes of the enterprise, while facilitating modular development and integration of the system. The final target blueprint data includes: an application blueprint diagram, providing an intuitive graphical representation of the application architecture; interface standard documents, detailing the specifications and requirements of the interfaces; a data responsibility table, clearly listing the primary responsibilities for the data; and a functional module directory, listing each functional module and its related information. In this invention, the blueprint data serves as a unified reference for the target enterprise, guiding subsequent system construction and integration for subsidiaries and departments.

[0039] Step 104: Obtain a list of the current status of each sub-department in the target enterprise, and compare the list of the current status of the system with the target blueprint data to obtain a list of gaps between the list of the current status of the system and the target blueprint data.

[0040] In this invention, a system status list for each sub-department is obtained, including the existing system's functions, interfaces, data usage, etc. Furthermore, the status list is compared item by item with the target blueprint to identify gaps in system construction, functional coverage, data governance, and technical support.

[0041] Specifically, the system overlap rate is obtained based on the number and proportion of duplicate systems among different subsidiaries or departments.

[0042] Identify which key processes or links are not yet supported by the system, find the gaps in business coverage, and determine the uncovered business domains.

[0043] Examine the differences in interface protocols, data structures, and calling methods to identify inconsistencies in the interfaces.

[0044] Determine whether different systems or organizations have inconsistent attributions and definitions of the same type of data, and identify relevant information regarding data responsibility conflicts.

[0045] Conduct compatibility assessments and evolution analysis of operating systems, databases, middleware, and development frameworks to obtain information on differences in the technology stack.

[0046] In this invention, gap analysis is not only a direct comparison between the current situation and the blueprint, but also requires setting reasonable goals in conjunction with the company's development stage. For start-up companies, the key goal is to reduce redundant system construction and establish basic functional coverage and data consistency; for growing companies, the goal is to gradually unify interface standards, resolve cross-departmental process breakpoints, and improve system integration; for mature companies, the goal shifts to optimizing the consistency and scalability of the overall architecture.

[0047] Ultimately, the gap analysis process will output a gap list and an improvement priority ranking. The gap list includes a list of duplicate systems, a list of uncovered functions, a list of interface issues, and a list of data conflicts; the priority ranking, combined with the company's phased goals, transformation costs, and implementation benefits, forms a roadmap for subsequent implementation.

[0048] Step 105: Based on the gap list, generate application platform management and control adjustment recommendation information for the target enterprise.

[0049] In this invention, based on the gap list, targeted application platform management and adjustment recommendation information is constructed to guide enterprises in improving and optimizing their systems.

[0050] Specifically, based on the gap analysis results, an implementation roadmap will be developed. Subsidiaries with a strong IT infrastructure and mature management will be selected as pilot enterprises to implement the blueprint partially, standardize interface applications, and unify data responsibilities. After the pilot program is completed, feedback and improvement measures will be used to gradually extend the program to other subsidiaries until it achieves full coverage across the group.

[0051] During implementation, phased acceptance and rolling evaluation are adopted to ensure that each step of construction is verifiable and correctable. Phased acceptance allows for the inspection and confirmation of the work results at each stage, ensuring work quality; rolling evaluation allows for timely adjustments to the implementation plan and strategies based on actual conditions, ensuring the smooth progress of the project.

[0052] Preferably, the current inventory and blueprint are revised annually, taking into account new system development, system adjustments, and technological evolution. Updates include new applications, changes to functional modules, interface updates, and adjustments to data responsibilities. Annual updates ensure the architecture remains consistent with the company's actual situation, preventing a disconnect between the blueprint and implementation. Through these methods, the generated application platform management and adjustment recommendations can effectively guide the company's system construction and optimization, improving its IT capabilities and operational efficiency.

[0053] The multi-level management and control method based on scalable application architecture provided by this invention constructs a target architecture model using a layered modeling method based on the system target list of the target enterprise's existing application platform, thereby generating target blueprint data. Then, it compares the current status list of sub-department systems with the gap list of blueprint data, and finally generates application platform management and control adjustment recommendation information based on this, thereby reducing the application duplication rate and improving data interoperability efficiency.

[0054] Based on the above embodiments, after generating application platform management and adjustment recommendation information for the target enterprise based on the gap list, the method further includes: Add a new application platform to the target enterprise, and based on the new application platform, obtain a new system target list, and construct new target blueprint data according to the new system target list.

[0055] In this invention, when a target enterprise faces situations such as the creation of new systems, architectural adjustments, and technological evolution during its operational development, it is determined that there are new application platform changes within the target enterprise. These new application platforms may be introduced to meet new business needs, expand into new market areas, or improve internal management efficiency, bringing new changes and impacts to the enterprise's overall business and technical architecture.

[0056] Furthermore, the original system target list will be modified in light of the newly added system and other factors. The addition of a new application platform will bring a series of new requirements and changes, thus forming a new system target list. This new list will include applications added due to the new application platform, such as new business processing applications and data analysis applications; it will also involve changes to functional modules, as the new application platform may need to integrate with existing system modules or upgrade existing modules; simultaneously, interfaces will be updated, as the new application platform needs to interact and communicate with existing systems and other external systems, inevitably leading to new interface requirements or adjustments to existing interfaces; additionally, data responsibilities may be adjusted, as the new application platform generates new data, and the management responsibilities for this data need to be clearly defined, potentially involving a redistribution of data responsibilities among different departments or systems.

[0057] Finally, based on the revised list and various changes, new target blueprint data is constructed. In this invention, the new system target list clarifies the enterprise's various needs and directions of change after the addition of a new application platform. Based on this list, new target blueprint data is constructed, presenting these needs and changes in a systematic and structured manner, forming a blueprint that can guide the enterprise's subsequent system construction and architecture optimization. This new target blueprint data ensures that the enterprise's architecture remains consistent with the actual situation after the introduction of the new application platform, avoiding the problem of the blueprint being out of sync with the actual implementation. For example, it ensures that the annually updated architecture is consistent with the enterprise's actual situation, preventing the blueprint from being out of sync with reality, and ensuring that the enterprise can smoothly and efficiently carry out system construction and business operations after the introduction of the new application platform.

[0058] Based on the above embodiments, obtaining the system target list based on the existing application platform in the target enterprise includes: Data is collected from the system logs, configuration files, document content, and user feedback information of the existing application platforms in the target enterprise to obtain an application platform system list, an application platform system function list, an application platform interface list, a data responsibility list, and a technology stack list. The application platform system list includes the system list of application platforms that have been built or are under construction. Based on the application platform system list, the application platform system function list, the application platform interface list, the data responsibility list, and the technology stack list, determine the application dependencies, system call relationships, number of interfaces, and data flow information corresponding to the existing application platforms in the target enterprise; Based on the application dependencies, system call relationships, number of interfaces, and data flow information, the system target list is constructed.

[0059] In this invention, key data such as the system's operating status, error information, and user operation records can be obtained by collecting and analyzing the system logs of the application platform. This data helps to understand the actual usage and performance of the system.

[0060] The configuration file contains various configuration parameters of the application platform, such as database connection information, service port number, and system parameter settings. By parsing these files, the specific configuration and dependencies of the system can be clearly identified.

[0061] The documents cover the application platform's design documents, user manuals, and technical guidelines. These documents provide important information such as the system's functional descriptions, usage methods, and architectural design, and are crucial for understanding the system's functions and architecture.

[0062] User feedback can be collected through surveys, user interviews, and other methods. This includes user opinions on the application platform, as well as evaluations of the system's usability, stability, and functional requirements. This information helps identify system problems and areas for improvement.

[0063] Furthermore, based on the collected data, the corresponding list content is constructed: The application platform system list covers the application platforms that have been built and are under construction within the target enterprise. By collecting relevant information, it is possible to clearly understand the basic information such as the number, names, and construction status of the application platforms currently owned by the enterprise, providing basic data for the overall application platform management of the enterprise.

[0064] The application platform system function list details the functions available on each application platform. Different application platforms may have different functions; for example, some application platforms focus on data processing, while others emphasize user interaction. A clear function list helps to understand the core role and value of each application platform.

[0065] The application platform interface list records the interface information for data interaction and communication between the application platform and other systems or modules. Interfaces are important channels for connecting the application platform with external systems; understanding the interface list allows you to understand the application platform's data transmission methods and its integration with other systems.

[0066] The data responsibility checklist clarifies the entity responsible for managing the data involved in each application platform. Within an enterprise, different data may be managed and maintained by different departments or teams; the data responsibility checklist helps avoid confusion and unclear responsibilities in data management.

[0067] A technology stack checklist lists the technical elements used by an application platform, such as the technology framework, programming languages, and database management systems. The technology stack determines the technical characteristics of the application platform and the difficulty of development and maintenance. Understanding the technology stack checklist can help companies assess technical risks and formulate technology upgrade strategies.

[0068] In this invention, by analyzing the application platform system list and function list, the dependencies between different application platforms can be determined. For example, a business processing application platform may depend on data support provided by a data analysis application platform. Only when the data analysis application platform is running normally and outputs accurate data can the business processing application platform complete the corresponding business operations. Clarifying application dependencies helps to rationally arrange the construction and maintenance sequence of application platforms, avoiding the inability of other related application platforms to operate normally due to problems with one application platform.

[0069] Furthermore, by combining the application platform system list and interface list, the system call relationships between application platforms can be identified. One application platform may obtain the required services or data by calling the interface of another application platform. For example, a user management application platform may call the interface of an identity authentication application platform to perform user authentication. Understanding system call relationships can help optimize the interaction process between systems and improve the overall performance and stability of the system.

[0070] Furthermore, analyzing the number of interfaces in the application platform's interface list can reveal the frequency and complexity of interactions between the application platform and external systems. An excessive number of interfaces may increase system integration difficulty and maintenance costs, and may also pose security risks. By analyzing the number of interfaces, the integration level and scalability of the application platform can be assessed.

[0071] In this invention, the flow of data between different application platforms can be determined based on the data responsibility list and the interface list. Throughout the entire process from data generation to storage, processing, and use, data passes through multiple application platforms. Clearly defining data flow information helps ensure data security and consistency, preventing data loss, leakage, or tampering during transmission.

[0072] Application dependencies, system call relationships, number of interfaces, and data flow information reflect the actual operation and interrelationships of existing application platforms within the target enterprise. This information forms the basis for constructing a system target list, helping enterprises clarify the goals and direction of system construction. In this invention, the system target list serves as a plan and guide for the enterprise's future system construction. Based on the relationships and information derived from the above analysis, it identifies the systems to be built, their functional requirements, integration methods between systems, and data management objectives. For example, if an application dependency is found to be overly complex, leading to low system efficiency, the system target list may propose goals such as optimizing the application architecture and simplifying dependencies; if the number of interfaces is excessive and poses security risks, the system target list may require interface integration and security hardening. By constructing a system target list, enterprises can conduct targeted system construction and optimization, improving their informatization level and business efficiency.

[0073] Based on the above embodiments, the step of constructing the target architecture model corresponding to each business function in the application platform based on the system target list and the layered modeling method includes: Based on the aforementioned hierarchical modeling method and preset hierarchical mode, the corresponding businesses and systems in the application platform system list, the application platform system function list, and the application platform interface list are decomposed level by level to obtain the hierarchical relationship and mapping relationship between each business and system; Based on the hierarchical relationship, the mapping relationship, and the application platform type, construct the target architecture model corresponding to each business function in the application platform.

[0074] In this invention, layered modeling is a method for decomposing complex systems into multiple layers for analysis and design. Pre-defined layering patterns provide a pre-set framework and rules for this decomposition. For example, common layering patterns may include a business layer, an application layer, and a technology layer. This layering approach allows large and complex businesses and systems to be broken down into multiple relatively independent yet interconnected parts.

[0075] The application platform system list contains basic information about each application platform within the target enterprise. In the hierarchical breakdown, some application platforms may have been built to achieve specific enterprise goals; for example, an enterprise might build an application platform supporting multilingual and multi-currency settlements to expand into other markets. From a business perspective, different business areas will correspond to different application platforms, such as a customer relationship management system for sales operations and a manufacturing execution system for production operations.

[0076] The application platform system function list details the functions possessed by each application platform. Taking an e-commerce application platform as an example, its functions might include product display, shopping cart management, order processing, and payment settlement. In the breakdown, from a business perspective, the product display function is to meet the business needs of users browsing products; from an application perspective, these functions are implemented through specific application modules; from a technical perspective, implementing these functions may require calling database queries, image processing, and other technologies. Through this breakdown, the manifestation of functions at different levels can be clearly seen.

[0077] The application platform interface list records the interfaces through which the application platform interacts and communicates with other systems or modules. For example, a logistics application platform may need to interface with a warehouse management system to obtain inventory information. From a business perspective, this interface interface is for the smooth operation of logistics and to ensure timely and accurate delivery of goods; from an application perspective, the interface defines the format and protocol for data transmission; and from a technical perspective, it involves technologies such as network communication and data encryption.

[0078] Through this step-by-step decomposition, the position and role of each business and system at different levels can be clarified, thus revealing the hierarchical relationships between them. For example, the requirements of the business layer determine the functional design of the application layer, while the implementation of the application layer's functions depends on the technical support of the technology layer. Furthermore, the mapping relationships between different layers can be discovered, i.e., how a specific goal is mapped to the business processes of the business layer, how the business layer's processes correspond to the functional modules of the application layer, and which technologies of the technology layer are used to implement the functional modules of the application layer.

[0079] In this invention, hierarchical and mapping relationships provide a crucial logical basis for constructing the target architecture model. Taking a financial enterprise's application platform as an example, assuming its goal is to improve customer service quality and efficiency, at the business layer, this might correspond to business needs such as optimizing account opening processes and accelerating loan approvals. At the application layer, to achieve these business needs, it might be necessary to develop functional modules such as online account opening systems and loan approval systems. At the technical layer, these functional modules rely on technical support such as database management systems and server clusters. Through hierarchical and mapping relationships, the entire path from strategic goals to technical implementation can be clearly seen, thus ensuring logical coherence and consistency between the various parts when constructing the target architecture model.

[0080] In this invention, different application platform types have different characteristics and requirements, which will affect the target architecture model. For example, enterprise resource planning (ERP) application platforms typically cover multiple core business areas of an enterprise, such as finance, procurement, and production. Their architecture model needs to have high integration and scalability to adapt to the enterprise's complex business processes and constantly changing business needs. Customer relationship management (CRM) application platforms, on the other hand, focus more on the collection, analysis, and utilization of customer information. Their architecture model may place greater emphasis on data accuracy and security, as well as close integration with marketing, sales, and other business operations. Therefore, when constructing the target architecture model, it is necessary to fully consider the type of application platform to ensure that the model can meet the specific requirements of that type of application platform.

[0081] Furthermore, considering hierarchical relationships, mapping relationships, and application platform types, appropriate methods and tools (such as architecture design software and flowchart tools) are used to construct the target architecture model. The target architecture model details the structure and interrelationships of various business functions within the application platform at different levels, and how these functions are implemented through technical means. The significance of constructing the target architecture model lies in providing enterprises with a clear guiding framework, helping them make reasonable decisions when building, upgrading, and optimizing application platforms, and ensuring that the application platform aligns with the enterprise's strategic goals, business processes, and technological environment.

[0082] Based on the above embodiments, the step of constructing the target architecture model corresponding to each business function in the application platform according to the hierarchical relationship, the mapping relationship, and the application platform type includes: When the application platform type is determined to be a business process type, the application platform is layered according to the business process sequence based on the hierarchical relationship and the mapping relationship, and the target architecture model corresponding to each business function in the application platform is constructed. When the application platform type is determined to be a system function type, the application platform is functionally driven and layered according to business functions based on the hierarchical relationship and the mapping relationship, and the target architecture model corresponding to each business function in the application platform is constructed based on the obtained business function modules. When the application platform type is determined to be a data-driven type, the application platform is divided into data-driven layers according to the data responsibility and data flow direction based on the hierarchical relationship and the mapping relationship, so as to divide the application platform into corresponding data providers, data processors and data consumers; based on the data providers, the data processors and the data consumers, the target architecture model corresponding to each business function in the application platform is constructed.

[0083] In this invention, once it is determined that the application platform belongs to a business process type, a target architecture model needs to be constructed based on the hierarchical and mapping relationships obtained in the above embodiments. The hierarchical relationships reveal the position of different business processes within the overall architecture, while the mapping relationships clarify the correspondence between business objectives, processes, and system functions. For example, in an e-commerce business process, from a user placing an order to product delivery, multiple business processes are involved. The hierarchical relationships determine the position of each process within the e-commerce business architecture, and the mapping relationships clarify which system functions correspond to each process.

[0084] Furthermore, the system is layered according to the business process sequence, with the business process as the main thread, precisely corresponding the application system to each business link. Taking the R&D business process of a manufacturing enterprise as an example, the R&D process includes requirements management, design, simulation, process, and testing and verification. In the business-driven layering, the requirements management link corresponds to the requirements management application module, which is responsible for collecting, organizing, and analyzing product requirements information; the design link corresponds to the design application module, used for product design; the simulation link corresponds to the simulation application module, which can simulate and test the designed product; the process link corresponds to the process application module, which formulates the product's production process; and the testing and verification link corresponds to the testing and verification application module, which conducts actual testing and verification of the product. The system is configured and integrated according to this process sequence to ensure that information can flow completely along the main business line without information gaps or inefficient flow.

[0085] Based on the above hierarchical results, a target architecture model is constructed. This model clearly illustrates the application modules corresponding to each business process, as well as their interactions and data flows. For example, requirement information generated by the requirement management module flows to the design module. After completing the design, the design module transmits the design data to the simulation module for testing. The simulation results are then fed back to the design module for optimization. The optimized design then enters the process module to formulate the process, and finally, it goes to the testing and verification module for verification. Through this model, enterprises can intuitively understand the operation of the application system throughout the entire business process, facilitating management and optimization.

[0086] Once the application platform is determined as a system function type, hierarchical and mapping relationships must also be considered. Hierarchical relationships help to divide functional modules into levels, while mapping relationships clarify the connection between functions and business needs, as well as system goals. For example, in an enterprise management system, different functional modules such as human resource management, financial management, and procurement management can have their hierarchical positions within the system architecture determined by hierarchical relationships, and mapping relationships explain how each functional module meets the enterprise's business needs.

[0087] Furthermore, based on business functions, a function-driven layering approach is adopted, breaking down complex application systems into multiple independently reusable functional modules. Taking a Product Lifecycle Management (PLM) platform as an example, the system is divided into modules such as configuration management, change management, document management, and project management. The configuration management module is responsible for managing product configuration information, ensuring the accuracy of configurations at different stages and versions; the change management module handles change requests during product design and production, and tracks the implementation of changes; the document management module manages various product-related documents, such as design drawings and technical specifications; and the project management module manages projects throughout the product's entire lifecycle, including project planning and progress tracking. Each module can run independently to complete specific functional tasks, or it can be reused within the platform or across platforms, avoiding redundant construction and improving system development efficiency and maintenance costs.

[0088] Based on the obtained business functional modules, a target architecture model is constructed. This target architecture model illustrates the relationships and interaction methods between the various functional modules. For example, in a PLM platform, the project management module might call the configuration management module to obtain product configuration information in order to formulate a reasonable project plan; when processing changes, the change management module will interact with the document management module to update relevant documents; there is also a data association between the configuration management module and the document management module to ensure the consistency of configuration information and documents. Through such a model, enterprises can clearly understand the role and interrelationships of each functional module, facilitating the expansion and optimization of system functions.

[0089] Once the application platform is determined to be data-driven, analysis is performed based on hierarchical and mapping relationships. Hierarchical relationships determine the flow and processing of data at different levels, while mapping relationships clarify the correspondence between data and business functions and system modules. For example, in a group financial system, financial data at different levels has different processing methods and flows. Hierarchical relationships determine the levels of data processing for headquarters, subsidiaries, etc., while mapping relationships explain how financial data is related to various business function modules.

[0090] Furthermore, data-driven layering is implemented according to data responsibility and data flow, dividing the application platform into data providers, data processors, and data consumers. Taking the group's financial system as an example, subsidiaries, as data providers, are responsible for collecting and organizing their own financial data, such as revenue, expenses, and costs; headquarters, as data processors, summarizes, reviews, and analyzes the financial data provided by subsidiaries to generate the group's financial statements and financial analysis reports; and business systems, as data consumers, use the financial data processed by headquarters for business decisions, such as budgeting and project evaluation. The entire architecture's division and construction revolve around data flow, focusing on resolving data consistency and cross-level data reconciliation issues to ensure data accuracy and timeliness.

[0091] Based on the defined data providers, data processors, and data consumers, a target architecture model is constructed. This model illustrates the flow and processing of data among these different roles. For example, a subsidiary's financial data is transmitted via network to the headquarters' data processing system. After processing, the headquarters stores the results in a database, and business systems retrieve the necessary data from the database for business analysis. Through this model, enterprises can clearly understand the source, processing, and usage of data, facilitating data management and optimization, and improving data quality and utilization efficiency.

[0092] Layered modeling enables the establishment of an architecture model that covers business scope, application affiliation, functional modules, functional items, interfaces, and operational configurations. This provides structured support for subsequent blueprint design, gap analysis, and implementation and promotion. Furthermore, the layering depth and modeling method can be flexibly adjusted according to enterprise size, industry characteristics, and management maturity.

[0093] Based on the above embodiments, the step of constructing the target blueprint data corresponding to the target enterprise according to the target architecture model includes: Based on the application platform system list, application platform system function list, application platform interface list, data responsibility list, and technology stack list corresponding to the target architecture model, obtain application layer division information, functional module boundary information, interface standard information, data responsibility attribution relationship, and technical support framework information. The target blueprint data is constructed based on the application hierarchy information, the functional module boundary information, the interface standard information, the data responsibility attribution relationship, and the technical support framework information.

[0094] In this invention, the application platform system list details various application platform systems within the enterprise, such as Enterprise Resource Planning (ERP) systems, Customer Relationship Management (CRM) systems, and Office Automation (OA) systems. By sorting and analyzing these systems, and combining them with the hierarchical structure (e.g., business layer, application layer, and technology layer) defined in the target architecture model, the application layer to which each system belongs can be clearly identified. For example, an ERP system typically involves multiple core business areas of an enterprise and may occupy an intersection of the business and application layers at the application layer. It supports the operation of the overall business processes of the enterprise (business layer) and implements various business functions through specific application modules (application layer). In this way, application layer classification information is obtained from the application platform system list, providing a hierarchical framework foundation for constructing the target blueprint data.

[0095] The application platform system function list details the functions of each application platform, such as customer information management, sales opportunity management, and customer service management in a CRM system. In the target architecture model, these functions are further refined and integrated into different functional modules. By analyzing the function list and combining it with the definitions and division rules of functional modules in the model, the boundaries of each functional module can be clarified, that is, determining which functions belong to the same module and where the functional boundaries between different modules lie. For example, in a CRM system, functions such as customer information management and customer communication records are divided into a customer management module, while functions such as sales opportunity tracking and sales forecasting are divided into a sales management module, thus clarifying the functional module boundary information.

[0096] The application platform interface list records the interfaces used for data interaction and communication between various application platforms and between application platforms and other systems or modules. Interface standard information includes the interface type (e.g., API interface, database interface), data transmission format (e.g., JSON, XML), communication protocol (e.g., HTTP, TCP / IP), and interface invocation methods and access control. By analyzing the interface list and combining it with the interface specification requirements in the target architecture model, interface standard information can be obtained. For example, if two application platforms transmit data via an API interface, specifying the use of JSON format for data transmission, HTTP protocol for communication, and corresponding invocation permissions, this information constitutes the interface standard information.

[0097] The data responsibility list clearly defines the responsible departments or systems for various types of data within an enterprise. In the target architecture model, data responsibility attribution is a crucial component, identifying the data producers, managers, and users. By analyzing the data responsibility list and combining it with the model's definitions of data flow and management, the data responsibility attribution can be determined. For example, regarding financial data, the finance department, as the primary responsible department, is responsible for collecting, organizing, and auditing financial data; regarding customer data, the marketing and sales departments may share primary responsibility, with the marketing department responsible for the initial collection of customer information and the sales department responsible for updating and maintaining that information.

[0098] The technology stack list documents the technologies used by an enterprise in building its application platform, including programming languages ​​(such as Java and Python), database management systems (such as MySQL and Oracle), server operating systems (such as Linux and Windows Server), and middleware (such as Tomcat and WebLogic). The technology support framework information describes how these technologies are combined and collaborate to support the operation and development of the application platform. By analyzing the technology stack list and combining it with the technical architecture requirements in the target architecture model, the technology support framework information can be obtained. For example, using Java as the programming language, MySQL as the database management system, Linux as the server operating system, and the Spring framework for application development constitutes the technology support framework.

[0099] Furthermore, the acquired application layer division information, functional module boundary information, interface standard information, data responsibility attribution, and technical support framework information are integrated to form a complete target blueprint framework, clarifying the position and interrelationships of each part. For example, at the application layer, the specific content and scope of the business layer, application layer, and technical layer are determined; regarding functional modules, the boundaries and functions of each functional module are clarified; regarding interfaces, the standards and specifications of the interfaces are defined; regarding data, the responsibility attribution of data is determined; and regarding technology, the technical support framework is constructed.

[0100] When designing the target blueprint data, the principles of scalability and modularity are followed. The scalability principle ensures the blueprint can adapt to future development and changes within the enterprise, allowing for easy expansion and adjustment when new businesses, systems, or functions are added. For example, when designing the application layer, space is reserved for the integration of new business systems; when designing functional modules, a modular design approach is adopted, enabling independent development and upgrades for each module and facilitating the integration of new functional modules. The modularity principle breaks down complex systems into multiple independent modules, each with clearly defined functions and interfaces, facilitating development, maintenance, and management. For example, the functional modules of the application platform are divided into independent microservices, each of which can be deployed and run independently, communicating and collaborating through interfaces.

[0101] In this invention, based on integrated information and design principles, specific target blueprint data deliverables are generated, including application blueprint diagrams, interface standard documents, data responsibility tables, and functional module directories. The application blueprint diagrams graphically display information such as application hierarchy, functional module boundaries, and interface connection relationships, intuitively presenting the overall architecture of the application platform. For example, a hierarchical structure diagram is used to represent the application hierarchy, rectangles are used to represent functional modules, and arrows are used to represent interface connections.

[0102] Interface standard documents describe in detail the types of interfaces, data transmission formats, communication protocols, invocation methods, and access control, providing specifications and guidance for the development and use of interfaces.

[0103] The data responsibility table lists the responsible departments or systems for various types of data in tabular form, clarifying the management responsibilities for the data.

[0104] The functional module directory lists all the functional modules in the application platform and provides a brief description of the function of each module, making it easy to manage and query the functional modules.

[0105] This invention, by constructing target blueprint data, can rationally plan its own system construction based on information such as application hierarchy and functional module boundaries in the blueprint, avoiding redundant construction and the emergence of system silos; based on interface standard information, it ensures interface compatibility and smooth data interaction between different systems; based on data ownership, it clarifies data management responsibilities, ensuring data accuracy and consistency; and based on technical support framework information, it selects appropriate technologies for system development, improving system stability and maintainability.

[0106] Based on the above embodiments, the step of comparing the current system status list with the target blueprint data to obtain a list of gaps between the current system status list and the target blueprint data includes: Based on the numbering information of each sub-department, the current status list of the system is compared with the corresponding department blueprint data in the target blueprint data to obtain the system overlap rate, uncovered business domain information, interface difference information, data responsibility conflict information and technology stack difference information corresponding to each sub-part. The gap list is constructed based on the system overlap rate, the information of the uncovered business domains, the interface difference information, the data responsibility conflict information, and the technology stack difference information.

[0107] In this invention, the sub-department number serves as a location identifier, clearly defining the scope of each sub-department within the enterprise's architecture and data system. When comparing the current system status quo list with the departmental blueprint data in the target blueprint data, the sub-department number allows for quick and accurate matching and comparison of the content related to a specific sub-department in the current system status quo list with the corresponding blueprint data in the target blueprint. For example, in a large group enterprise, there are multiple sub-departments with different business directions, each with a unique number. During comparison, the relevant data for each sub-department in the current system status quo and the target blueprint can be accurately located based on the number, avoiding data confusion and erroneous comparisons, and ensuring the accuracy and reliability of the comparison results.

[0108] Specifically, system overlap rate is a crucial indicator for measuring the degree of system duplication across different sub-departments. During the comparison process, a detailed review and analysis of the current system inventory and departmental blueprint data are conducted. The number of duplicate systems across different sub-departments is counted; these are systems independently built in multiple sub-departments with similar functions. Then, the proportion of duplicate systems to the total number of systems in each sub-department is calculated, thus yielding the system overlap rate. For example, sub-department A and sub-department B have each built independent customer management systems, and these two systems have significant functional overlap. Statistics show that there are N such duplicate systems, and the total number of systems in sub-departments A and B is M. Therefore, the system overlap rate is N / M. An excessively high system overlap rate leads to wasted enterprise resources and increased maintenance costs. Obtaining this information provides a clear understanding of the extent of system duplication.

[0109] Information on uncovered business domains reflects deficiencies in the current system's support for enterprise business processes. Comparing the system functions in the current system status quo list with the planned business processes and functional requirements in the departmental blueprint data identifies which key business processes or links lack corresponding system support in the existing system construction. For example, the target blueprint data might plan for a sub-department to have a complete supply chain management system to support the entire business process from procurement to sales. However, the current system status quo list only shows that the sub-department has systematized the procurement process; the sales process lacks system support. Therefore, the sales process falls under the uncovered business domain. Obtaining information on uncovered business domains helps enterprises identify shortcomings in system construction, providing direction for subsequent system improvements and functional expansions.

[0110] As interfaces for data interaction and communication between different systems, interface differences can affect system integration and data flow. When comparing the current system inventory and departmental blueprint data, a detailed examination of interface protocols, data structures, and calling methods is crucial. This includes checking for consistent interface protocols (e.g., some systems use HTTP while others use FTP); matching data structures (e.g., differences in data field types, lengths, and formats); and consistent calling methods (e.g., the difference between synchronous and asynchronous calls). These checks identify inconsistencies and gather information on interface differences. Significant interface differences can prevent normal communication between systems, lead to data transmission errors, and disrupt overall business processes.

[0111] Data responsibility conflicts involve inconsistencies in the attribution and definition of similar data across different systems or organizations. A comparison should be made between the data management status in the system current status list and the data responsibility attribution defined in the departmental blueprint data. This identifies which data has unclear attribution or inconsistent definitions across different sub-departments or systems. For example, regarding customer data, sub-department C may believe it is responsible for collecting and updating it, while sub-department D may also believe it has management responsibility for this data, with differences in data recording format and content. This constitutes a data responsibility conflict. Data responsibility conflicts lead to data inconsistencies, impacting the accuracy of corporate decision-making and operational efficiency.

[0112] Differences in technology stacks reflect the diversity of technologies used by an enterprise in system construction. This involves compiling a list of current system status and departmental blueprints, identifying the operating systems, databases, middleware, and development frameworks involved. The types and quantities of these technologies are statistically analyzed, along with their differences. For example, some sub-departments use Linux, while others use Windows Server; regarding databases, some use MySQL, while others use Oracle. The compatibility and evolution difficulty of these technology stacks must be assessed. Excessive differences in technology stacks can lead to difficulties in system integration, increased maintenance costs, and hinder the unification and upgrading of the enterprise's overall technology.

[0113] Furthermore, the acquired system overlap rate, uncovered business domain information, interface difference information, data responsibility conflict information, and technology stack difference information are systematically integrated. Based on this information, a gap list framework is constructed, thereby summarizing and organizing different types of problems according to certain logic and classification. For example, problems related to system overlap rate can be grouped into one category, problems related to uncovered business domain information into another category, and so on, forming a clear and organized checklist framework.

[0114] Based on the checklist framework, each type of problem is meticulously documented. For system overlap issues, the names of duplicate systems, their respective sub-departments, and the degree of duplication are recorded. For uncovered business domain issues, the names of uncovered business processes or steps and their impact on the business are recorded. For interface differences issues, the interface names, involved sub-departments, and specific details of the differences are recorded. For data responsibility conflicts, the names of the conflicting data, the involved sub-departments, and the specific manifestations of the conflict are recorded. For technology stack differences, the names of different technologies, the sub-departments using them, and assessments of compatibility and evolution difficulty are recorded. Through these detailed records, the gap checklist comprehensively and accurately reflects the gap between the current state of the enterprise's systems and the target blueprint.

[0115] Following the steps outlined above, detailed records of all issues are compiled to form a comprehensive gap list. This list not only includes specific problems in areas such as enterprise system construction, functional coverage, data governance, and technical support, but also provides detailed evidence for subsequent analysis and improvement. For example, enterprises can use the information in the gap list to formulate targeted improvement measures, clarify the priorities and directions of improvement, thereby gradually narrowing the gap between the current situation and the target blueprint, and promoting the continuous improvement and development of enterprise informatization.

[0116] Figure 2 The diagram below illustrates the scalable application architecture for multi-level control scenarios provided by this invention. (See attached diagram.) Figure 2As shown, firstly, based on the existing application platforms within the target enterprise, a system objective list is obtained, resulting in a set of desired system construction goals. This system objective list clarifies the various functional and business objectives the enterprise hopes to achieve through the application platform, providing guidance for subsequent architecture design. For example, in the R&D field, this might include goals such as building a comprehensive R&D management system and achieving efficient R&D process collaboration.

[0117] Next, based on the system target list and layered modeling method, target architecture models corresponding to each business function in the application platform are constructed. For example... Figure 2 The four-layer architecture design, combined with a multi-level control mechanism, constructs an application architecture consisting of four layers: a management decision-making layer, a business collaboration layer, a functional module layer, and a basic support layer. Layered modeling is fully utilized here. Taking the management decision-making layer as an example, a unified architecture blueprint, standard specifications, and evaluation system are established, clearly defining the layer's position and function within the overall architecture and providing a framework for guidance and supervision of lower-level architectures. The business collaboration layer, through standardized process and interface design, establishes cross-departmental and cross-subsidiary process links and data sharing, reflected in the target architecture model as specific collaborative process and interface specification designs. The functional module layer constructs functional sub-items around the enterprise's core R&D activities, forming a unified functional catalog system, which, in the target architecture model, defines the boundaries, functions, and interrelationships of each functional module in detail. The basic support layer employs cloud-native, containerized, and IT-innovation compatible technologies to provide a sustainable technological foundation for the target architecture model.

[0118] Then, based on the target architecture model, target blueprint data corresponding to the target enterprise is constructed. This target blueprint data encompasses information such as application layer division, system module boundaries, interface specifications, data responsibility attribution, and technical support framework, serving as a unified reference standard for the entire group. For example, the application blueprint diagram graphically displays the application layer division and functional module boundaries; the interface standard document details the interface types and data transmission formats; the data responsibility table clearly identifies the responsible department or system for each type of data; the functional module catalog lists all functional modules and their functional descriptions; and the technical support framework information describes the technology combinations and collaboration methods. These deliverables collectively constitute the target blueprint data, used to guide subsequent system construction and integration for subsidiaries and departments.

[0119] Next, a system status list for each sub-department within the target company is obtained and compared with the target blueprint data to identify gaps. The system status list reflects the current system construction status of each sub-department, including existing systems, functions, interfaces, data management, and technology applications. Comparison with the target blueprint data reveals issues such as excessive system overlap, uncovered business domains, inconsistent interfaces, conflicting data responsibilities, and differences in technology stacks. For example, the comparison reveals duplicate system construction across different sub-departments (system overlap); certain key business processes are not supported by existing systems (covered business domains). These gaps are recorded in detail to form a gap list, providing a basis for subsequent adjustments.

[0120] Finally, based on the gap list, recommended adjustment information for application platform management is generated for the target enterprise. Based on the issues reflected in the gap list, and considering the enterprise's development stage and goals, targeted adjustment suggestions are formulated. For start-up enterprises, the focus can be on reducing redundant system construction and establishing basic functional coverage and data consistency; for developing enterprises, the goal is to unify interface standards, resolve cross-departmental process breakpoints, and improve system integration; for mature enterprises, the focus shifts to optimizing the consistency and scalability of the overall architecture, promoting cloud-native architecture, domestic IT adaptation, and cross-subsidiary data collaboration. In this way, reasonable application platform management adjustment solutions are provided to enterprises, improving the overall coordination and feasibility of their application architecture, and driving their digital transformation and intelligent development.

[0121] The following describes the multi-level management and control system based on a scalable application architecture provided by the present invention. The multi-level management and control system based on a scalable application architecture described below can be referred to in correspondence with the multi-level management and control method based on a scalable application architecture described above.

[0122] Figure 3 This is a schematic diagram of the structure of the multi-level management and control system based on a scalable application architecture provided by the present invention, such as... Figure 3As shown, this invention provides a multi-level management and control system based on a scalable application architecture, including a target list acquisition module 301, a hierarchical modeling module 302, a blueprint construction module 303, a gap analysis module 304, and a management and control recommendation module 305. The target list acquisition module 301 is used to obtain a system target list based on existing application platforms in the target enterprise; the hierarchical modeling module 302 is used to construct target architecture models corresponding to each business function in the application platform based on the system target list and the hierarchical modeling method; the blueprint construction module 303 is used to construct target blueprint data corresponding to the target enterprise according to the target architecture model; the gap analysis module 304 is used to obtain a system status list for each sub-department in the target enterprise, compare the system status list with the target blueprint data, and obtain a gap list between the system status list and the target blueprint data; the management and control recommendation module 305 is used to generate management and control adjustment recommendation information for the application platform corresponding to the target enterprise based on the gap list.

[0123] The multi-level management and control system based on a scalable application architecture provided by this invention constructs a target architecture model using a layered modeling method based on the target enterprise's existing application platform system target list, thereby generating target blueprint data. Then, it compares the current status list of sub-department systems with the blueprint data to form a gap list, and finally generates application platform management and control adjustment recommendation information based on this, thereby reducing the application duplication rate and improving data interoperability efficiency.

[0124] The system provided in this embodiment of the invention is used to execute the above-described method embodiments. For specific processes and details, please refer to the above embodiments, which will not be repeated here.

[0125] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 4As shown, the electronic device may include: a processor 401, a communications interface 402, a memory 403, and a communication bus 404. The processor 401, communications interface 402, and memory 403 communicate with each other via the communication bus 404. The processor 401 can call logical instructions in the memory 403 to execute a multi-level control method based on a scalable application architecture. This method includes: obtaining a system target list based on the existing application platform in the target enterprise; constructing a target architecture model corresponding to each business function in the application platform based on the system target list and a hierarchical modeling method; constructing target blueprint data corresponding to the target enterprise according to the target architecture model; obtaining a system status list for each sub-department in the target enterprise, comparing the system status list with the target blueprint data, and obtaining a gap list between the system status list and the target blueprint data; and generating application platform control adjustment recommendation information corresponding to the target enterprise based on the gap list.

[0126] Furthermore, the logical instructions in the aforementioned memory 403 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0127] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, wherein when the program instructions are executed by a computer, the computer is able to execute the multi-level control method based on the scalable application architecture provided by the above methods, the method comprising: obtaining a system target list based on the existing application platform in the target enterprise; constructing a target architecture model corresponding to each business function in the application platform based on the system target list and a hierarchical modeling method; constructing target blueprint data corresponding to the target enterprise according to the target architecture model; obtaining a system status list of each sub-department in the target enterprise, and comparing the system status list with the target blueprint data to obtain a gap list between the system status list and the target blueprint data; and generating application platform control adjustment recommendation information corresponding to the target enterprise based on the gap list.

[0128] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the multi-level management and control method based on a scalable application architecture provided in the above embodiments. The method includes: obtaining a system target list based on an existing application platform in a target enterprise; constructing a target architecture model corresponding to each business function in the application platform based on the system target list and a hierarchical modeling method; constructing target blueprint data corresponding to the target enterprise according to the target architecture model; obtaining a system status list for each sub-department in the target enterprise, and comparing the system status list with the target blueprint data to obtain a gap list between the system status list and the target blueprint data; and generating application platform management and control adjustment recommendation information corresponding to the target enterprise based on the gap list.

[0129] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-level management and control method based on an extensible application architecture, characterized in that, include: Based on the existing application platforms within the target enterprise, obtain a list of target systems; Based on the system target list and the hierarchical modeling method, construct the target architecture model corresponding to each business function in the application platform; Based on the target architecture model, construct the target blueprint data corresponding to the target enterprise; Obtain a list of the current status of systems in each sub-department of the target enterprise, and compare the list of current status of systems with the target blueprint data to obtain a list of gaps between the list of current status of systems and the target blueprint data; Based on the gap list, application platform management and control adjustment recommendation information is generated for the target enterprise.

2. The multi-level governance method based on extensible application architecture according to claim 1, wherein, After generating application platform management and control adjustment recommendation information for the target enterprise based on the gap list, the method further includes: Add a new application platform to the target enterprise, and based on the new application platform, obtain a new system target list, and construct new target blueprint data according to the new system target list.

3. The multi-level management and control method based on a scalable application architecture according to claim 1, characterized in that, The process of obtaining a system target list based on existing application platforms within the target enterprise includes: Data is collected from the system logs, configuration files, document content, and user feedback information of the existing application platforms in the target enterprise to obtain an application platform system list, an application platform system function list, an application platform interface list, a data responsibility list, and a technology stack list. The application platform system list includes the system list of application platforms that have been built or are under construction. Based on the application platform system list, the application platform system function list, the application platform interface list, the data responsibility list, and the technology stack list, determine the application dependencies, system call relationships, number of interfaces, and data flow information corresponding to the existing application platforms in the target enterprise; Based on the application dependencies, system call relationships, number of interfaces, and data flow information, the system target list is constructed.

4. The multi-level management and control method based on a scalable application architecture according to claim 3, characterized in that, The construction of target architecture models corresponding to each business function in the application platform based on the system target list and hierarchical modeling method includes: Based on the aforementioned hierarchical modeling method and preset hierarchical mode, the corresponding businesses and systems in the application platform system list, the application platform system function list, and the application platform interface list are decomposed level by level to obtain the hierarchical relationship and mapping relationship between each business and system; Based on the hierarchical relationship, the mapping relationship, and the application platform type, construct the target architecture model corresponding to each business function in the application platform.

5. The multi-level management and control method based on a scalable application architecture according to claim 4, characterized in that, The step of constructing the target architecture model corresponding to each business function in the application platform based on the hierarchical relationship, the mapping relationship, and the application platform type includes: When the application platform type is determined to be a business process type, the application platform is layered according to the business process sequence based on the hierarchical relationship and the mapping relationship, and the target architecture model corresponding to each business function in the application platform is constructed. When the application platform type is determined to be a system function type, the application platform is functionally driven and layered according to business functions based on the hierarchical relationship and the mapping relationship, and the target architecture model corresponding to each business function in the application platform is constructed based on the obtained business function modules. When the application platform type is determined to be a data-driven type, the application platform is divided into business-driven layers according to the data responsibility and data flow direction based on the hierarchical relationship and the mapping relationship, so as to divide the application platform into corresponding data providers, data processors and data consumers; based on the data providers, the data processors and the data consumers, the target architecture model corresponding to each business function in the application platform is constructed.

6. The multi-level management and control method based on a scalable application architecture according to claim 3, characterized in that, The step of constructing the target blueprint data corresponding to the target enterprise based on the target architecture model includes: Based on the application platform system list, application platform system function list, application platform interface list, data responsibility list, and technology stack list corresponding to the target architecture model, obtain application layer division information, functional module boundary information, interface standard information, data responsibility attribution relationship, and technical support framework information. The target blueprint data is constructed based on the application hierarchy information, the functional module boundary information, the interface standard information, the data responsibility attribution relationship, and the technical support framework information.

7. The multi-level management and control method based on a scalable application architecture according to claim 3, characterized in that, The step of comparing the current system status list with the target blueprint data to obtain a list of gaps between the current system status list and the target blueprint data includes: Based on the numbering information of each sub-department, the current status list of the system is compared with the corresponding department blueprint data in the target blueprint data to obtain the system overlap rate, uncovered business domain information, interface difference information, data responsibility conflict information and technology stack difference information corresponding to each sub-part. The gap list is constructed based on the system overlap rate, the information of the uncovered business domains, the interface difference information, the data responsibility conflict information, and the technology stack difference information.

8. A multi-level management and control system based on a scalable application architecture, characterized in that, include: The target list acquisition module is used to obtain the system target list based on the existing application platforms in the target enterprise; The hierarchical modeling module is used to construct the target architecture model corresponding to each business function in the application platform based on the system target list and the hierarchical modeling method. The blueprint construction module is used to construct target blueprint data corresponding to the target enterprise based on the target architecture model; The gap analysis module is used to obtain a list of the current status of the systems in each sub-department of the target enterprise, and compare the list of the current status of the systems with the target blueprint data to obtain a list of gaps between the list of the current status of the systems and the target blueprint data. The management and control recommendation module is used to generate application platform management and control adjustment recommendation information for the target enterprise based on the gap list.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the multi-level management method based on a scalable application architecture as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-level management method based on a scalable application architecture as described in any one of claims 1 to 7.

Images