How we can fix standards efforts in oil and gas

Failures in standards in oil and gas

I’ve spoken at several conferences about the failures in standards efforts in oil and gas. I’ve commented on the reasons for these failures. I’ve also highlighted the key characteristics of successful standards efforts in other industries.

In the short version, this boils down to my well-worn aphorism “adoption beats perfection”. The longer version is contained in the seminal paper by Hanseth and Lyytinen (“Theorizing about the Design of Information Infrastructures: Design Kernel Theories and Principles”, 2004). This despite its title, contains material that is relevant for all standards efforts.

Hanseth and Lyytinen identify five design principles:

1. Design initially for usefulness
2. Draw upon existing installed base
3. Expand installed base by persuasive tactics to gain momentum
4. Make it simple
5. Modularize by building separately key functions of each infrastructure, use layering, and gateways

A cursory glance at the standards documentation from bodies like Energistics and PPDM demonstrate a failure to adhere to some, if not all, of these principles.

Goals of standardisation

I can see three obvious scenarios where standards in oil and gas could be useful. There are probably more, but let’s start with these three.

First, we might want to be sure we can export all of the data from one system and import it into another. Either because we wish to use different software or because the software we’re using has reached the end of its life.

Secondly, I might wish to store my data in a repository from one vendor, but be sure that software tools from any other vendor can interrogate the data without custom programming.

Third, we might want to interchange a subset of data between two parties. Perhaps delivering fluid analyses from the lab to the operator, or daily production reports from the operator to the partners.

The first two of these represent a significant undertaking. They potentially imply a standard that covers a large information space, with many data elements. Even more importantly, they would require that we share an understanding of the semantics of our model. Even common terms such as well can have subtly different meanings for different disciplines in the industry. It is also possible that vendors have their own internally defined information elements and these must be either supported or discarded.

Working together

Over the years I have developed the view that most vendors are not entirely keen on these two scenarios. I would much prefer it if the standards in oil and gas could be developed such as to focus on the narrower goal of improving the way that an individual vendor’s software packages work together. The idea of opening the door to a competitor’s products is an uncomfortable one. Unless, of course, the experience can be guaranteed to be less than ideal. I am fairly comfortable with the assertion that this is one of the reasons for the failure of efforts like POSC. Though I admit that I have little more than anecdotal evidence and observation to support this view.

The third scenario has a more reasonable scale. It feels as though the development of a standard might be accomplished in a way that adheres to the principles advanced by Hanseth and Lyytinen. With that in mind, I will try to outline the activities that I believe are important for success.

The road to successful standards in oil and gas

First, we need to identify the exact scenario that is to be addressed. It cannot be an academic exercise, as the first principle is to design for usefulness. We should identify users currently experiencing a real problem, and establish how to fix it. Real and detailed use cases should follow.

Secondly, we should look at the ways people have addressed the problem in other companies, and also look for parallels in other industries. Perhaps a solution or a standard already exists. There might also be standards that seem at first sight to be unsuitable or only a partial fit, but if they are already in use and tooling is available then it might be preferable to repurpose them rather than create something from scratch.

Third, it is necessary to have reference implementations, to demonstrate that the standard is viable. Ideally, this will be used to solve the problem identified in the first step.

Fourth, a minimum of two software vendors must commit to a production-ready implementation within twelve months of the standard being approved. While it might be possible to accept non-vendors, the reality is that sustaining any implementation demands wide distribution of the kind that is only possible for software companies.

Fifth, in the event that production-ready implementations do not appear in the defined period, the standard will be open for deprecation. There is little value in having a standard that no-one implements.

Summary

In the above list I have not developed anything radical or revolutionary. I have simply listed activities that appear to have produced results in other industries and standards bodies.

To make one final point, XML does not a standard make. The world needs new XML schema like a hole in the head. Developing new schema should be a last resort. Constructing a data format is not the same as constructing a data model, and it certainly doesn’t define the semantics.