Classification setting method for group and subsidiary company two-level legal person enterprise architecture

Abstract

The invention provides a grading setting method for a group and subsidiary company two-stage legal person enterprise architecture. According to the hierarchical setting method of the group and subsidiary company two-stage legal person enterprise architecture, compatible coexistence of a unified standard and personalized asset management under the group and subsidiary company two-stage legal person enterprise architecture is realized, and the management and control precision and reuse efficiency of architecture assets are improved; the repeated construction cost is reduced; and the expansibility and the collaboration of an enterprise architecture system are enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of hierarchical management of enterprise architecture assets, and in particular to a hierarchical setting method for a two-level legal enterprise architecture of a group and a subsidiary. BACKGROUND

[0002] Enterprise architecture management, as the core foundation of digital construction of large groups, is widely used in financial, energy, manufacturing and other industries. In related technologies, through the coordinated operation of the five-dimensional architecture model of business, data, application, technology and security and the directory system, a technical ecology combining unified standards and personalized management is constructed. Specifically, this technical system covers the whole process from strategic planning to asset sedimentation, including key links such as asset classification standard formulation, permission control rule design, and sharing mechanism establishment. The existing technology usually adopts a flat centralized management mode of a single legal person enterprise, and its core feature is to only set an enterprise-level asset total directory and a project-level asset directory, to achieve simple classification through asset type tags, and to only distinguish between administrator and project user roles in permission rules, and the directory structure does not reflect the hierarchical relationship of group level-subcompany level-project level.

[0003] However, in the existing technical solution, the "enterprise-level asset total directory + project-level asset directory" double-layer structure is directly adopted, and the standard inheritance and permission isolation coordination mechanism is not established, which may lead to conflicts between group strategy execution and subsidiary innovation needs. Specifically, the traditional directory system has three technical defects in the two-level legal person scenario: first, it lacks a multi-level architecture asset isolation mechanism of "group standard layer-current level supplement layer-project sedimentation layer", leading to the risk of version conflict between unified standards and personalized assets; second, the permission control rules do not realize hierarchical authorization, and the administrator role centrally controls all asset modification permissions, which cannot meet the needs of subsidiary self-management; third, there is a lack of bidirectional mapping relationship between project assets and enterprise standards, and high-quality assets cannot be upgraded to shared assets through the audit mechanism. Based on this, the existing technology needs to rely on manual coordination when sharing data across subsidiaries, and the asset reuse rate is less than 30%, and there is a problem of asset version fragmentation caused by permission confusion, which ultimately affects the resource integration efficiency and business collaboration ability of the group's digital transformation. SUMMARY

[0004] The present application aims to at least partially solve one of the technical problems in the related art.

[0005] To this end, a first object of the present application is to propose a hierarchical setting method for a two-level legal enterprise architecture of a group and a subsidiary.

[0006] A second object of the present application is to propose a hierarchical setting device for a two-level legal enterprise architecture of a group and a subsidiary.

[0007] A third object of the present application is to propose an electronic device.

[0008] A fourth object of the present application is to propose a computer-readable storage medium.

[0009] A fifth object of the present application is to propose a computer program product.

[0010] A fourth object of the present application is to propose a computer-readable storage medium.

[0011] To achieve the above object, the first aspect of the present application proposes a hierarchical setting method of a two-level legal person enterprise architecture of a group and a subsidiary, comprising: S1, constructing a three-level architecture asset directory system comprising a group parent directory, a current directory and a project-level directory, wherein the group parent directory stores unified core architecture standards of the whole group, the current directory stores personalized architecture assets exclusive to the group or the subsidiary, and the project-level directory stores architecture assets related to each project and is associated with the standards of the parent directory or the current directory; S2, setting differentiated permission control rules for the three-level directories, the group parent directory only allows the group architecture administrator to perform creation, modification and deletion operations, and key operations need to go through the double processes of department audit and committee approval; the current directory is managed by the current architecture administrator, and when modified, a compliance explanation of the parent standard needs to be submitted; the project-level directory is created and modified by the project team members, and asset release needs to be audited by the current architecture management department; S3, defining the sharing range through a permission tag system, the group parent directory is set to be visible to the whole group and prohibited from unauthorized modification, the current directory is set to be visible to the current level and needs to be authorized to access, and the project-level directory is set to be visible within the project and supports asset upgrade to the upper directory; S4, establishing an asset upgrade mechanism, marking the architecture assets in the project-level directory that meet the reuse conditions of the current level as reusable and upgrading them to the current directory, and upgrading the architecture assets that meet the whole group reuse conditions to the group parent directory after being approved by the group architecture management department.

[0012] In an embodiment of the present application, the three-level architecture asset directory system comprising a group parent directory, a current directory and a project-level directory further comprises: S11, the group parent directory is organized according to a three-level classification structure of “domain-category-asset”, wherein the domain includes business architecture, data architecture, application architecture, technology architecture and security architecture, the category is a subdivision module under each domain, and the asset is a specific reusable architecture element; S12, the project-level directory sets asset association identifiers in the five subdirectories of “business, data, application, technology and security”, and realizes standard inheritance by referencing the asset numbers of the parent directory or the current directory.

[0013] In one embodiment of the present invention, the step of setting differentiated permission control rules for the three-level directory further includes: S21, the departmental review process for key operations includes the architecture management department conducting a compliance review of the modified content and generating a compliance report; S22, the committee approval process involves the group architecture committee making a final confirmation of the compliance report, and the asset modification operation can only be executed after the approval is passed.

