Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Domain Data Management Service (DDMS) â is a platform component that extends OSDUÂŪ core data platform with domain specific model and optimizations. DDMS is a mechanism of a platform extension that:
- delivers optimized handling of data for each (non-overlapping) "domain."
- pertains to a single vertical discipline or business area, for example, Petrophysics, Geophysics, Seismic
- serves a functional aspect of one or more vertical disciplines or business areas, for example, Earth Model
- delivers high performance capabilities not supported by OSDUÂŪ generic normal APIs.
- helps achieve the extension of OSDUÂŪ scope to new business areas.
- may be developed in a distributed manner with separate resources/sponsors.
OSDUÂŪ Technical Standard defines the following types of OSDUÂŪ application types:
| Application Type | Description |
|---|---|
| OSDUÂŪâĒ Embedded Applications | An application developed and managed within the OSDUÂŪ Open-Source community that is built on and deployed as part of the OSDUÂŪ Data Platform distribution. |
| ISV Extension Applications | An application, developed and managed in the marketplace that is NOT part of THE OSDUÂŪ Data Platform distributions, and when selected is deployed within the OSDUÂŪ Data Platform as add-ons |
| ISV third Party Applications | An application, developed and managed in the marketplace that integrates with the OSDUÂŪ Data Platform, and runs outside the OSDUÂŪ Data Platform |
| Characteristics | Embedded | Extension | Third Party |
|---|---|---|---|
| Developed, managed, and deployed by | The OSDUÂŪ Data Platform | ISV | ISV |
| Software License | Apache 2 | ISV | ISV |
| Mandatory as part of an OSDUÂŪ distribution | Yes | No | No |
| Replaceable | Yes, with preservation of behavior | Yes | Yes |
| Architecture Compliance | The OSDUÂŪ Standard | The OSDUÂŪ Standard | ISV |
| Examples | OS CRS Wellbore DDMS |
ESRI CRS Petrel DS |
Petrel |
Who did we build this for?
IT Developers build systems to connect data to domain applications (internal and external â for example, Petrel) which enables data managers to deliver projects to geoscientists. The DDMS suite on Azure Data Manager for Energy helps automate these workflows and eliminates time spent managing updates.
Geoscientists use domain applications for key Exploration and Production workflows such as Seismic interpretation and Well tie analysis. While these users won't directly interact with the DDMS, their expectations for data performance and accessibility will drive requirements for the DDMS in the Foundation Tier. Azure will enable geoscientists to stream cross domain data instantly in OSDUÂŪ compatible applications (for example, Petrel) connected to Azure Data Manager for Energy.
Data managers spend a significant number of time fulfilling requests for data retrieval and delivery. The Seismic, Wellbore, and Petrel Data Services enable them to discover and manage data in one place while tracking version changes as derivatives are created.
Platform landscape
Azure Data Manager for Energy is an OSDUÂŪ compatible product, meaning that its landscape and release model are dependent on OSDUÂŪ.
Currently, OSDUÂŪ certification and release process are not fully defined yet and this topic should be defined as a part of the Azure Data Manager for Energy Foundation Architecture.
OSDUÂŪ R3 M8 is the base for the scope of the Azure Data Manager for Energy Foundation Private â as a latest stable, tested version of the platform.
Learn more: OSDUÂŪ DDMS community principles
OSDUÂŪ community DDMS Overview provides an extensive overview of DDMS motivation and community requirements from a user, technical, and business perspective. These principles are extended to Azure Data Manager for Energy.
DDMS requirements
A DDMS meets the following requirements, further classified into capability, architectural, operational and openness/extensibility requirements:
| # | Description | Business rationale | Principle |
|---|---|---|---|
| 1 | Data can be ingested with low friction | Need to seamlessly integrate with systems of record, to start with the industry standards | Capability |
| 2 | New data is available in workflows with minimal latency | Deliver new data in context of the end-user workflow â seamlessly and fast. | Capability |
| 3 | Domain data and services are highly usable | The business anticipates a large set of use-cases where domain data is used in various workflows. Need to make the consumption simple and efficient | Capability |
| 4 | Scalable performance for E&P workflows | E&P data has specific access requirements, way beyond standard cloud storage. Scalable E&P data requires E&P workflow experience and insights | Capability |
| 5 | Data is available for visual analytics and discovery (Viz/BI) | Deliver minimum set of visualization capabilities on the data | Capability |
| 6 | One source of truth for data | Drive towards reduction of duplication | Capability |
| 7 | Data is secured, and access governed | Securely stored and managed | Architectural |
| 8 | All data is preserved and immutable | Ability to associate data to milestones and have data/workflow traceable across the ecosystem | Architectural |
| 9 | Data is globally identifiable | No risk of overwriting or creating non-unique relationships between data and activities | Architectural |
| 10 | Data lineage is tracked | Required for auditability, re-creation of the workflow, and learning from work previously done | Architectural |
| 11 | Data is discoverable | Possible to find and consume back ingested data | Architectural |
| 12 | Provisioning | Efficient provisioning of the DDMS and auto integration with the Data Ecosystem | Operational |
| 13 | Business Continuity | Deliver on industry expectation for business continuity (RPO, RTO, SLA) | Operational |
| 14 | Cost | Cost efficient delivery of data | Operational |
| 15 | Auditability | Deliver required forensics to support cyber security incident investigations | Operational |
| 16 | Accessibility | Deliver technology | Operational |
| 17 | Domain-Centric Data APIs | Openness and Extensibility | |
| 18 | Workflow composability and customizations | Openness and Extensibility | |
| 19 | Data-Centric Extensibility | Openness and Extensibility |
OSDUÂŪ is a trademark of The Open Group.
Next steps
Advance to the seismic DDMS sdutil tutorial to learn how to use sdutil to load seismic data into seismic store.
