This article is approximately 610 words long. Click here if you would like to request a complimentary copy.
This article is approximately 805 words long. Click here if you would like to request a complimentary copy.
This is the penultimate edition of Oil IT Journal. I am stopping because of personal circumstances which I prefer not to elaborate on. Also because of a declining business. Folks seem to like reading Oil IT Journal, but most get their satisfaction from the free sample back issues. Fewer and fewer corporates are actually paying for a subscription. Enough of the bitching.
So two editorials to go… the next (last) will be a recap of thirty years of publication, a potted history of upstream IT, the people, the tech, the highlights and maybe not so highlights. I therefore propose to entertain you with some personal observations on the evolving art of upstream data management and IT. This will in fact include some bitching.
Oil IT Journal started out in 1996 as Petroleum Data Manager. That was the hot topic du jour. It’s interesting to reflect on exactly why. Digital data had been in the industry for a long time. Reservoir modeling has been digital in part since 1955. Seismic has been pretty well exclusively digital since the 1960s.
As you all know, data volumes have since been on an upward trend. For many oil companies in the 1990s, the volumes of data on disk and tape were getting out of hand. Managing all this stuff is a bit non linear as folks like to say. A few boxes, OK. A warehouse of stuff, paper records, navigation data and field recordings not so easy. Very tricky in fact. Tricky but not the sort of activity that geoscientists and engineers really like doing. Thus was the discipline of data management born. A curious activity that required knowledge of both the geoscience discipline (aka the ‘business’), the digital tools of the trade (aka information technology) and a capacity to invent and implement the ‘management’ of all of the above.
In the early days the new activity attracted some smart people who pontificated, decided what needed to be done, did a bit of this and that, then got bored and left to do greater things. There was a recognition that a ‘data manager’ was never going to make CEO. In parallel, IT was staffing-up and developing along rather different lines (SAP for anyone?). As befitted a novel field, IT was also constantly inventing new paradigms, new solutions and searching for the ‘next big thing’. Data management was tributary to this Brownian motion and became something of a headless chicken. Which it remains to today. Folks continue to present papers, voice opinions on LinkedIn about the same issues as were raised thirty years back. These revolve around lack of funding, lack of management support, failure to adopt the latest technology and so on. In the last decade we have seen the arrival of OSDU, of machine learning and large language models. All next big things that keep data management from settling down into the rational, mostly automated activity that it ought to be. Think how a seismic contractor or a logging contractor acquires petabyte data sets in the field, gets it all into the computer, does quite a lot of clever stuff and outputs interpretation-ready data sets. All without ‘data management’.
OSDU represents the latest in a long line of data management quasi-failures starting with POSC Epicentre and Business Objects, the PPDM data model and others. Such initiatives are driven by the standardization movement that the oil and gas majors favor. The argument goes: with our current software portfolio we cannot link data in application A from vendor B with application C from vendor D. So instead of asking a vendor to write a script to transfer such data, data managers step back from the immediate problem and try to imagine a solution that will fix not only the problem in hand, but also all other problems, real and imagined that exist now or may exist in the future (curiously, these same folks often warn others of the danger of ‘boiling the ocean’, but I digress).
Now another facet of all this and one that I was guilty of myself when I was a young geophysicist (some fifty years ago) is that geoscientists and engineers in major oil companies have a very high opinion of themselves and a rather low opinion of the vendor community (see the piece on the Polo of Kings in our last issue). Faced with problems such as the ones above, the answer is to set up a partnership with their self important peers from other majors of a similar ‘status’. This may be a closed shop affair or perhaps a more open forum to develop a ‘collaborative’ solution. The closed shop has the advantage that, being free of scrutiny, there is no obligation to achieve anything.
The new partnership may involve setting up a ‘standardization’ effort to address some perceived problem – likely one that does involve boiling the ocean. Meetings ensue, things drag on and in general little is achieved. Except for two things. The menace of an industry standard can create the IT equivalent of planning blight. Vendors whose solutions just work (perhaps in a non collaborative proprietary fashion) may have a hard time following the sluggishly developing new standard. They may even be punished if they do not support the standard as we have reported.
Another unfortunate downside of the standards movement is that it gives a very misleading picture of what is really going on. This is particularly evident in that small part of academia that bothers itself with oil and gas IT. Because the standards bodies communicate well (that’s about all they do well in fact), students are directed to research such efforts. Sometimes with surprising results – see our recent reporting on Norwegian university investigations into OSDU. Outside of oil and gas, the whole field of the ‘semantic web’ standard which Tim Berners-Lee dreamed up circa Y2K has spun out innumerable ‘ontologies’, government funded studies and ‘standards’ which have failed to produce anything of worth. The ontologists are still knocking at the door of OSDU and CFIHOS by the way.
How can things have got into such a pickle? I have a couple of explanations. A) things are not as bad as they seem. Data can always be exchanged even if done in a less than perfect manner. Life goes on. Oil and gas offshore platforms are built without ‘standards’ other that those that the EPC uses itself. Seismic interpretation has become very sophisticated with help from an inventive vendor community which has shown that pretty well any non seismic data can integrate the workflow if required. B) IT is a phenomenal invitation to futzing. Programming a ‘solution’ to a problem from first principles is much more fun and intellectually stimulating than looking for a solution in the marketplace. Python offers rewards that are comparable to solving a Sudoku (and may be as useful). C) Another reason that the data management folk appear to be constantly struggling is that in reality, the community lives on such inefficiencies.
So is AI going to come in an fix all of the above? At the 2026 ECIM conference which we will be reporting from in our final edition several presentations showed how AI could integrate the data workflow. These generally imagine that the AI toolset will be used by data managers to improve their current ways of doing business – eliminating grunt work and enabling the data managers to achieve greater things whatever these may be. Elsewhere, AI has been shown to be effective at ‘rethinking’ whole processes and, yes, eliminating layers of the workforce. The question then arises as to where in the whole company structure should AI be put to use? This is a really interesting question. If you asked the boardroom how to engineer the ideal prompt that was to run the company I suspect that the C-Suite would be hard pressed to say exactly what this might be. Now if you were to ask your favorite LLM ….
But all of this does not quite explain why the majors spend so much time and effort on non productive activities that involve sending people around the world for ‘face-to-face’ gatherings. I believe that this is due to the joint ventures that the majors create to explore for oil and gas. And more precisely in how joint venture accounting works. When a few majors get together to form a JV, one is designated the operator. The operator performs various tasks, interpretation, drilling, producing and so on. Most of this activity is performed by third parties whose bills (for seismic, drilling and so on) are divvied up and paid for the JV parties. But the operator’s own work also needs to be paid for by the JV. Time sheets are filled out by geoscientists and engineers and again, paid for by the JV. But there are a lot of other activities that the operator performs that represent its cost of doing business. A portion of these are actually carried by the JV under the term ‘overheads’.
I have to confess that I have not seen a JV agreement for decades but I suspect that a lot of the rather unproductive activity I describe above ends-up being paid for by the JV as overhead. Since overheads are monies that go straight from the JV partners into the operators pocket, it is in the operator’s interest to make them as high as possible. The JV partners may squeal, but probably not too much since they will be running the show in the next JV and pocketing the proceeds. Thus does the Brownian motion turn into a cash cow!
This article is approximately 1152 words long. Click here if you would like to request a complimentary copy.
This article is approximately 503 words long. Click here if you would like to request a complimentary copy.
This article is approximately 496 words long. Click here if you would like to request a complimentary copy.
This article is approximately 334 words long. Click here if you would like to request a complimentary copy.
This article is approximately 291 words long. Click here if you would like to request a complimentary copy.
This article is approximately 302 words long. Click here if you would like to request a complimentary copy.
This article is approximately 371 words long. Click here if you would like to request a complimentary copy.
This article is approximately 337 words long. Click here if you would like to request a complimentary copy.
This article is approximately 625 words long. Click here if you would like to request a complimentary copy.
This article is approximately 288 words long. Click here if you would like to request a complimentary copy.
This article is approximately 270 words long. Click here if you would like to request a complimentary copy.
This article is approximately 288 words long. Click here if you would like to request a complimentary copy.
This article is approximately 605 words long. Click here if you would like to request a complimentary copy.
This article is approximately 222 words long. Click here if you would like to request a complimentary copy.
This article is approximately 140 words long. Click here if you would like to request a complimentary copy.
This article is approximately 219 words long. Click here if you would like to request a complimentary copy.
This article is approximately 165 words long. Click here if you would like to request a complimentary copy.