[0014] In one embodiment of the present invention, defining the sharing scope through the permission tag system further includes: S31, the group-wide visible tag is implemented through the system's preset global access permissions, prohibiting any editing requests from non-group architecture administrators; S32, the local visible tag automatically matches access permissions through the user's organizational structure attributes, and external entities need to submit a cross-level authorization application and obtain approval from the superior architecture administrator to access it.

[0015] In one embodiment of the present invention, it further includes: S5, establishing an asset association verification mechanism, which forcibly verifies the association relationship between the assets and the parent directory or the current directory when the project-level directory is created, and prohibits the asset publishing operation if the association relationship is missing.

[0016] To achieve the above objectives, a second aspect of the present invention proposes a hierarchical setup device for a two-tier corporate structure of a group and its subsidiaries, comprising: a three-tiered structure asset catalog construction module, used to construct a three-tiered structure asset catalog system including a group parent catalog, a local catalog, and a project-level catalog, wherein the group parent catalog stores the unified core architecture standards of the entire group, the local catalog stores the personalized architecture assets exclusive to the group or its subsidiaries, and the project-level catalog stores the architecture assets related to each project and is associated with the standards of the parent catalog or the local catalog; and a differentiated permission control module, used to set differentiated permission control rules for the three-tiered catalogs, wherein the group parent catalog is only allowed to be created, modified, and deleted by the group architecture administrator, and key operations require a dual process of departmental review and committee approval; the local catalog is managed by the local architecture administrator, and modifications require the submission of a parent standard compliance statement; the project-level catalog is created and modified by project team members, and asset releases require review by the local architecture management department; The permission tag sharing scope definition module is used to define the sharing scope through the permission tag system. The group parent directory is set to be visible to the whole group and unauthorized modification is prohibited. The current directory is set to be visible to the current level and requires authorized access. The project-level directory is set to be visible within the project and supports asset upgrades to the parent directory. The asset upgrade mechanism establishment module is used to establish an asset upgrade mechanism. The architecture assets in the project-level directory that meet the reuse conditions of the current level are marked as reusable and upgraded to the current level directory. The architecture assets that meet the reuse conditions of the whole group are upgraded to the group parent directory after being approved by the group architecture management department.

[0017] To achieve the above objectives, a third aspect of the present invention provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of the first aspects.

[0018] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method as described in any one of the first aspects.

[0019] To achieve the above objectives, a fifth aspect of the present invention provides a computer program product that, when executed by a processor, implements the method described in any one of the first aspects.

[0020] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: achieving compatibility and coexistence of unified standards and personalized asset management under the two-level legal entity structure of the group and its subsidiaries, improving the control accuracy and reuse efficiency of the structured assets, and supporting the balance between the implementation of the group's strategy and the flexible operation of the subsidiaries.

[0021] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a hierarchical setting method for a two-tier corporate structure of group and subsidiaries according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the hierarchical setup device for a two-tier corporate structure of group and subsidiaries according to an embodiment of the present invention. Detailed Implementation

[0023] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0024] like Figure 1 As shown, the hierarchical setup method for a two-tier corporate structure consisting of a group and its subsidiaries includes the following steps: S1 constructs a three-level architecture asset directory system, including a group parent directory, a local directory, and a project-level directory. The group parent directory stores the unified core architecture standards of the entire group, the local directory stores the personalized architecture assets exclusive to the group or its subsidiaries, and the project-level directory stores the architecture assets related to each project and associates them with the standards of the parent directory or the local directory.

[0025] Specifically, the core of this step is to build a three-level architecture asset directory system that includes a group parent directory, a local directory, and a project-level directory. Its technical implementation is based on the directory structure design and access control mechanism of the enterprise architecture management platform, aiming to achieve unified management, hierarchical sharing, and precise reuse of architecture assets.

[0026] At the technical implementation level, this three-level directory system adopts a tree-like hierarchical structure, achieving collaborative asset management through "standard inheritance + permission isolation". The group-level parent directory serves as the top-level unified standard layer, storing unified business, data, application, technology, and security architecture standards across the entire group. The directory structure is divided according to "domain-category-asset", such as "data architecture-data standards-enterprise subject domain". This directory is maintained by the group architecture administrator, with permissions set to allow only creation, modification, and deletion operations. Critical operations require a dual-process control mechanism of "department review-committee approval" to ensure the authority and consistency of the standards.

[0027] This directory serves as an intermediate layer, storing customized architectural assets specific to the group headquarters or its subsidiaries. Its directory structure remains consistent with the parent directory, with content expansion only occurring within the "Project-Level Asset Directory." For example, subsidiaries can add process models tailored to their specific business needs under "Business Architecture - Business Processes." This directory is managed by the local architecture administrator; modifications require a "Parent Standard Compliance Statement" to ensure compliance with group-wide standards. Sharing scope is controlled via the "Local Visible" tag, granting default access only to local users; external access requires authorization.

[0028] The project-level directory serves as the underlying asset accumulation layer, creating an independent directory for each project and further subdividing it into five subdirectories: Business, Data, Application, Technology, and Security Architecture. Project team members have "create" and "modify" permissions, and asset releases require approval from the local architecture management department. After a project concludes, assets meeting the reuse criteria can be marked as "reusable" by the local architecture management department and upgraded to the local directory or the group's parent directory based on their general applicability, thus achieving a dynamic asset accumulation and reuse mechanism.

[0029] At the parameter level, the directory system has a three-layer hierarchy, and assets are categorized into five types (business, data, application, technology, and security). Access control granularity reaches the directory level, role level, and operation level. The sharing scope supports both "visible to the entire group" and "visible to this level" modes. Furthermore, in the asset upgrade mechanism, an asset must achieve a compliance score of ≥ 85% (based on a matching degree assessment with the parent standard) to enter the upgrade process.

[0030] In application scenarios, this three-tiered directory system is suitable for two-tiered corporate organizational structures, including group and subsidiary levels. It is particularly effective in large group enterprises in sectors such as finance, energy, and manufacturing, supporting standardized corporate architecture, flexible subsidiary expansion, and the management needs for the reuse of project assets. Through this system, enterprises can achieve full lifecycle management of their organizational assets, improve asset reuse rates, and reduce the cost of redundant construction.

[0031] The technical effect of this step is that, through structured directory design and permission isolation mechanisms, it solves core problems in existing technologies such as "conflict between unified standards and personalized needs", "insufficient precision in asset sharing and permission control", and "inability to retain and reuse project assets". It realizes hierarchical management, precise sharing and efficient reuse of enterprise architecture assets, and has significant dual value of management standardization and business flexibility.

[0032] Furthermore, S1 includes: S11, the group's parent directory is organized according to a three-level classification structure of "domain-category-asset". The domain includes business architecture, data architecture, application architecture, technical architecture and security architecture. The category is the sub-module under each domain. The asset is the specific reusable architectural element.

[0033] Specifically, in this application proposal, the group's parent directory is organized according to a three-level classification structure of "domain-category-asset," which is one of the core technical means to achieve compatibility and coexistence between the group's unified architectural standards and the personalized asset management of subsidiaries. The technical implementation of this step is based on the directory structure design of the enterprise architecture management platform, which ensures the uniformity, manageability, and reusability of architectural assets through standardized classification logic and permission isolation mechanisms.

[0034] At the technical implementation level, the group's parent directory is constructed using a tree-like hierarchical structure, with the root node being the "Group Enterprise Architecture Standard Directory," which includes five domain directories: Business Architecture, Data Architecture, Application Architecture, Technical Architecture, and Security Architecture. Each domain directory is further subdivided into several category directories; for example, "Data Architecture" can include categories such as "Data Standards," "Data Models," and "Data Governance." Each category directory stores specific architectural assets; for instance, "Data Standards - Enterprise Theme Domain" contains unified data theme definitions and data classification specifications across the entire group. This structure follows the classification logic of the TOGAF (The OpenGroup Architecture Framework) enterprise architecture framework, ensuring that the organization of architectural assets conforms to international standards.

[0035] At the parameter level, the directory structure has a fixed three-level hierarchy: "Domain-Category-Asset". The domain level has five fixed options, while the category level can be expanded based on actual business needs, but must comply with the "Architecture Directory Classification Specification V1.0" formulated by the Group Architecture Committee. The asset level must meet the requirements of the "Architecture Asset Naming and Coding Specification V2.0", including asset names, coding rules, and version control mechanisms. Furthermore, directory permission settings follow the RBAC (Role-Based Access Control) model. Only the Group Architecture Administrator has "create, modify, and delete" permissions for assets in the parent directory; other users only have "view, reference, and download" permissions. Critical operations must be controlled through a dual-process mechanism of "department review - committee approval".

[0036] At the application level, this step is suitable for scenarios where the group headquarters conducts standardized management of the entire group's architectural assets under a unified strategic framework. For example, in the field of data architecture, the group can uniformly define a "customer data subject domain" and use it as the basis for the data model design of all subsidiaries, ensuring data consistency and interoperability between systems. At the same time, this directory structure provides a standard reference for the subsequent accumulation and upgrading of project-level assets, and is the foundation for realizing asset reuse and version evolution.

[0037] The technical advantage of this step lies in achieving unified management and mandatory constraints on the group's architectural standards through a structured and standardized catalog system. This prevents subsidiaries from arbitrarily modifying the group's standards during architectural design, thereby preventing architectural fragmentation. Simultaneously, this structure provides a clear path for asset classification, retrieval, and sharing, improving the management accuracy and reuse efficiency of architectural assets. It is a key supporting module for achieving "uniformity and compatibility" in the entire hierarchical setup method.

[0038] S12, the project-level directory sets asset association identifiers in the five subdirectories of "business, data, application, technology and security", and achieves standard inheritance by referencing the asset number of the parent directory or the current directory.

[0039] Specifically, in this application proposal, the step of "setting asset association identifiers in the five subdirectories of 'Business, Data, Application, Technology, and Security' for the project-level directory, and achieving standard inheritance by referencing the asset numbers of the parent directory or the current directory" is a key step in realizing the standardized inheritance of architectural assets and the accumulation of project-level assets. The technical implementation principle of this step is based on the asset referencing mechanism and directory hierarchy design in the enterprise architecture management platform. Through the unique identifier of the asset number and the explicit definition of the inheritance relationship, it ensures that project-level assets can form a logical association with the group or subsidiary-level architecture standards when they are created, thereby achieving standard reuse and consistency control.

[0040] At the technical implementation level, the five subdirectories of the project-level directory (Business, Data, Application, Technology, and Security) correspond to the five core dimensions of the enterprise architecture. Each asset in a subdirectory must be bound to one or more asset IDs upon creation. These IDs can come from the parent directory (the group enterprise architecture standard directory) or the current directory (the current enterprise architecture directory). Asset IDs follow a unified naming convention, such as the format R.type.name, where R represents the asset type (e.g., B for business assets, D for data assets), type represents the asset category (e.g., process for business processes), and name is the asset name. Through this structured identification, the system can automatically identify the asset's origin level and differentiate its handling in terms of access control, sharing scope, and version management.

