Groundwork: Layering OO & GIS on the PPDM
System Review
Most companies have put in a system architecture that is similar to the following
diagram:
Unfortunately, this architecture is often repeated within each department/discipline in a
company, meaning that a company has the extra expenditure of maintaining these
separate data streams. Consolidation has been done by migrating to common hardware
(Unix / NT) platforms and software (Oracle / Microsoft) applications. Currently most
companies have relational-based systems supporting the business and most of these
are based on Unix / NT hardware. There are functioning applications that work on top of
these systems and access can be made from anywhere (inside / outside the office).
What does become clear from this “typical architectural picture” is that any additional
integration will be an advantage.
Integration Review
Basic integration in most Oil and Gas companies has not been done. There are two
stumbling blocks that are in everyone’s road: departmental dysfunction and natural key
selection. We all know about departmental dysfunction (the ability of a department to
put its agenda first) and most of us manage around it. It has become easier to break
down these departmental barriers, in part due to the downward cost pressure that new
technologies (internet-related) bring. The other roadblock, natural key selection, is
tougher to deal with. All systems, relational or otherwise have a natural key identifier.
This key is not a primary key, but rather a representation of a unique time-based (more
likely than not) element that is naturally understood within the business discipline. We
humans think in complex patterns and have the ability to associate and disassociate relationships ‘on-the-fly’. The best industry illustration of this is a well location in
Canada. The well was originally licensed and drilled as 11-31-66-11w6 (the actual
name/location has been changed to protect the stupid) but was actually found to be
located at 1-1-67-12w6. This well was incorrectly surveyed and thus recorded with the
government authority as the incorrect location. Geoscientists working the area know it
by both locations. More importantly, the incorrect well location will just not go away.
Production volumes are associated with 11-31, routinely and the working interest for 1-1
is almost always incorrectly adjusted for, because of missing production. This is a
simple integration problem between business disciplines (and their systems). Humans
quickly learned and remembered that these wells are in-fact the same well and can deal
with it, but our systems cannot. There is nothing that relates 11-31 to 1-1. This
illustrates complex reasoning and the related business rules contributing to why system
integration is so difficult. If we can move toward defining objects that are able to better
reflect these and other business rules, we will be able to create systems that accurately
reflect the manner in which our company does business.
Technical Review
There is a common data model in the oil and gas sector called the PPDM. The PPDM is
a relational based model; that is very mature in the following subject areas: Wells,
Stratigraphy, Land, Business Associates, Contracts and Seismic. The PPDM has
created a model that has followed a strict naming convention standard. This has created
a model that is consistent in the entity and attribute naming as well as the attribute
typing. Later we will see how we can take advantage of this in the implementation of
objects based on this oil and gas data model. The PPDM is starting to add spatial
components to the model with a complete spatial hierarchy in each subject area. This
additional layer of complexity could delay implementation at companies for two reasons:
1) the implementing company will have to load, store and maintain this information;
adding to the existing infrastructure costs. 2) The implementing company will have to get
software vendors (or their own internal I.S. departments) to adopt their software to read
in this new spatial structure. Most software vendors have already formed alliances with
ESRI or MapInfo to display data in a spatial format or have their own proprietary
methods of displaying maps. Why would they want to add in another display mechanism
and have to support it? Both above considerations will contribute to an expensive and
time-consuming task. In today’s Internet economy, is this a reality?
Objective
Let review the objective at the Oil and Gas Company that we work at. It is probably to
enable our geoscientific user community with the ability to view data in a map view and
to be confident that all information is available within a specified geographical area. This
means that our systems must: 1) have a systems with architectures that are compatible
with each other. 2) have disciplines must be aware of what other data is available and
be linked together. 3) allow separate subject areas to be displayed on the same map.
This will require a significant change in systems across the entire enterprise or will it?
Using a standard model and methodology will be fundamental to enabling seamless
communication between; departments within a company, applications from different
vendors, company offices and even between oil companies. What could this standard
be? How much will it cost to pull all of this information together and display it in a
coherent manner?
