Chapter 6: The Process for Planning ODS Implementation
This chapter organizes the standard process for users adopting Open Dataspaces. The process proceeds in four steps:
(1) Organizing the project structure and architecture design
(2) Selecting an implementation approach
(3) Data handling agreements
(4) Ensuring data trustworthiness
6.1 Organizing the Project Prolosals and Teams
When launching an Open Dataspaces implementation project, begin by clarifying the following.
Clarify the purpose and objectives of adoption (starting from the challenge identification in Section 5.1)
Identify internal stakeholders (data management, IT, business units, legal) and build consensus
Identify external stakeholders (partners, managed service providers, integration vendors)
Determine the entry pattern (distributed, federated, or hybrid) (refer to Section 5.2)
Key deliverables:
Project Proposals: Background of the challenge, business positioning, system configuration policy, legal/compliance considerations, and business process definitions
Roles and Responsibilities Matrix: Delineation of areas handled by the organization itself versus those handled by managed service providers and integration vendors
6.2 Selecting an Implementation Approach
Implementation approaches can be broadly divided into two patterns in ODS-RAM: in-house development (Pattern A) and use of managed services (Pattern B). Each is described below to provide a basis for deciding which to adopt.
Pattern A) In-House Development Using ODS SDKs and OSS
An approach for organizations that have technical resources and wish to implement and operate ODS Protocols internally.
Proceed with development while verifying that the implementation of ODS Protocols
Leverage SDKs and reference implementation software (ODS Middleware), while developing business-specific logic in-house
Deliverables include connectivity and API specifications implementing ODS Protocols, and operational procedures
For technical implementation guidance, refer to the Open Data Spaces Introductory Guidebook for Developers
Pattern B) Selection and Use of Managed Services
When technical resources for implementing and operating ODS Protocols in-house are limited, or when minimizing entry costs at the PoC stage is a priority, the federated model — using services provided by managed service providers — becomes a realistic option.
When selecting a managed service, confirm the following five perspectives:
Interoperability: Is ODP implemented and supported, and does the service offer interoperability with other products?
SLA and Support Structure: Do incident response, protocol update tracking, and operational support meet the organization's requirements?
Data Usage Control: Even in the federated model, can the organization retain control over the management and usage of its own data and ontology? (Is the service designed to avoid consolidating data with the service provider?)
Phased Migration Feasibility: What is the portability and degree of vendor lock-in when migrating from federated to distributed in the future?
Pricing Model: Does the pricing structure based on number of users, data volume, and features align with the organization's business plan?
6.3 Data Handling Agreements
Distributed data management through ODS requires both a reliable technical foundation and the legal compliance that underpins it. It is important to organize data handling agreements while taking the following considerations into account:
Data Sharing Agreements: Clarify the roles, rights, and obligations among the three parties: "managed service provider," "data provider," and "data consumer." Customizing these to fit the organization's specific use case is an effective approach.
Explicit Terms of Use and Prohibitions: Data providers shall establish terms of use covering the purpose of use, duration of use, and whether secondary use or third-party provision is permitted. Ownership of intellectual property rights and terms of use should also be clearly defined in contracts in advance.
Traceability of Contract Execution and Performance: Ensure traceability of contract execution and performance through the use of digital contracts, smart contracts, etc..
Warranties and Liability: It is standard practice for data providers to warrant that the data they provide does not infringe upon third-party rights and has been obtained lawfully, while not warranting the "accuracy" or "completeness" of the data (provided on an as-is basis).
6.4 Ensuring Data Trustworthiness
To ensure the trustworthiness of entities and data, it is necessary to organize authentication schemes (Table 9) and provenance management.
Table 9 Authentication Schemes
Self-Declaration
Participants
The organization declares its own commitment to comply with usage rules. Readily applicable in the initial entry stage and at the PoC phase.
Mutual Authentication
Between participants
Evaluate and confirm the trust level of counterparties. Established based on agreement with the partner.
Third-Party Certification
Optional
Certification by an external certification body. Consider when industry standards or regulatory compliance is required, or when higher trust requirements apply.
When designing a provenance management, it is effective to organize it in the following phased process:
Visualize the data processing flow: Map the flow of data the organization provides and receives, the parties involved, and the points at which data is transformed or processed.
Identify risks: Identify the primary risks at each data handoff point (information leakage, misuse, violations of terms of use, etc.).
Select an authentication scheme: Determine which combination of self-declaration, mutual authentication, and third-party certification is appropriate, based on cost and the importance of the use case.
Determine the provenance management implementation policy: Design what granularity of access, operation, contract, and evaluation history will be recorded and made verifiable after the fact.
Last updated