[0041] At the parameter level, referencing an asset ID must meet the following conditions: the referenced asset ID must exist in the directory of the current user's legal entity level and have the "referenceable" permission tag; the reference relationship must be explicitly recorded in the asset metadata, including fields such as reference time, referencer, and reference version. Furthermore, the asset association identifier setting must support many-to-many mapping, meaning one project-level asset can reference multiple standard assets, and one standard asset can also be referenced by multiple project assets. The system records the parent-child relationships between assets by establishing a reference relationship table (reference_table), whose fields include source_id (source asset ID), target_id (target asset ID), and reference_type (reference type, such as inheritance, extension, combination, etc.).

[0042] At the application level, this step applies to various project implementation processes under a two-tiered legal entity structure of the group and its subsidiaries. For example, when a subsidiary is building a new business system, the project team can reference the group's unified business process standard (such as B.process.core_sales) in the project-level directory, and then extend or customize it locally to create assets that conform to the subsidiary's business characteristics (such as B.process.core_sales_sub1). Through the asset number inheritance mechanism, the system can automatically identify its association with the group's standard, facilitating subsequent asset upgrades, version comparisons, and compliance reviews.

[0043] The technical benefit of this step lies in achieving a logical binding between project-level assets and group / subsidiary standard assets through an asset number referencing and inheritance mechanism. This ensures that project assets consistently adhere to a unified architectural standard during design and implementation, while retaining necessary flexibility. Furthermore, after project completion, the system can upgrade reusable assets to the local or group-level catalog based on asset reference relationships and quality assessment results. This improves asset reuse rates, reduces redundant construction costs, and enhances the enterprise's lifecycle management capabilities for architectural assets.

[0044] S2 sets differentiated permission control rules for third-level directories. The group's parent directory can only be created, modified, and deleted by the group's architecture administrator, and critical operations require a dual process of departmental review and committee approval. Specifically, setting differentiated permission control rules for the three-level directory is a key technical step in achieving "hierarchical authorization + precise control" in this invention proposal. In some implementations, this step involves building a permission isolation mechanism in the enterprise architecture management platform to implement strict permission control over the "group parent directory," ensuring the authority and stability of its content. Specifically, the group parent directory, as the carrier layer of the unified architecture standard across the entire group, only allows the Group Architecture Administrator to perform creation, modification, and deletion operations. Its permission configuration must be based on the RBAC (Role-Based Access Control) model, achieving fine-grained permission allocation through a role binding policy.

[0045] At the parameter level, access control rules need to configure the following key parameters in the system: User Role ID, Permission Mask, Directory Path, and Approval Workflow ID. The Permission Mask defines the types of operations a user can perform on a directory, such as "Create=0x01", "Modify=0x02", and "Delete=0x04", using bitwise operations to combine and isolate permissions. Critical operations (such as deleting or modifying core architectural assets) must trigger a dual-process approval mechanism: first, the user's department initiates a review, followed by final approval by the Group Architecture Committee. This process can be implemented through a Workflow Engine, and the approval status must be recorded in the operation log to meet audit compliance requirements.

[0046] At the application level, this access control mechanism is suitable for centralized management scenarios where the group headquarters needs to maintain a unified architectural standard. Examples include defining core business processes in the business architecture, establishing enterprise-level data standards in the data architecture, and setting whitelists for technical components in the technical architecture. The system binds permission tags to directory paths to restrict access for unauthorized users, ensuring the immutability of the group's standard directories.

[0047] The technical effect of this step is that, through strict access control and a dual-process approval mechanism, it effectively prevents subsidiaries from misoperating or arbitrarily modifying the group's unified standards, thereby ensuring the uniformity and authority of the architecture standards. It solves the cross-organizational collaboration obstacles caused by "standard fragmentation" and "loss of access control" in existing technologies, and improves the control accuracy and governance efficiency of the group's architecture assets.

[0048] Furthermore, S2 includes: S21, the departmental review process for critical operations includes the architecture management department conducting a compliance review of the modified content and generating a compliance report.

[0049] Specifically, in this application proposal, the departmental review process for key operations is the core link in realizing "hierarchical access control" and "architectural asset compliance management." Its technical implementation is based on the access isolation mechanism and standard inheritance logic of the enterprise architecture management platform. Specifically, after an architectural asset completes its preliminary design and modifications in the project-level directory, it needs to be submitted to the architecture management department at that level for compliance review. This review process is implemented through the platform's built-in "standard compliance comparison engine." This engine performs structured matching and semantic consistency verification of project assets based on the preset group enterprise architecture standard directory (level one) and the asset classification rules in the enterprise architecture directory at that level (level two).

[0050] In some implementations, the architecture management department employs a multi-dimensional review mechanism, including but not limited to asset type matching, naming convention consistency, data model integrity, and technical component compliance. For example, in the data architecture subdirectory, the system automatically compares data entities in project assets with conceptual data entities (CDEs) in the group's standards and calculates their semantic similarity. ,like (in If the threshold is set to 0.85 (a preset threshold), then compliance is considered passed. Furthermore, in the technical architecture subdirectory, the system checks whether the selected technical component is in the group's technical component whitelist; if not, a warning is triggered and replacement is required.

[0051] The output of this process is a "compliance report," which includes fields such as asset name, asset type, audit status, explanation of non-compliance, and suggested modifications. The report format follows the structured requirements for architectural asset auditing in the ISO / IEC 23894 standard. Only assets that pass the audit can proceed to the release process; assets that fail must be revised and resubmitted for auditing.

[0052] In practice, this step is typically deployed within the "Asset Lifecycle Management Module" of an enterprise architecture management platform, supporting a hybrid auditing model that combines batch uploading, automatic verification, and manual review. Its technical value lies in ensuring that project assets meet unified standards and compliance requirements before being upgraded to the group or subsidiary's shared directory, thereby avoiding architecture fragmentation and improving asset reuse and system consistency.

[0053] S22, the committee approval process involves the Group Structure Committee making the final confirmation of the compliance report, and asset modification operations can only be carried out after approval.

