You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Groups with numerous companies and subsidiaries face challenges in managing data and EDCs due to their complex structures. Instead of providing an independent EDC for each entity, a consolidated EDC is used, which complicates data requests and forwarding among companies.
Explain the topic in 2 sentences
Due to the high complexity of group structures, a single dedicated EDC is used to consolidate data for multiple companies, rather than providing an independent EDC for each entity. This results in challenges where a company must request data from another company through an intermediary EDC, which must correctly interpret and forward the data from the originating company.
What's the benefit?
Reduce complexity, and manual effort. Make intermediate EDCs and use cases like PURIS possible.
What are the Risks/Dependencies ?
Potential breaking chance
Detailed explanation
Groups have a large number of companies and subsidaries. Due to the high complexity of the group structure, an independent EDC is not provided for each company or investment, but consolidated via, for example, a dedicated EDC that is only attached to one company and forwards the data to all other participating companies. It is currently not possible to map this complexity in the Discovery Services and EDCs. This has the following consequences: For example, company x would like to receive data from company y. This is then also specified accordingly in the policies. However, when the request is made, it is noticed that there is no EDC for company y, but that the EDC of company y is attached to company z. Company x must now make the request to company z and the EDC must be able to interpret that the EDC is provided by company z, but the data originates from company y.
Current implementation
Proposed improvements
Feature Team
Contributor
Contributor 1
Contributor 2
Committer
Committer 1
Committer 2
User Stories
Issue 1, linked to specific repository
Issue 2, linked to another specific repository
Acceptance Criteria
Criteria 1
Criteria 2
Criteria 3
Test Cases
Test Case 1
Steps
Do something
Click something
Add something
Expected Result
Expectation
Expectation
Expectation
Architectural Relevance
The following items are ensured (answer: yes) after this issue is implemented.
In the context of the standards 126 and 127, typically only one is applicable, depending on the specific use case. Please cross out one of the two standards that does not apply.
This feature aligns with our current architectural guidelines
The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
Potential risks or conflicts with existing architecture has been assessed
Justification:(Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)
Additional information
I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)
The text was updated successfully, but these errors were encountered:
Overview
Groups with numerous companies and subsidiaries face challenges in managing data and EDCs due to their complex structures. Instead of providing an independent EDC for each entity, a consolidated EDC is used, which complicates data requests and forwarding among companies.
Explain the topic in 2 sentences
Due to the high complexity of group structures, a single dedicated EDC is used to consolidate data for multiple companies, rather than providing an independent EDC for each entity. This results in challenges where a company must request data from another company through an intermediary EDC, which must correctly interpret and forward the data from the originating company.
What's the benefit?
Reduce complexity, and manual effort. Make intermediate EDCs and use cases like PURIS possible.
What are the Risks/Dependencies ?
Potential breaking chance
Detailed explanation
Groups have a large number of companies and subsidaries. Due to the high complexity of the group structure, an independent EDC is not provided for each company or investment, but consolidated via, for example, a dedicated EDC that is only attached to one company and forwards the data to all other participating companies. It is currently not possible to map this complexity in the Discovery Services and EDCs. This has the following consequences: For example, company x would like to receive data from company y. This is then also specified accordingly in the policies. However, when the request is made, it is noticed that there is no EDC for company y, but that the EDC of company y is attached to company z. Company x must now make the request to company z and the EDC must be able to interpret that the EDC is provided by company z, but the data originates from company y.
Current implementation
Proposed improvements
Feature Team
Contributor
Committer
User Stories
Acceptance Criteria
Test Cases
Test Case 1
Steps
Expected Result
Architectural Relevance
The following items are ensured (answer: yes) after this issue is implemented.
In the context of the standards 126 and 127, typically only one is applicable, depending on the specific use case. Please cross out one of the two standards that does not apply.
Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)
Additional information
The text was updated successfully, but these errors were encountered: