Impressive debut for Open Spirit Alliance (September 1998)

The Open Spirit Alliance, the Shell-inspired,POSC-supported framework promising the holy grail of software interoperability, made ashowy debut at the SEG.

Open Spirit has already been presented in various PDMs – (Vol. 2 N° 12 and recent interoperability series). The New Orleans SEG was an important milestone for the initiative, and Open Spirit certainly made the grade in terms of marketing presence. A substantial stand, a multiplicity of announcements, a big party and some impressive demos combined to make for a successful launch of the interoperability framework. What’s new is the availability of vendor development kits, allowing application developers to plug and play with E&P datastores such as Schlumberger’s GeoFrame/IESX and landmark’s OpenWorks/SeisWorks. Industry support and interest is demonstrated by the addition of several new members of the Open Spirit Special Interest Group (OSIG), currently clocking up new members at a rate of one per week. Interoperability demonstrations at the SEG included ;

Tsurf’s GoCAD modeling product integration with OpenWorks and GeoFrame.

CGG’s StratiMagic using Open Spirit Event services to interoperate with other applications.

Petrotechnical Data Systems (PDS) use Open Spirit data and viewing capabilities to display and select GIS data from the public domain Digital Chart of the World.

Elf Aquitaine Sismage – the componentized motor from the StratiMagic application.

Shell Services International demonstrated a new toolkit for E&P data analysis.

Open Spirit V1.0 product will be released in beta test in November 1998, with a commercial product in January 1999. Open Spirit builds on existing technology from Shell and the POSC Interop workgroup and promises a framework for software developers to plug and play with each other’s wares. At the most straightforward level, this involves agreeing upon a framework, a set of definitions of Common Business Objects (CBO) such as wells, seismic lines and so on. Then everyone can use these same objects in their applications. This simplistic definition omits the fact that the main environments that must be integrated are already there, and pre-date the framework. Open Spirit gets around this by building ‘sources and sinks’, which are translators for getting data from say Open Works, to an Open Spirit CBO. Of course it is not quite as easy as that to make new pots from old.

The Open Spirit initiative has defined some pervasive objects and methods that will be used in Open Spirit compliant software, but which will not exist as such in legacy applications. There will be two classes of Open Spirit ‘compliant’ software. Those that have been written from the ground up (in Java) to take advantage of the new Framework and CBO’s, and those which are legacy applications ‘wrapped’ with source/sink data servers. This poses potential future maintenance problems of the interface with the legacy applications. One IT manager for an international major suggested to PDM that a way around this problem would be to mandate compliance with, and support for the framework from approved vendors. An alternative would be for the major vendors to re-write all their applications to take advantage of the new way of doing things. But just before you start pestering your local sales rep, reflect on this. Landmark for one has around 90 million lines of code in their product suite. Re-tooling to Open Spirit, Java or whatever will not exactly be a trivial task.