In this issue we have played catch-up with the conference season. While we attend quite a few ourselves, there is no way we can be everywhere. Fortunately, many conference organizers and standards bodies have the good grace, and I think good judgment, to put their proceedings online, allowing us to capture what I hope is at least the gist of what took place. This month we provide virtual reports from PPDM, OPC-UA, GITA/PODS, POSC/Caesar, a ping from the W3C Semantic web oil, gas and chemicals business group and some new ‘P-formats’ in our ‘Standards stuff’ feature.
Many have tried to describe the essence of what a standard is. I don’t propose to go there exactly, just to look at some of the things that characterize the different initiatives above. But before that, let me say what standards are not. Standards are not a ‘motherhood and apple pie’ phenomenon, an unequivocally ‘good thing.’ Neither, as been suggested, are they a sure-fire way of ‘avoiding major disasters’ or necessarily, enhancing operations in the environmentally tricky ‘high north.’
Standards generally involve a time-consuming, possibly costly effort of uncertain outcome. How costly? Well the latest ‘semantic’ EU project, ‘Optique’ will consume a cool €14 million of (mostly) taxpayers’ cash. Standards may fail completely or become commercial ‘footballs,’ kicked around by vendors, used and abused. Thankfully, they do sometimes work and may even be gratified with the ultimate accolade—take-up!
What follows is a rushed and poorly thought out guide to how to spot a ‘good’ standard that will hopefully bring you a degree of success with a minimum of headache.
First reflect on where the standards’ home community is in relation to you. If you work in the upstream, some of the kit that is deployed on say a production platform may be the same as that used in a refinery. This gives an apparent degree of comfort in that you are thus member of a community that extends to, say, the refinery. But but it may have a downside if the kit is so widely used that its center of gravity is out in the discreet process (manufacturing) business. Then you will have a smaller voice in how the standard develops. A related issue is the standard’s ‘event horizon.’ The larger the scope, the more ‘foreign’ problems come into view and the more complex and intractable becomes their solution. Even apple pies may be too big to digest!
Next check out the underlying technology. Today, standards are delivered as Word documents, XML schemas, SQL data models. All of which are by now reasonably familiar technologies. They have the advantage that you should not find it too hard to hire people who understand the basic mechanics of the protocol. If the standard uses more esoteric technology like the semantic web (as PCA and its US cousin Fiatech have), then you are talking to a much smaller community of practitioners and expose yourself to the risk of being bamboozled by the technologists.
Another consideration is what exactly is being standardized and how ‘mission critical’ does it have to be. In telecommunications and finance, phone calls and cash circulate around the world thanks to prescriptive, tightly drafted standards. In the upstream, there is in general some wriggle room for personalization and preference. An SEG tape standard or a PPDM database will often require some inspection before use. Why don’t we have tight, prescriptive standards in oil and gas? That is a good question...
You might think that all of this is just an amusing part of technology’s life and that it doesn’t really matter that standards progress slowly—they are after all great forums for getting together and discussing stuff—not at all a bad thing. But what would Neil McNaughton do if he were in charge of a standards project?
Taking it from the top I would suggest the following rules. Use a technology that already has traction (XML or SQL). But also use a technology—don’t deliver in a Word document or a ‘spec’ for an 80 column Ascii card. The consensus today is that XML is the bees knees. When you are through developing your standard, provide a validation mechanism . This is part and parcel of the XML package, less obvious in the SQL world. Use familiar terms that your community really understands and (preferably) agrees on. If you use a standard vocabulary or ‘list of terms’ do not pretend it is an ‘ontology.’ Do not seek to or (even worse) claim that you will ‘boil the ocean.’
The unfortunately rather common ‘boil the ocean’ phenomenon works at two levels. First any project that includes the word ‘enterprise’ implies ocean boiling. Second, as soon as IT is involved, there is a tendency to want to abstract a problem set into generalizations. These tend to extend the standard’s event horizon with stuff like ‘data agnostic’ transport mechanisms. This leads to amusing situations such some slide ware showing POSC/Caesar’s ISO 15926 as carrying OPC-UA traffic and elsewhere, OPC-UA as carrying ISO 15926.
You may or may not be impressed by all of this. You would be in good company. You only have to look to how BP (OITJ Nov 2011) and Chevron (this month’s lead) approach enterprise data integration. Both companies, while supporting plethoric standards efforts, are more circumspect when deploying their ‘real world’ solutions and have deployed Composite Software’s data virtualization toolkit—buying or building adapters to native data sources. This may be because at the enterprise level, there are so many ‘standard’ protocols around that there may as well be none!
To sum up. May your standards be focused—small is beautiful. Use your domain specialists to fix domain problems. Don’t fret about stuff beyond the event horizon—there are many off the shelf solutions for data integration at the enterprise level now. Use tried and tested technologies deployed by knowledgeable and straightforward technologists. Talk to them! Ask for their ‘elevator pitch.’ If it’s all Greek to you that is a bad sign. If they say ‘enterprise’ or ‘ontology,’ you could even show them the door. Happy holidays.
© Oil IT Journal - all rights reserved.