Since we created our cloud service in 2009, one of the first in oil and gas and still the leader, we have built and managed our own infrastructure in multiple data centres in the UK. After a year of work, in the next week we’ll be moving our platform to infrastructure provided by Amazon Web Services, and I wanted to explain why.Details
In my last post, I discussed the origins of our company, what motivated us, and the problems we were trying to address. I discussed our primary driver as the belief that it had to be possible “to do it better.” As the company evolved, nowhere was this need for improvement more evident than in oil and gas software, but the path wasn’t easy.Details
We run a cloud service for oil and gas. Our goal is to grow organically, and to grow profitability not staff numbers. We value a high degree of autonomy, and we operate entirely virtually. We’ve been extensively using cloud services to run our business for over ten years, and now virtually everything we do, from mail and calendar to accounting and document management, is done in the cloud.
However, we didn’t start out that way.Details
At our regular Hydrocarbon Allocation (HA) Forum in Aberdeen yesterday, we had a terrific “state of the union” presentation by Laurence Ormerod, Consultant and Project Manager for the PRODML standard. By the way, if you don’t attend our HA Forums then you might want to check out our website for details, and sign up for our mailshots. They are intended to be deliberately free from sales messages, and are generally held in Aberdeen at breakfast or lunchtime.
Laurence provided a really good summary of the history of standards development for production data.Details
An article on open source tools to “make your presentations pop” intrigued me initially, then bemused me, then annoyed me. Ignoring for a moment the desirability or otherwise of having presentations that “pop”, the bemusement came from the realisation that the entire focus of the article was on creating effects and transitions, and absolutely nothing about content. The annoyance began when I realised that several of the oil and gas conferences I’ve attended recently have implicitly taken the same approach, focussing on presentation over content.Details
People often ask me how our cloud service for production data management, production reporting and production allocation is different from traditional solutions. This is a hard question to answer, as I want to describe the distinct values of my product and company without seeming to denigrate the competition.
In addition, it’s really hard to provide quantitative information. We think an EnergySys solution is hands-down the fastest, most cost-effective and most configurable choice for customers, but this is largely based on anecdotal evidence. It’s rare for two companies to have delivered systems for the same assets under the same conditions, though we do have a fair amount of experience of replacing competitor systems, so an exact comparison is difficult.
However, during the course of a discussion with a company looking to replace a competitor system I realised that part of the answer lay in the conversation we were having. This user kept talking about projects. Projects to implement new assets. Projects to add new fields or wells. Projects to upgrade the basic software. Everything was a project. And projects required substantial time, money and resources, even just to get a basic upgrade of the software done. In fact, for this user an upgrade cost almost as much as the original project implementation! EnergySys isn’t like that.Details
I’ve spoken at several conferences about the failures in standards efforts in oil and gas, and 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) which, despite its title, contains material that is relevant for all standards efforts. They identify five design principles:
- Design initially for usefulness
- Draw upon existing installed base
- Expand installed base by persuasive tactics to gain momentum
- Make it simple
- Modularize by building separately key functions of each infrastructure, use layering, and gateways
This has led me to consider the goals of standardisation in oil and gas, and what might help with their adoption.
I can see three obvious scenarios where standards could be useful. There are probably more, but let’s start with these three.Details
In a recent survey we carried out, (download the report here), we asked professionals involved in Hydrocarbon Accounting (HCA) how confident they were in their data. Around 65% said that they were “not at all” or only “somewhat” confident in the data they were using as input to the hydrocarbon allocation process. This situation is problematic, given that allocation is all about determining the division of ownership of hydrocarbon products, and that mistakes can have a real and substantial financial impact. Inadequate systems and processes can make it difficult to manage routine issues like mismeasurements, and initially small problems can give rise to a cascade effect with consequences that are difficult to unravel. A failure of compliance is not the least of the potential problems.Details
I made a presentation at yesterday’s conference on Developments with the Digital Oilfield in London. The title of my talk, “Why private cloud is a cul-de-sac of doom”, was somewhat tongue-in-cheek, and intended to be mildly provocative. However, I had a serious purpose, in that the words and terms we use to describe things are important in creating clarity and driving ideas. Misusing them dilutes their power and ultimately diminishes opportunities. In that context, the term “private cloud” is one that has minimal value and causes confusion.
In my talk, I referenced the NIST definition of cloud computing, and my version of the three key elements that embody the transformational impact of the cloud:
- A usage-based payment model, whether that’s per user, per cycle, per cpu, or whatever
- Rapid elasticity, or the ability to seamlessly grow and shrink your demand without needing to stop to add new hardware or software
- No barrier to exit or entry
In a recent posting to LinkedIn, comments from an oil company contact were reported to the effect that high levels of investment in hydrocarbon allocation systems were unsustainable. The poster invited people to consider whether it was time to concentrate on value for money. I won’t link to the post, partly because it was on a closed group, but also because I wanted to focus on the general issue that it raises, rather than the specifics of the post.Details