In Prague's old town square there is a remarkable fifteenth century clock which displays apparent planetary motion (tough using a geocentric paradigm!), three different time systems (Old Czech time with 24 hours starting at dawn, Babylonian time with seasonally varying length hours and "modern" time) and a complex calendar. The 300 plus delegates at GeoQuest's Forum 97 event had the opportunity, between lectures, user group meetings and drinking sessions to observe this wonder and reflect on this early example of a GUI whose patrons, instead of messing with a non disclosure agreement, blinded Master Hanus the maker, rather than let him reproduce his marvel elsewhere.
Plug and play??
Such reflections may have led some to see the merit of a "standard" world where one time system has replaced the three used in Prague in the middle ages, and standards were indeed the leitmotiv of the GeoForum97 conference. Schlumberger has revamped its data modeling offering and it pulling out all the stops to impress on its users that its new product line is entirely POSC compliant and will allow for plug and play "real soon now". Well it is quite a while since we heard of plug and play in the E&P software field. Personally I have not heard those words since 1995, when following their widespread use, and total absence of any demonstration of the concept, there ensued considerable backtracking.
Shared Earth Model
So what do we have today, and how near are we to plug and play? First lets examine what we mean by plug and play, and what applications we might expect to benefit from this technology. We are fortunate here, because many speakers have vaunted the merits of a shared earth model, allowing applications to share the same dataset, more recently, we have heard of Business Objects which would allow seamless inter-application communication of data. Similarly, the virtues of being able to use "best of breed" software have been much promoted. What then do we expect to plug and play with what? Well plug and play can be implemented on various levels and with greater or lesser scope. One plug and play type scenario could mirror the PC world where for instance, Microsoft owns the OS (Windows), all the main applications (Office), but still facilitates plug and play with other vendor applications through dynamic data sharing technologies such as OLE. In E&P the absolutely obvious first candidates for plugging and playing with each other are applications from GeoQuest and its main competitor, Landmark Graphics Corporation. So having established the theoretical objectives of the plug and play shared earth model, lets take a close look at how GeoQuest's latest offerings.
Checkered history
Finder has had a long and checkered history. Finder Graphics Systems (FGS) originated as a US focussed lease and well mapping tool, but demonstrated from its earliest days what could be achieved by linking a map to a relational database. FGS was one of the founding members of the Public Petroleum Data Model, and it was the PPDM Version 1 which formed the core of the Finder product. The company was bought by CGG-Petrosystems in the mid 80's, but did not find a home there and CGG sold Finder on to Schlumberger GeoQuest in the late 80s. Geoquest then set about developing Finder into a data management system. Its role in the Schlumberger product line changed around quite a bit until 1996 when it began to be presented as the hub of the GeoQuest product line, becoming a data delivery tool accessing data in the database product line (LogDB, SeisDB etc.) and building project databases for the applications. At this time, Finder was still running on the PPDM data model with proprietary extensions termed N-Lists for rapid retrieval of bulk data (well logs and cultural features). Some of GeoQuest's larger clients (and more importantly potential clients) had invested heavily in the POSC, and there was considerable pressure at this time on vendors to provide POSC compliant solutions. Geoquest set to work on this at two levels. Internally all new developed software (and notably GeoFrame) was to be designed as "POSC compliant", and they joined the collaborative effort, the Discovery project, whose goal was to develop a subset of Epicentre to model seismic data in what was supposed to be a merger of the POSC and PPDM data models. Well Discovery has been grinding on now for around about a year without exactly setting the world on fire. Meanwhile, GeoQuest has to keep on rolling out that "POSC compliant" software and has, in effect, gone it alone with what amounts to a take-over of POSC!
API oblige
Now we have already been here before, in the October PDM we revealed that interoperability within the GeoFrame environment would be limited to those who bought into GeoQuest's proprietary API, and that Landmark was not exactly first in line to acquire their main competitor's technology. Although GeoQuest offer their API as a means of developing POSC compliant software, this is something of an exaggeration, and a far cry from the open world which POSC was aiming for initially. After all POSC compliance should mean that other software should be able to talk directly to the data model, not go through an API.
But lets get back to Finder and look some more at GeoQuest's developing data management solution. Some radical re-packaging has been going on here, and the result is somewhat confusing. The hub between the database product line and GeoFrame is now termed "Enterprise", which is described as a federating database of metadata. Now you may find this terminology familiar, it should be, it is exactly how Finder was being marketed a year or so ago. In fact Enterprise was described by some as "what we thought we were buying when we bought Finder". In the same vein, GeoQuest a "new" LogDB to Finder functionality. It may be new software, but this is pretty long in the tooth vapourware by now!
Finder 8
Finder 8, the latest version of the products has now been divided up into a legacy component (still PPDM-ish) called Finder Kernel, and "extensions" – Production and Well Construction (tubulars, cement and the like) which are proudly trumpeted as being "fully POSC compliant". Although in the same breath GeoQuest announce here that, since the POSC production model was considered lacking, they had to extend it themselves. They are literally writing the book here, like I said it is a take-over!
Finder 8 innovations include Graphical Entity Mapping System (GEMS) which makes Finder behave more like a true GIS. GEMS allows user defined attributes to be attached to graphical features so that more powerful and customisable search and display functionality is now possible. Instead of geo-attributes being "hard-wired" into Finder – such as licence information, they can now be customised so that a given user may attach information on pipeline ownership or capacity and suchlike.
Gotcha!
Enterprise has another little built-in "gotcha". Unlike other database federating technologies such as ODBC (which incidentally GeoQuest uses extensively in its PC product line) Enterprise relies on proprietary "hooks" which must be inserted into the databases to which it is going to talk. This was spotted as a less than perfect solution to interoperability, in that, just as our application programmers have to customise their software to the GeoQuest API, third party database vendors will have to incorporate the GeoQuest hooks into their products to be Enterprise enabled. Thus while a vendor of a specialised database system dealing with say geochemistry may be prepared to jump through this particular hoop, IBM may be less than delighted to have their clients asking them to incorporate their major competitor's technology into PetroBank. This is likely to develop into a major issue for Finder/Enterprise clients who really do want to see all their data at one go, not an unreasonable requirement after all.
A common pattern is emerging here, and it does not say "Open System"! What is more likely happening in the real world is that there are "poles" of software families developing respectively, grouped around IBM, LGC and GQ. They will likely have to be able to talk to each other using one kind of link or another, but commercial pressures will mean that these links will not be at the cutting edge of technology. Products such as GeoShare, and techniques such as ASCII file transfer, reformatters and scripts have a long life ahead of them after all, and behind the razzmatazz, it is pretty much the status quo for the harassed data manager.
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_199705_3 as the subject.
© Oil IT Journal - all rights reserved.