At last month's POSC meetings in Dallas, Schlumberger- GeoQuest's product line was in the spotlight at the first of a new "Supplier Workshop Series". The idea behind the workshop's is for a supplier member of POSC to lead a half-day workshop following each POSC Member General Meeting. Larry Denver (GeoQuest) traced the development of GeoFrame from V 1.0 in '93 to V 4.0 due to be released in 1999. By that date GeoFrame should incorporate inter-well imaging, production analysis, simulation and drilling, in other words integrating much of the domains currently covered by Oilfield Manager (OFM). Interest was expressed as to the availability of a GeoFrame developers toolkit which is currently being shipped to "key" clients. Thirty companies have already purchased the development toolkit. As for the holy grail of plug and play, as we have previously discussed here in PDM, this will only be a reality for applications developed in the GeoFrame environment. In the POSC environment, the migration to "full" Epicentre is obviously of interest. GeoQuest stated that this would occur over the next "two to four years".
history
Najib Abusalbi (GeoQuest) provided some information on the implementation of Epicentre in GeoFrame. Some 20% of the 600 plus entities in GeoFrame are extensions including many derived attributes (with stored procedures). This is partly due to "historical usage" but there are areas where the corresponding Epicentre attribute has not been used. GeoQuest has already implemented its own Business Objects (see this month's PDM lead) which provide application access to the physical data model - avoiding direct SQL table queries. Some of this work is fed back to POSC.
confusion
Current GeoFrame architecture does not use the POSC Data Access and Exchange layer and GeoQuest has essentially gone for a proprietary DAE although the PRISM LightSIP DAEF (see October PDM lead) is under evaluation. Bulk data in GeoFrame does not use the POSC defined Frames concept, but rather through the POSC DAE Bulk Data Access Library (BDAL) specifications. GeoQuest uses the notion of POSC compliance very widely in its marketing effort and came under fire for the potential "confusion" that this might cause. POSC is therefore very interested in a compliance verification process, while GeoQuest appeared reluctant to submit themselves to such a test.
PDM comment : GeoQuest like to talk about POSC compliance because they perceive a marketing advantage - and will very likely customize or open up POSC type entry points to their POSC-committed oil company clients. What is less likely is that such plug and play facilities will be offered to GeoQuest's competitors. This is understandable in the commercial world, and reflects the fact that, while the technicalities of interoperability have been investigated in great depth, the existence of a business model that might support interoperability is a rather naive assumption. In other not so far removed fields such as UNIX, or the current Netscape vs. Microsoft courtroom battle, interoperability has either proved a myth, or is centerpiece in out and out commercial warfare. Rather than coming up with some minimalist POSC compliance testing schema, it might be worthwhile to develop even a theoretical business model for how interoperability could be made to work commercially. After all, we are all in it for the money!
Click here to comment on this article
If your browser does not work with the MailTo button, send mail to pdm@the-data-room.com with PDM_V_2.0_199712_9 as the subject.
© Oil IT Journal - all rights reserved.