I’d like to offer some insight, gleaned from our attendance at two UK based IT/data management events in London this month. I submit that this is the sort of information that a) would cost you a fortune if it came from the likes of Gartner etc. and b) is of such simplicity and immediacy that the consultants would have to protect it with a bodyguard of hot air.
Sarbanes-Oxley
Readers of Oil IT Journal will have heard many dire warnings of the impact on IT systems of Sarbanes-Oxley (SOX), the post-Enron US transparency legislation. Paras MD Hamish Wilson, speaking at the PESGB’s Data Management conference this month (more of which in next month’s issue) described the increasing reporting burden that SOX has brought, with the requirement to demonstrate how reserves figures are obtained. Companies need to get a much better handle on their complex workflows which may involving seismics, stochastics and simulation. All of which is a potential field day for the IT consultants.
SPE
Following the PESGB do in Piccadilly, we strolled across St. James Park to Westminster for the SPE’s conference on Digital Security in Oil and Gas (again, more in next month’s Journal). Here we heard KPMG’s Chris Wright talk on what SOX really means for oil companies and their IT departments. Wright stated that the SOX provisions for control over corporate financial reporting are just that. The intent of the legislator was not that such controls should spread throughout the enterprise into technical analysis. There is a boatload of implications for IT managers but they are not about technical computing. ‘A lot of time has been wasted on systems that don’t refer to SOX.’
Archaic
The dividing line between technical and finance may be hard to draw, but the intent of the legislator is clear and has echoes in the SEC’s rather archaic definitions of ‘reserves’. When you hear technologists push for SEC’s acceptance of seismics and stochastics in reserves evaluation, you may want to reflect on the increased reporting burden that this would bring. I have an image of the petroleum engineering community’s collective finger on the trigger of a gun pointed at its foot!
~~~
Another piece of information triangulation this month links the talk from Shell’s exploration director Malcolm Brinded (opposite page), the Kalido webinar (page 12 of this issue) to recent presentations in Calgary (PPDM—page 6) and London (IQPC—page 12). Brinded’s plea for better tools for data integration begs the question, ‘is the upstream a technological leader or a laggard?’ If you believe Adam Dodson, Shell itself is a leader in terms of taming software ‘beasts’ like ESRI, LiveLink, Autonomy, MetaCarta, integrating them into an apparently coherent IM solution. OTOH, judging from Alan Bays’ PPDM talk, Shell’s own groundbreaking taxonomies could be improved. I listened to the Kalido webinar with all this in mind. Does the commercial data mining community have something to offer us in the context of taxonomies and the emerging ‘master data store’ technology? Watch this space.
~~~
When folks take a bird’s eye view of the standards arena things look fairly straightforward. In French they have a saying, ‘Yaca-Focon*’, which means ‘all you have to do is such and such and everything will be OK.’ I suggest this is a good starting point for what I would call the standards ‘disillusionment cycle.’
CRLF
You may think that ASCII is a standard, but even here there is no agreement on the most basic aspect of a text file, how a line of text is terminated. The story begins in the dark and distant past of computing, or rather before computing began, with the mechanical workings of a line printer. These devices used to be, and of course still are, proprietary, with complex control codes to make them print text, ring bells, feed the fan-folded paper and so on. In those days, there were separate ASCII codes for a carriage return and a linefeed.
iBook
My problematic workflow, which I have already exposed in these columns, involves a great deal of cutting and pasting. From websites, my own notes taken on an Apple iBook, Adobe pdf documents, Microsoft Office and so on. As anyone who has cut and pasted anything knows, this simple act is fraught with problems. In Microsoft Word for instance, a cut and paste can transform the target document’s formatting, numbering and even the spell check language. A trip through the good old Windows notepad as an editing buffer fixes a lot of these issues, except for one—the oldest IT gotcha in the book, the new line symbol which is variously a linefeed or a combination of a carriage return plus linefeed. If you ever wonder what your ‘knowledge workers’ are doing, there is a good chance that they are still occasionally futzing around with dumb stuff like this and I can assure you that there is nothing like it to stop the creative juices flowing.
Sand in ointment
Of course it would be easy to fix this. But we are years beyond the Yaca-Focon’ phase on the linefeed problem. In fact we are even beyond even the disillusionment part of the cycle. The problem is almost hidden as applications perform transformations on the fly. Sometimes they even get it right although as cutters and pasters know, the clever format guessing Word performs is not necessarily what was intended. Perhaps a bit of sand in the ointment is what it takes to make a company finally give up on ‘best of breed’ and go for a single vendor solution in despair.
Four seismic XMLs
Please do not get me wrong. I am a great believer in standards. I am just warning newcomers, the folks who think ‘Yaka-Focon.’ And to point out that if the simple stuff is so hard, we need to be very circumspect about the hard stuff. Talking of which I came across no less than four mooted seismic XML initiatives in the last month (from POSC/WITSML, OpenSpirit/Resolve, PPDM and the SEG) which suggests that there is a still a lot of Yaka-Focon-ism around. Happy new year.
* Il n’y a qu’à, faut qu’on.
© Oil IT Journal - all rights reserved.