[0054] Specifically, in some implementations, the committee approval process is the key control mechanism for achieving "company-wide standardization and subsidiary-specific compatibility" in this application proposal. Its technical implementation is based on the permission isolation and process control module within the enterprise architecture management platform. This process involves the group architecture committee providing final confirmation of the compliance report, ensuring that the architecture assets submitted by subsidiaries in their respective directories conform to the unified standards set in the parent directory of the group in terms of business logic, data models, application components, technology selection, and security strategies. The specific operation is as follows: when a subsidiary's architecture administrator submits an asset modification request in its own enterprise architecture directory, the system automatically generates a compliance report. The report includes a comparison of the asset before and after the change, a matching degree analysis with the parent standard, and potential conflict point alerts. This report is automatically pushed to the group architecture committee's approval module through a pre-set approval process.

[0055] At the parameter level, the compliance report must meet the following standards: the report should include at least Key inspection items include consistency of business terminology and the degree of matching between the data model and conceptual entities. Are the technical components on the group's whitelist? (1 indicates it's on the whitelist, 0 indicates it's not), and whether the security policy meets the group's security domain classification requirements. During the approval process, members of the Group Structure Committee need to... The approval process will be completed within one business day. The approval result will be updated to the system synchronously through the permission tag mechanism. The system will only allow the asset modification operation to be executed when the approval result is "passed".

[0056] At the application level, this approval process is widely used by subsidiaries to adjust architectural assets during business expansion, system upgrades, or data governance. For example, when a subsidiary needs to introduce a new business process model or deploy non-group standard technical components, this process must be used to ensure that the changes do not disrupt the consistency of the group's overall architecture. After approval, the asset will be formally included in the local directory and can be further upgraded to the group directory, enabling asset retention and reuse.

[0057] The technical advantage of this step lies in ensuring that modifications to the structural assets are both compliant and retain the flexibility of subsidiaries in their business practices by introducing a dual-process mechanism of "departmental review - committee approval." Simultaneously, the standardization and time constraints of the approval process... This ensures the efficiency and controllability of the process, thereby improving the overall collaborative efficiency and asset reuse capabilities of the group's organizational structure management.

[0058] S3 defines the sharing scope through the permission tag system. The parent directory of the group is set to be visible to the whole group and unauthorized modification is prohibited. The current directory is set to be visible to the current level and requires authorized access. The project-level directory is set to be visible within the project and supports asset upgrades to the parent directory.

[0059] Specifically, this step defines the sharing scope through a permission tag system, constructs a three-tiered asset catalog system under the two-tiered corporate structure of the group and its subsidiaries, and implements differentiated permission control strategies to achieve hierarchical sharing and precise management of structural assets. At the technical implementation level, this step designs the catalog structure and configures permission tags based on an enterprise architecture management platform (such as TOGAF, ArchiMate, or other standard-supported systems). Specific operations include: In some implementations, the group's parent directory serves as a first-level directory, storing the group's unified architectural standards and core assets. Its sharing scope is set to "visible to the entire group" via a permission tagging system, meaning all subsidiaries and group-level users can access the asset content under this directory. Regarding access control, this directory is set to "prohibit unauthorized modification," meaning only the group's architecture administrator has "create, modify, and delete" permissions, while other users only have "view, reference, and download" permissions. Critical operations such as asset modifications require a two-stage process of "department review - committee approval" to ensure standard consistency and controllable changes.

[0060] This directory, as a second-level directory, has its sharing scope set to "visible only to this level," meaning it is accessible only to users at the group level or subsidiary level. Access control requires authorization through a permission tagging system, such as a Role-Based Access Control (RBAC) model, assigning "create, modify, delete" permissions to the local architecture administrator, while other department users only have "view, reference, download" permissions. When submitting assets, a "parent standard compliance statement" must be provided to ensure it does not violate the group's unified standards, thereby achieving synergy between standard inheritance and personalized supplementation.

