... | ... | @@ -78,10 +78,7 @@ available in workflows should be minimal. Consequently, a DDMS should support |
|
|
multiple access patterns e.g. small amount of data wherein it becomes available
|
|
|
for consumption instantly, large amounts of data where data becomes available
|
|
|
for consumption incrementally or if domain logic demands that it be all
|
|
|
available at once, then after a reasonable time interval. DELFI is expected to
|
|
|
solve the challenge wherein a corporate store like ProSource is updated with new
|
|
|
data, but a Petrophysicist or Geologist in a Techlog continues working with a
|
|
|
previous version, blissfully ignorant of the data changes.
|
|
|
available at once, then after a reasonable time interval.
|
|
|
|
|
|
Domain data and services are highly usable
|
|
|
------------------------------------------
|
... | ... | @@ -121,9 +118,6 @@ results are available for these workflows. This requires the ability to pick |
|
|
attributes and relationships across domains - real value of BI is cross domain
|
|
|
not single domain.
|
|
|
|
|
|
Example – In ProdOps one may want to compare forecast from PO with a R model
|
|
|
forecast built on the ecosystem data
|
|
|
|
|
|
One source of truth for data
|
|
|
----------------------------
|
|
|
|
... | ... | @@ -240,11 +234,7 @@ vs interpreter work-in-progress vs qualified best results etc.) – This implies |
|
|
we need an index that spans both work-in-progress and final data – quality
|
|
|
should convey if a data is trust-worthy and suitable for a down-stream workflow.
|
|
|
|
|
|
Inability to know what has been picked out by an interpreter into Petrel and
|
|
|
Techlog projects and the lack of awareness of the team’s work artifacts has been
|
|
|
a key problem before that we should avoid in DELFI. Think Studio
|
|
|
(publish/subscribe) vs OpenWorks (data tagged, single shared collaborative
|
|
|
repository). The latter is the pattern we must establish in Data Ecosystem.
|
|
|
...
|
|
|
|
|
|
Discoverability of data requires a perspective of the data kind that is
|
|
|
conducive for search. Typically the perspective is defined by the domain that
|
... | ... | @@ -380,22 +370,6 @@ possible. |
|
|
Also, if the user needs to update a KB it should be done once not in multiple
|
|
|
places and all workflows should reflect the correction immediately.
|
|
|
|
|
|
Data-Centric Extensibility
|
|
|
--------------------------
|
|
|
|
|
|
Customers are used to Ocean and its extensibility capabilities – capitalizing on
|
|
|
that is to DELFI’s advantage. Petrel/Techlog used a data centric integration
|
|
|
approach where a customer can create an alternative way to generate tops or
|
|
|
realize a surface and continue the rest of their steps with standard Petrel
|
|
|
and/or Techlog functionality.
|
|
|
|
|
|
- A similar data-centric integration approach taps into the expertise already
|
|
|
in market place
|
|
|
|
|
|
- A composable workflow approach is an alternative, but this requires us to
|
|
|
build an orchestration layer and expose APIs for data that may be workflow
|
|
|
specific
|
|
|
|
|
|
|
|
|
Tutorial
|
|
|
========
|
... | ... | |