When I last wrote an editorial on Business Objects PDM August 1996 it described the basics of Object Oriented software, and showed how using these techniques one should be able program in such a way that other programs, written in different programming languages, and running on different machines can be treated as resources at one’s disposal, much in the way a subroutine is called in conventional programming. I showed that while the OO approach to software engineering is of limited interest to the end user, a higher level approach, that of using "Business Objects" has shown promise in potentially facilitating that "holy grail" of E&P computing, that of interoperability between applications. I had written in what I thought was a fairly provocative manner, on a subject where I admit my knowledge was somewhat sketchy, and I had hoped to stir up a lively debate.
Interest
While the article did spark off a high level of interest form our readership as I had hoped, what did not materialise was the lively debate. What most people wanted was more of the same. Well in this issue, we are offering you the first in a series of articles from the industries top object specialists, Nigel Goodwin from Essence Associates.
Two groups that are currently working in the E&P arena (1) POSC - Business Objects and Interoperability Workgroup led by Alan Doninger of POSC. This group's mandate is to design a process by which the business objects for E&P are to be built. After this, a second modelling team will come in and build the object definitions. The final result will be a object specification which multiple companies will implement. (2) OpenSpirit Initiative - an outsourcing of a E&P object library from Shell International (SIEP in the Hague). GeoFrame from Schlumberger is also rumoured to be based on business objects using a proprietary BO platform. Landmark is yet to visibly support any BO initiative. Most smaller development shops in E&P express interest in the Business Objects, as long as it won't cost them and they don't have to build it themselves!
SLO..SLO..
Now that I have put my first expert witnesses to work, I can sit back and pontificate some more on where objects are taking us today. One quick answer is that the technology will always be hidden from the end user’s view (the best place for it I hear the hard-line IT-ers shout). Typical "hidden" uses for the technology are in software maintenance, where only updated versions of objects need to be distributed instead of a whole executable or library. But this a limited view of the potential indeed. What would be really fun, what would make end users sit up and listen would be if a big chunk of our data, say a seismic line, could be wrapped up and used as an object across different applications. So that the new SLO definition would allow seamless data to be dragged and dropped from ProMax to SeisWorks, interpreted and then passed on to say Charisma for modelling. Of course to do this, the SLO needs to know a lot more than say what is contained in the SEG-Y format. It would have to include navigation data, and probably attribute information, and god knows what else. In fact it would pretty soon end up looking like a data model unto itself. Which is OK, because the current trend is for the Business Objects to be a kind of meta-manipulator for the data model, as Nigel Goodwin explains.
Jury out
Still unresolved in the OO world are the intriguing commercial issues which we raised in the last OO PDM. Who will pay for this and who will own it? And perhaps most importantly, when will anything workable be delivered. As Robert Peebler stated recently, companies like Landmark just cannot afford to wait around for 10 years while various standard organisations agree to set up more subcommittees. They need results yesterday! Will OO accelerate or retard the dash for interoperability? The jury is still out.
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_199704_3 as the subject.
© Oil IT Journal - all rights reserved.