[0061] The project-level directory, as a third-level directory, has a default sharing scope of "visible within the project," meaning it is only accessible to project team members. This directory is further subdivided into five subdirectories: business, data, application, technology, and security, corresponding to the five dimensions of the enterprise architecture. After a project concludes, the architecture management department, based on asset quality and reusability, marks eligible assets as "reusable" and migrates them to the local or group-level directory via an "asset upgrade" mechanism. Asset upgrades must meet preset audit criteria, such as integrity scores. Consistency score and reuse potential assessment ( ,in The number of times an asset is cited. (Total number of times the asset is used).

[0062] In practical applications, this step is suitable for large group enterprises (such as those in the finance, energy, and manufacturing industries) that need unified management and flexible reuse of architectural assets during their digital transformation. By combining a permission tagging system with a directory hierarchy design, it achieves "hierarchical sharing + precise permission control" of assets, improving asset reuse rate and management efficiency. It solves problems such as rigid standards, loose permissions, and asset loss in existing technologies, demonstrating significant innovation and practicality.

[0063] Furthermore, S3 includes: S31, the group-wide visible label is implemented through the system's preset global access permissions, prohibiting any editing requests from non-group architecture administrators.

[0064] Specifically, in some implementations, setting a group-wide visible label is one of the key technical steps in this application proposal to combine "unified sharing of group standards" with "centralized control of permissions." This step, through a system-preset global access permission mechanism, ensures that core assets in the group's enterprise architecture standard directory are visible and referable throughout the group, while strictly restricting editing operations on the directory content by non-group architecture administrators, thereby achieving unified management of standard assets and preventing accidental modification or unauthorized changes.

[0065] At the technical implementation level, the setting of group-wide visible tags relies on the access control module and tag management system of the enterprise architecture management platform. During system initialization, the platform administrator creates a "group parent directory" in the root directory and configures global access permissions for this directory and all its subdirectories and asset items. Specifically, the system sets the access permission for this directory to "group-wide visible" through a permission tag mechanism. This means that all users at the group level and subsidiaries automatically gain "view, reference, and download" permissions for this directory after logging into the system, without requiring additional application or authorization. This permission configuration is typically implemented through the platform's permission policy engine, and its permission rules can be expressed as follows:

[0066] in, This indicates the user's access permission level to this directory. Indicates user role, This indicates the role of the group's architecture administrator. The system uses this formula to perform real-time judgment and control of user access behavior.

[0067] At the parameter level, key parameters involved in this step include permission label type (e.g., "visible to the entire group"), user role identifier (e.g., "group_admin", "subsidiary_admin", "project_user"), and operation type (e.g., "create", "edit", "delete"). Furthermore, the system must support a permission inheritance mechanism to ensure that subdirectories automatically inherit the access permission settings of their parent directories, avoiding redundant permission configurations.

[0068] At the application level, this step is primarily used in scenarios where the group headquarters releases and maintains unified architecture standards. For example, when business architecture standards are updated, the group architecture administrator can make modifications in the "group parent directory" and ensure, through permission tags, that all subsidiary users can only view and reference the updated standards, but cannot directly edit them, thereby guaranteeing the authority and consistency of the standards.

[0069] From a technical perspective, this step effectively resolves the conflict between "standard uniformity and subsidiary individualization" in existing technologies, ensuring that the group's unified standards are accessible and reusable across the entire group, while preventing standard fragmentation caused by unauthorized modifications. Through this mechanism, enterprises can achieve centralized management and efficient sharing of architectural assets, providing a foundation for the standardized application and accumulation of subsequent project-level assets.

[0070] S32, the access permissions for tags visible at this level are automatically matched based on the user's organizational structure attributes. External entities need to submit a cross-level authorization application and obtain approval from the superior architecture administrator to access the tags.

[0071] Specifically, within the enterprise architecture directory at this level, hierarchical access control is one of the key mechanisms for achieving "coexistence of unified standards and personalized assets." This step, through automatic matching of user organizational structure attributes, intelligently identifies and assigns permissions to "visible at this level," thereby ensuring the accessibility of unified standard assets at the subsidiary level while preventing unauthorized modifications. In some implementations, the system dynamically binds permission tags based on the user's organizational structure level (such as group headquarters, subsidiary, department, etc.). Specifically, it obtains the user's organization ID (org_id) and role ID (role_id) through a user authentication system (such as LDAP, AD, or a self-built IAM system) and matches them with the permission tag (permission_tag) of the directory assets.

[0072] The setting of permission tags follows the standard RBAC (Role-Based Access Control) model, extended to incorporate the hierarchical relationships of the organizational structure. For example, when an asset is marked as "visible only to this level," its access permissions are only open to users within the current organizational level (org_level = current_level). If an external entity (such as other subsidiaries or cross-department users) attempts to access the asset, the system will trigger a cross-level authorization process. The user must submit a cross-level access request, filling in fields such as the purpose of access and scope of use. This request will be routed to the superior architecture administrator (superior_arch_admin) for approval. Once approved, the system will dynamically update the permission tag, allowing access.

[0073] In practical applications, this step is suitable for scenarios involving the sharing of architectural assets between the group and its subsidiaries. For example, when designing local business processes, subsidiaries may need to reference the group's unified business terminology or data standards, but also need to expand their local directories with personalized content. By combining local visibility tags with cross-level authorization mechanisms, the system ensures both the authority of the group's standards and the flexibility of subsidiaries within the framework of compliance.

[0074] Furthermore, this mechanism improves the precision of management and control and the efficiency of sharing of architectural assets, avoiding asset abuse caused by overgeneralized permissions or asset silos caused by closed permissions. Its technical value lies in building a collaborative mechanism of "standard inheritance + permission isolation," providing a workable, auditable, and scalable solution for large group enterprises to achieve hierarchical management of architectural assets.

[0075] S4. Establish an asset upgrade mechanism to mark the architectural assets in the project-level directory that meet the reuse conditions of this level as reusable and upgrade them to this level directory. Architectural assets that meet the reuse conditions of the whole group will be upgraded to the group parent-level directory after being approved by the group architecture management department.

[0076] Specifically, in this application proposal, the step of "establishing an asset upgrade mechanism" is the core link to realize the hierarchical management and reuse of enterprise architecture assets. Its technical implementation is based on the architecture catalog system of "standard inheritance + permission isolation". Combined with asset classification standards and approval processes, it ensures that project-level assets can be upgraded to the local or group-level catalog in an efficient and compliant manner after meeting the reuse conditions, thereby improving the asset reuse rate and reducing the cost of repeated construction.

[0077] In some implementations, the asset upgrade mechanism is implemented through the directory structure and access control module in the enterprise architecture management platform. After project construction is completed, the architecture assets in the project-level directory are subject to asset acceptance and evaluation by the architecture management department at that level. Evaluation criteria include the asset's universality, degree of standardization, and compatibility with group or local architecture standards. For example, business architecture assets must meet the requirements of the group's unified business terminology (such as...). To ensure consistency, data architecture assets must conform to the enterprise's subject area classification standards (such as...). Application architecture assets must comply with application domain classification specifications (such as...). )wait.

[0078] The specific operational process is as follows: First, the project team completes the creation and maintenance of assets in the project-level directory. Before the assets are released, they must be submitted to the architecture management department at this level for review. After the review is approved, the assets enter the "pending upgrade" state. Second, the architecture management department classifies and judges the assets according to their reuse scope: if the assets meet the reuse conditions at this level (e.g., If the asset has a reuse probability of at least 70%, it will be marked as "reusable" and automatically upgraded to the enterprise's organizational structure directory via the platform interface; if the asset has reuse value across the entire group (e.g., ... If so, it needs to be submitted to the group's architecture management department for approval, and after approval, it will be upgraded to the group's parent directory.

[0079] In practical applications, this mechanism is suitable for large group enterprises in finance, energy, and manufacturing, especially during digital transformation, where the architectural assets generated by numerous projects need to be shared and reused between the group and its subsidiaries. For example, in the insurance industry, if the data model generated by a subsidiary when developing a claims system conforms to the group's unified data standards (such as...), it can be reused. This can be upgraded to the group directory for other subsidiaries to use directly, avoiding redundant modeling.

[0080] From a technical perspective, this step, by establishing standardized asset upgrade paths and approval processes, achieves the systematic accumulation and structured reuse of project assets, enhancing the enterprise's lifecycle management capabilities for architectural assets. Simultaneously, through access control mechanisms (such as...) It ensures the security and compliance of the asset upgrade process, effectively solves problems such as asset loss, low reuse rate and chaotic permissions in the existing technology, and enhances the collaborative efficiency and consistency of the group and its subsidiaries in architecture management.

[0081] S5. Establish an asset association verification mechanism to forcibly verify the association between assets and parent or current directories when creating a project-level directory. If the association is missing, the asset publishing operation is prohibited.

[0082] Specifically, in this application proposal, establishing an asset association verification mechanism is a key control step to realize the association between project-level architectural assets and group or subsidiary-level directory standards. Its technical implementation principle is based on directory hierarchy inheritance relationship and asset reference constraint mechanism. By implementing mandatory association verification logic when the project-level directory is created, it ensures that the asset must meet the reference or inheritance relationship with the standard asset in the upper-level directory before it is released, thereby ensuring the standardization and reusability of architectural assets.

[0083] In some implementations, this mechanism embeds a directory association verification engine within the enterprise architecture management platform. When a user attempts to create or publish a project-level asset, the system automatically triggers a verification process. Specifically, when a user uploads or creates a type of architecture asset (such as a business process diagram or data model) in a project-level directory, the system first parses the asset's metadata, extracting its architecture domain (such as business or data) and asset type (such as a flowchart or entity model). Then, it searches the corresponding group-level or local directory for a referenceable standard asset. If found, the system requires the user to fill in the associated asset ID or inheritance relationship description in the asset publishing form and performs format verification to ensure it conforms to preset referencing specifications, such as standard identifier formats like R.styleable.name or R.type.name.

[0084] In terms of parameter metrics, this mechanism involves the following key parameters: Associated Asset ID field: Used to identify the group or local standard assets referenced by the project assets, in the format [0-9A-Z]{18}, which conforms to the unique identifier specification of enterprise structure assets; Inheritance description field: Users are required to fill in a description text of no less than 50 words, describing the logical inheritance or extension relationship between the project asset and the standard asset; Validation trigger timing: Automatically triggered when creating a project-level directory or publishing an asset; response time should be controlled within [timeframe missing]. Seconds, to ensure user experience; Verification failure handling mechanism: If the associated asset ID is not filled in or the description does not meet the specifications, the system will prohibit the asset from being published and return error code 403-ASSET-UNLINKED, prompting the user to supplement the associated information.

[0085] In practical applications, this mechanism is widely used in project asset management within a two-tiered corporate structure of group and subsidiary companies, particularly in large enterprises in industries such as finance, energy, and manufacturing. It ensures that project assets must establish a clear reference relationship with the group's or subsidiary's standard assets before release, preventing asset isolation, standard conflicts, or redundant development. For example, in business process modeling within the insurance industry, project teams must reference the group's unified "Claims Business Component" standard asset when creating new claims process models; otherwise, the system will refuse to release the model.

[0086] The technical benefit of this step is that, through mandatory correlation verification, it ensures that project assets have established logical connections with the group's or subsidiary's standard assets before release, thereby improving the standardization and reusability of assets, avoiding asset silos, and enhancing the uniformity and flexibility of the enterprise architecture. Furthermore, this mechanism provides a data foundation for subsequent automatic asset upgrades and sharing, and is an important prerequisite for achieving closed-loop management of "asset accumulation-review-upgrade".

[0087] The hierarchical setting method for a two-tier corporate structure of group and subsidiary in this invention establishes an asset association verification mechanism. When creating a project-level directory, the association between the asset and the parent or current level directory is forcibly verified. This effectively prevents the isolated existence of structural assets, ensures the logical consistency and integrity of assets in the hierarchical structure, and further improves the reuse efficiency of structural assets and the standardization of group structure management.

[0088] To achieve the above embodiments, the present invention also proposes a hierarchical setting device for a two-tier corporate structure of group and subsidiary. Figure 2 This is a schematic diagram of a hierarchical setup device for a two-tier corporate structure (group and subsidiaries) provided in an embodiment of the present invention. Figure 2 As shown, the device includes: The three-level architecture asset catalog construction module 100 is used to construct a three-level architecture asset catalog system that includes a group parent directory, a local directory, and a project-level directory. The group parent directory stores the core architecture standard that is unified across the entire group, the local directory stores the personalized architecture assets that are exclusive to the group or its subsidiaries, and the project-level directory stores the architecture assets related to each project and associates them with the standards of the parent directory or the local directory. The Differentiated Access Control Module 200 is used to set differentiated access control rules for three-level directories. The parent-level directory of the group can only be created, modified, and deleted by the group architecture administrator, and key operations require a dual process of departmental review and committee approval. The local directory is managed by the local architecture administrator, and a parent standard compliance statement must be submitted when modifying it. The project-level directory is created and modified by project team members, and asset releases require review by the local architecture management department. The permission tag sharing scope definition module 300 is used to define the sharing scope through the permission tag system. The group parent directory is set to be visible to the whole group and unauthorized modification is prohibited. The local directory is set to be visible to the local level and requires authorized access. The project-level directory is set to be visible within the project and supports asset upgrades to the parent directory. The Asset Upgrade Mechanism Establishment Module 400 is used to establish an asset upgrade mechanism. It marks the architectural assets in the project-level directory that meet the reuse conditions of this level as reusable and upgrades them to this level directory. The architectural assets that meet the reuse conditions of the whole group are upgraded to the group parent directory after being approved by the group architecture management department.

[0089] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0090] To implement the above embodiments, the present invention also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0091] To implement the above embodiments, the present invention also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0092] To implement the above embodiments, the present invention also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0093] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0094] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0095] This invention is intended to provide implementation schemes for users to selectively prevent the use or access to personal information data. That is, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information can be de-identified to protect user privacy.

