NMcN When you visit the PetroConnect website it is easy to be overwhelmed by the scope of IBM's offering in the E&P field. There is software, hardware, services - a finger in all pies! How would you define IBM's approach to supporting the E&P sector in the field of computing and data management.
G.P. IBM has undergone much reorganization over the last few years, and we now have two principal branches, - "customer facing" and brands. The customer facing people are there to gain an understanding of client's business needs and to match IBM's offerings to them. The brands division contains the familiar hardware and software groupings such as PC, RS6000, AS400, our ES390 mainframes, solid state hardware, networks etc.
About three years ago IBM launched what have been termed "special views" of customers - who were previously grouped together according to their industry. These new views represent a different segmentation of our marketplace such that different industries sharing the same methods are now grouped together. In our Process and Petroleum division for instance, we have petroleum, petrochemicals, forestry, textile and apparels - all linked by the common connecting thread of a process transforming an input into an output.
N.McN. This thread is obvious looking at the downstream oil business, but it is a bit harder to discern in E&P.
G.P. Of course, the Petroleum division is further sub-segmented into oil products, petrochemicals and E&P. Our mission is to populate these divisions with customer facing people with the relevant skills and backgrounds and also to supply technology appropriate for the sector. These are set up as Industry Solutions Units, with strategic and tactical roles. Many customers have their own IT architecture and plans and we respond tactically to these. Other companies may be seeking our strategic offerings and our consultants will engage with them to identify their business objectives and in this context we have noticed great interest in data management, where there is an urgent need to collapse time frames.
N.McN. Who do you talk to in oil companies, the CEO, the IT people?
G.P. If required we will talk to the company president. Businesses are increasingly taking over IT having been frustrated with IT departments. The business now says "show me the value" and it is the requirements that determine the technology. What used to be a technological push is turning into a business pull with the aim of a more effective use of IT. Of course not all of our customers are the same. IT departments may come in different flavors, some with corporate standards - like SAP, with different internal IT organizations, one IT department per domain, hence the focus on our client-facing activity.
N.McN. Can we now focus on IBM's E&P specific offerings. IBM has had a long history of involvement with E&P data modeling in particular with the Mercury project in the 80's and with PetroBank in the 90's, how do you situate your E&P domain activity today?
G.P. The industry at large has been taking a long look at itself and has began to re-form its core business with a focus on assets, usually oilfields, and asked the question "how do you improve these assets?". Do you acquire new assets, if so by purchase, or exploration. This leads on to issues of how to manage these assets and the view of the asset's lifecycle. This itself evolves through a field's life with issues such as more seismics, delineation wells early on in the field's life, water-flood and so on. IBM spotted this developing trend and also did some assessment of market size. The first thing we realized was how dependent on data management the cycle was, which was of great interest to us because IBM is extremely strong in this field. Some 70% of all the data in the world is stored on IBM mainframes, so it was natural to try to apply this strength to E&P.
The analysis showed that there were some strong, competent products out there, in acquisition, processing and interpretation. The industry has a long history of investment in these fields by companies such as Landmark GeoQuest and others and it would be extraordinarily difficult for IBM to contemplate gaining a competitive advantage in this area.
As I said though, we determined that the management of the data was critical to this activity - not just in the field of acquisition, but in tracking an asset all the way through its' life-cycle of. This involves managing persistent data - where media is as important as software, where the read/load/manage cycle needs a standards based approach that is viable for perhaps 30 years or more. This led us to implement our data management solutions on POSC and we continue to believe that this is the way forward. This does not mean, though, that we believe that the industry's problems will be solved by building the "mother of all" databases.
N.McN. Wasn't that POSC's intent though?
G.P. Yes in the subsurface, but not for facilities. Lets return to the field asset. The asset is what is important, it is managed on behalf of the asset owner - or perhaps one or two owners. It is serviced by many more contractors. All this requires coordination and easy access to contract information. In the world of "leaner and meaner" companies we need multi-contractor access to data and links to business management.
N.M. So POSC has been more successful in facilities than in the subsurface?
G.P. I was thinking particularly of the POSC/CAESAR compliant VAV project which is going well but we haven't finished yet. One reason the facilities area is ahead of E&P is because of the prevalence of the PC as the hardware platform.
N.McN Does IBM see POSC's DAE as the way forward, or the relational projection of Epicentre?
We follow and implement POSC as far as possible, we are certainly not intending to promote a competing architecture. In fact the DAE when it is released next year will be promoted as the preferred means for applications to access the Project Data Store (PDS).
N.McN. Do you see the wave of business software tools such as SAP Oracle and J.P. Edwards as crossing the divide between finance/administration and the E&P technical department?
G.P. That's not clear. We are currently working on links between PetroBank and the PDS - which today is a development of the Tigress database, but which is being migrated to Epicentre. PDS handles multiple copies of an interpretation perhaps done by different teams. PetroBank to SAP links would need to be implemented at the project level - we are currently working on this.
N.McN. Can we now take a look at the broader world of IT, and where you think that's going. To take one of your earlier statements about technological push being replaced by business pull, I remember the days when everything just had to run on UNIX, as though that was the only criteria for an E&P buyer. Do you think that Java is shaping up to be another example of pure technological push?
G.P. An aspirin looking for a headache? To an extent, but Java is useful especially in the pace and ease of Inter/Intranet implementation. IBM's view is that the Internet's underlying suite of standards promote information for everyone anywhere. Java complements this vision very well but IBM is not in the Java/Windows 95 war - nor in the PC/Net PC war either. We will make our products compliant with what is required.
N.McN. Would you go as far as to say that the Internet has solved the problem of Client/Server computing?
G.P. Yes. Of course performance and availability of critical business applications still need improvement. Security is also an issue before e-commerce will take off. Incidentally, the development of PetroBank has been in the forefront of secure systems. There have been orchestrated attempts to break into PetroBank so far without success.
N.McN. What is IBM's attitude towards the POSC Business Objects/Interoperability initiative, do you see this as an alternative route to the "mother of all databases" approach.
G.P. We are very strongly committed to object technology and use and promote OO programming techniques heavily. Without getting too technical, if you define an objects as actions and associated non-persistent data they begin to start looking like mini-applications. You will still need a database or databases for the storage of persistent data. Our experience in manufacturing, comes in here where an object framework fits the business quite naturally. In fact the applications we have developed using this technology have been used in other industries.
N.McN. In PDM we have been tracking the way the E&P software industry, far from moving towards interoperability, seems to be polarizing around GeoQuest's GeoFrame environment and Landmark's Open Works. Do you see IBM, with PetroBank and the PDS developing as a third pole here?
G.P. I don't like to think of a third pole. We have developed a POSC compliant architecture allowing for plug and play for similarly compliant applications which lowers the entry barriers to new vendors and promotes cooperation between say the petrophysicist, seismic interpreter, petroleum engineer. As businesses follow the asset based paradigm I outline earlier, speed of change becomes the dominant factor - wouldn't it be better if more companies adopted this POSC based technology - that is the key.
N.McN. That still sounds like a third pole to me, and GeoQuest also claims POSC compliance.
G.P. If GeoQuest want, they can plug and play with us! Landmark has already an agreement with PetroBank. The problem is one of direct access to the data - comparable to a direct write to hardware in the Windows environment. End users want performance, when you take the high ground of standards you can starve up there. The same issues apply to the thorny problem of upgrading the data model. At some point you will have to make someone unhappy! I believe that the industry is at a turning point - vendors are to an extent at the mercy of their customers. The usual trade-offs apply, short term-ism versus the long term, performance against interoperability. We need tangible support for standards and we need it soon.
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_199710_4 as the subject.
© Oil IT Journal - all rights reserved.