CGG Petrosystems view on Interoperability (July 1998)

Continuing the interoperability debate, this month Jean-Paul Marbeau of CGG-Petrosystems presents the view of a medium-sized software developer with a particular interest in plug-and-play capability with the major vendors.

Interoperability has been one of Petrosystems’ key priorities since the early 90s. For a mid-size software vendor like us, interoperability has always meant the ability to seamlessly exchange information with the main vendors' systems. This is a major reason-why we originally joined POSC in 1991. Since that time, a lot has happened, both in terms of re-defining the E&P business processes and the emerging I.T. technologies. This led to re-definition of the concept of interoperability and currently, we consider that the E&P technical software industry is entering into a completely new era. Back in 1991, interoperability was mostly viewed as being achieved through data integration. With Integral Plus, we were actually one of the first companies offering such data integration. However, based on a proprietary data model, our interpretation software was locked in its own integration. This is why we actively supported the design process of POSC Epicentre, the vision of a single data model adopted by the entire Industry. The concept of business objects was still considered as a far-reach, and, with Epicentre, the POSC arena settled for a logical data model concept, half way between object technology and physical data models

Seven years later, Epicentre’s benefits turned out to be quite different. It did provide the basis for modern corporate data-management, and our leadership position in that domain with the PetroVision suite of products we developed with PECC is directly linked with Epicentre’s proven industrial strength in that domain. However, Epicentre did not work for interoperability, first because the main E&P systems, i.e. Geoquest and Landmark did not fully implement it in their applications, but also because the paradigm had somewhat changed. The new organization of the E&P Industry through multidisciplinary asset teams has modified the requirements with respect to interoperability. First, seamless-access to the main project databases is a must, and will stay that way in the future. Quick convergence of the respective data models is not expected any more. It is a matter of survival for both the value-added software vendors and the technology groups within the oil companies to adapt to this reality. Second, the concept of Shared Earth Model is now gaining momentum. This model-centric approach to asset workflow basically means that data integration is not enough. Different disciplines and software applications must share common high-level objects. Modifications made by one application must be immediately available – and consistent with – the other ones. At this point, interoperability also means sharing context, graphics, and algorithms such as 3D-geomodelling tools.

Such interoperability, across project databases, vendors and platforms, cannot be reached simply by using vendor A or B Application Programming Interfaces (API) that are meant to work only in the proprietary environment of its owner. This is why we have been advocating a "neutral" SIP, and welcomed the first efforts to build one, PrismTech's Light-SIP. In the mean time, object-oriented technology has become mainstream. Every significant vendor is now stating that its new developments are OO-based and made in C++ or Java development languages. More importantly, the OMG has set the standards for distributed objects technology, which, in theory is the proper framework for the high-level interoperability as described above. This is why Petrosystems developed CORBA-based data servers, enabling commercial applications such as Stratimagic to simultaneously access data from OpenWorks, Integral Plus and now GeoFrame project databases. This experience was for us the proof-of-the pudding, and in 1995 we started the development of GEM-3D, our new object-oriented application integration platform, based on CORBA protocols for accessing the data through business objects, and integrating gOcad as our preferred 3D-geomodelling tool.

Finally, came Open Spirit and the POSC interoperability RFT. This is for us the most recent leg of the interoperability journey. Technically, Open Spirit brings us two key features. First, it is a neutral Application Integration Platform (AIP), to be shared by a number of software vendors and oil companies. Second, it brings the full strength of the distributed business objects, on top of the concept of CORBA-based data servers. This is the main reason that we consider the Open Spirit project as strategic for us, and why we are sponsoring it, and contributing two senior programmers to its development Team. We expect the deliverables to be on time, first in terms of CORBA servers, by Q1 1999, then in terms of graphics and other more sophisticated distributed services. We expect to rapidly implement such servers both in our data management and our geoscience interpretation applications. We also verified that the Open Spirit architecture makes it possible for us to keep as framework extensions several important GEM-3D features, such as its highly sophisticated interaction mechanisms and its integration of gOcad. The merger of the two frameworks will take place next year.