[0096] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0097] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0098] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0099] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0100] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0101] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0102] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0103] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0104] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0105] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for hierarchical setting of a two-tier corporate structure consisting of a group and its subsidiaries, characterized in that, include: S1. Construct a three-level architecture asset directory system including the group parent directory, the local directory, and the project directory. The group parent directory stores the core architecture standard that is unified across the entire group. The local directory stores the personalized architecture assets that are exclusive to the group or its subsidiaries. The project directory stores the architecture assets related to each project and associates them with the standards of the parent directory or the local directory. S2 sets differentiated permission control rules for the three-level directory. The group parent directory can only be created, modified and deleted by the group architecture administrator, and key operations must go through a dual process of departmental review and committee approval. This level of directory is managed by the architecture administrator at this level, and a standard compliance statement from the parent level must be submitted when making changes; project-level directories are created and modified by project team members, and asset releases must be approved by the architecture management department at this level. S3 defines the sharing scope through the permission tag system. The parent directory of the group is set to be visible to the whole group and unauthorized modification is prohibited. The current directory is set to be visible to the current level and requires authorized access. The project-level directory is set to be visible within the project and supports asset upgrades to the parent directory. S4. Establish an asset upgrade mechanism to mark the architectural assets in the project-level directory that meet the reuse conditions of this level as reusable and upgrade them to this level directory. Architectural assets that meet the reuse conditions of the whole group will be upgraded to the group parent-level directory after being approved by the group architecture management department.

