Interoperability can mean different things to different people. To try to establish some common ground in this complex field, POSC took an in-depth look into industry perceptions of interoperability (see side box). I think that the prevailing view, when people talk about interoperability, is a meaning somewhere at or around Level 4 or 5. To achieve this degree of interoperability across the board will clearly take some time. At the same time a distinction must be made between interoperability across different vendor's platforms and intra-operability within the products of a single vendor. We have already seen evidence of some degree of intra-operability between products within the main vendor's frameworks.
OpenSpirit
To address the question as to how interoperability might be achieved in a reasonable (three year) time frame, I believe that we will begin to see the capability for Level 2 and 3 interoperability relatively soon; perhaps by early 1999 in the case of the Open Spirit work and the first POSC specifications for Interoperability and Business Objects. The capability for Levels 4 and 5 will evolve over the next 2-4 years as the industry builds new generations of integrated products. I like to say that we're moving to a new generation of where we are "building integrated systems in addition to integrating built systems". We'll only see Level 4-5 interoperability if the key E&P application suppliers build on open standards that broadly support these levels of sharing. Such functionality will have to be offered independently of whether they have such capabilities within their own product lines. POSC is very much a supporter of the notion of business objects. Our Interoperability and Business Object Initiative has as its focus sets of E&P Business Objects, along with enabling architectures. We believe that the success of this initiative will accelerate the industry's ability to build, deploy and use interoperable applications.
Epicentre
The next question concerns the deployment of Epicentre as a route to interoperability. As we have long known, common terminology is important for information sharing. A comprehensive life-cycle data model such as Epicentre is a fundamental enabler of this sharing. But it is not sufficient to permit the level of integration (3-5) that the industry requires. Mapping data objects to Epicentre gives us a basis for sharing common concepts between data objects, applications, systems and users. Therefore, Epicentre deployment might be looked at as a necessary, but not sufficient requirement. Finally you ask if there are other routes to interoperability than vendor APIs. By "Vendors" I assume you mean E&P technical application vendors as opposed to middleware vendors. Certainly the use of vendor APIs improves our ability to share environments and data and for application interaction. If these APIs were built on a common basis (with a common data model, a common object architecture including common concepts and interfaces) then the ability to put together interoperable systems (approaching level 4) across product lines would be at hand.
Open?
Notwithstanding this, vendors most likely will continue to develop APIs at various levels to support application development. The key issue is how "Open" they are and how much these APIs share common building blocks, so that applications built on one vendor's API can interact appropriately with applications built on another. Basing a vendor's API on open standards (such as Epicentre, POSC Business Objects, etc.) will be a major step forward. We believe that this is where the main focus should be over the next few years. There is an alternate (but not mutually exclusive) idea that middleware vendors will provide computing environments (including APIs) that G&G application vendors can adopt as the foundation of their computing platforms. This is a sound idea if the application vendors see -- as they have already seen in hardware, operating systems, database technology, GUI tools and other areas -- that developing all aspects of the underlying computing infrastructure is not their core competency. Rather they would layer their internal APIs and applications on third party platforms built on industry standard architecture and object definitions.
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_199805_11 as the subject.
© Oil IT Journal - all rights reserved.