The Public Petroleum Data Model Asociation was founded in Canada in 1988 (two years before POSC!) with the intent of defining a data model suited to the needs of the Canadian E&P sector. This meant that the initial versions of the PPDM data model had a strong focus on well data which is both widely available and very actively traded in Alberta (a propos, Queen Victoria wanted to rename India "Alberta" after the death of her consort, her advisors redirected this accolade to the Canadian province). The PPDM model and membership have grown a lot since the early days. Today there are 86 members, and the current version 3.3 of the PPDM data model contains around 300 tables in the four subject areas of wells, seismic, land/lease and lithology. The PPDM data model is very widely used in the industry, it is at the heart of Geoquest's Finder product - with more than 500 world-wide licences. In fact Finder Graphics Corporation was one of the four founding members of PPDM. Landmark will also implement the PPDM data model as the basis of their Open Works product. While the majority of the members of PPDM come from the vendor community, providing data and other services utilising the model, some oil co. members implement the PPDM model themselves as a corporate data store.
Pragmatic
PPDM's approach has always been a pragmatic one, the objective is to supply an implementable data model using today's technology. Thus the PPDM deliverable comes in the form of a suite of Oracle Data Description Language (DDL) scripts. These can be run on any Oracle installation to initiate the model. Populating it is up to the user. It is clear that this approach is less than politically correct in these days of open systems. It might seem a shame that a "standard" is so closely coupled with a commercial product (although there are rumoured to be some Sybase implementations of PPDM around), but this is a reflection of Oracle's dominance in the E&P sector. In this context, POSC is in practice as coupled to Oracle as PPDM, with their relational implementations delivered too in Oracle DDLs.
Prime
Those of you who would like to have an overview of the PPDM data model together with a reasonably dispassionate presentation of the business case for PPDM would be well advised to sign up for the one day seminar held regularly by Prime Geomatics . This outlines the history of PPDM, runs through the subject areas and perhaps most importantly, distinguishes the areas of the model in active use from those under construction. Such considerations are important for implementers since implementing a part of the model which is already in widespread use will be very different from doing so with a frontier area.
Plug and tweak
PPDMology is an important science if only for the reason that the PPDM data model is more mature than POSC, has been more widely implemented and can therefore tell us a thing or two about the likely future evolution of POSC itself. Firstly, PPDM implementations do not allow for plug and play. Finder "runs on" PPDM as will Open Works. But they both have their own internal implementations which are to all intents and purposes proprietary. That is to say that the frequently presented diagram showing a central data repository, with applications running off it as spokes, is simply not how things actually work. Real world implementations of PPDM are (in the end-user oil co. community) as essentially stand alone data repositories. Data may be pumped out from them to applications, which may themselves have a PPDM data model at their core, but it will be a separate, different implementation of the model. Implementing a PPDM model - again as an end-user - is not for the faint hearted as is shown by the type of company which has adopted this approach. These are generally either majors, large subs or state companies with significant IT resources.
"based-on"
The essence of the problem here is that, contrary to the marketing spiel, PPDM (and incidentally POSC) are not "buy not build" solutions. They nearer to being "build not buy" solutions (given the rather low price for POSC's SIP V2.1 mentioned elsewhere in this edition, you will forgive me this poetic license). You acquire a data model for a very small price, then you build it into a solution whether this be a vendor's data delivery tool or an Oil Co.'s full-blown corporate data repository. During the building process the model is customized for local data flavors, data entry tools are developed, formatters and re-formatters are plugged in to the model for export to a particular combination of applications and to satisfy a particular type of workflow. Queries, indexes, triggers and stored procedures are designed and implemented and after a while and a not inconsiderable investment, you have a working solution. This can then be said to have been "based on" PPDM or POSC, but will also have been based on a particular version of one of these.
antiquated
Which leads on to another complication which is clear from our elementary study of PPDMology. Without wanting to embarrass anyone, all commercial implementations of both PPDM (and POSC) are by their nature, based on more or less antiquated versions of their respective standards. Porting them to the next version is a costly and painful exercise which is infrequently performed. So commercial implementations of PPDM today are variously based on versions 1.0, 2.3, 3.2 and 3.3. In the POSC camp, the first version of Epicentre was published in September 1993, version 2.0 followed in October 1995, and 2.1 has just been issued. So real-world implementations of Epicentre will, in all probability, come in different flavors, with the same issues of compatibility and cost of change.
Ad-infinitum
Another field where PPDMology is instructive is in model scope. Get a group of data modellers together and what do they do? Model! It is tempting for all IT professionals to go on developing ad-infinitum rather than deploying. This situation is actually encouraged by the structure of POSC and PPDM. Rather than making sure that a sector of the model is well specified, debugged and in service, it is much more interesting to move on to greener pastures. This is a difficult issue, but broadening the scope of a data model is a double edged sword. It may make the understanding of the business easier for the E&P data modeller, but when you are beginning to invade ground that is already well-trodden by accountants with big iron products like SAP, then you had better watch out!
Buy or build?
In conclusion I would like to open up the debate with a statement and a
question. The statement: neither POSC nor PPDM are either "buy not build"
solutions nor do they promote interoperability - in the sense of "plug and
play". The question: what are they really for? What honest statements about their
real usefulness can be made. This is a leading question, but I can think of a few answers
that are not entirely negative. What do you all think?? Answers please to PDM, we will
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_199611_7 as the subject.
© Oil IT Journal - all rights reserved.