2. The method as described in claim 1, characterized in that, The construction of a three-tiered asset catalog system, comprising a parent directory, a current directory, and a project-level directory, also includes: S11, the group parent directory is organized according to a three-level classification structure of "domain-category-asset". The domain includes business architecture, data architecture, application architecture, technical architecture and security architecture. The category is the sub-module under each domain. The asset is the specific reusable architectural element. S12, the project-level directory sets asset association identifiers in the five subdirectories of "business, data, application, technology, and security", and achieves standard inheritance by referencing the asset number of the parent directory or the current directory.

3. The method as described in claim 1, characterized in that, The method for setting differentiated permission control rules for third-level directories also includes: S21, the departmental review process for key operations includes the architecture management department conducting a compliance review of the modified content and generating a compliance report; S22, the committee approval process involves the Group Structure Committee making the final confirmation of the compliance report, and asset modification operations can only be carried out after approval.

4. The method as described in claim 1, characterized in that, Defining the sharing scope through the permission tagging system also includes: S31, the group-wide visible label is implemented through the system's preset global access permissions, prohibiting any editing requests from non-group architecture administrators; S32, the access permissions for tags visible at this level are automatically matched based on the user's organizational structure attributes. External entities need to submit a cross-level authorization application and obtain approval from the superior architecture administrator to access the tags.

5. The method as described in claim 1, characterized in that, Also includes: S5. Establish an asset association verification mechanism to forcibly verify the association between assets and parent or current directories when creating a project-level directory. If the association is missing, the asset publishing operation is prohibited.

6. A hierarchical setup device for a two-tier corporate structure of group and subsidiaries, characterized in that, include: The three-level architecture asset catalog construction module is used to build a three-level architecture asset catalog system, which includes a group parent directory, a local directory, and a project-level directory. The group parent directory stores the core architecture standards that are unified across the entire group, the local directory stores the personalized architecture assets that are exclusive to the group or its subsidiaries, and the project-level directory stores the architecture assets related to each project and associates them with the standards of the parent directory or the local directory. The differentiated permission control module is used to set differentiated permission control rules for third-level directories. The group parent directory only allows the group architecture administrator to perform creation, modification and deletion operations, and key operations must go through a dual process of departmental review and committee approval. This level of directory is managed by the architecture administrator at this level, and a standard compliance statement from the parent level must be submitted when making changes; project-level directories are created and modified by project team members, and asset releases must be approved by the architecture management department at this level. The permission tag sharing scope definition module is used to define the sharing scope through the permission tag system. The parent directory of the group is set to be visible to the whole group and unauthorized modification is prohibited. The current directory is set to be visible to the current level and requires authorized access. The project-level directory is set to be visible within the project and supports asset upgrades to the parent directory. The asset upgrade mechanism module is used to establish an asset upgrade mechanism, which marks the architectural assets in the project-level directory that meet the reuse conditions of this level as reusable and upgrades them to this level directory. Architectural assets that meet the reuse conditions of the whole group are upgraded to the group parent-level directory after being approved by the group architecture management department.

7. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-5.

Images