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.
We had a huge amount of experience in the development of software for tracking and reporting of ownership of hydrocarbons, and we didn’t think that customers got the systems they really needed. This is a specialist area, and you can certainly be forgiven if you’ve never heard of hydrocarbon accounting or production allocation, but it’s a key part of the oil and gas business. Managing this data, and performing these ownership calculations in a fair and equitable fashion, is at the core of every partnership between oil and gas companies who are developing an asset together.
At that time, the available systems, including ours, were hugely expensive to acquire, and required massive amounts of man-time to implement and maintain. Software vendors built their fortunes from man-time services, so it was not in their interest to make systems easy to set up, or easy to change. And that struck us as particularly odd, as hydrocarbon accounting systems generally need to change on a regular basis. New fields, new assets, new partners, new metering, changes in product specifications, new buyers, new transportation mechanisms, new agreements. It was rare to find a system that didn’t need to be changed at least once a year, and often several times a year, and that required a project and expensive man-time services. If customers had been buying electricity, it was as if the suppliers asked customers to describe their ideal power station, and then they built it from a set of parts like generators and turbines. Further, it would be constructed entirely to the customer’s specification, ignoring the fact that they would typically have almost no knowledge of a power station and how it worked. Given this, it’s possibly not surprising that many of the systems that vendors delivered did not actually do what was needed, and a number of projects were complete failures.
We set out to address this. Over the next few years, each time we started a client project we re-evaluated and enhanced our systems architecture, and tried to think about change as a fundamental fact of life. We developed a lot of interesting technology, and delivered some really outstanding systems. However, we didn’t achieve our goal. There were two reasons for this, and neither of them was about technology. First, we were trying to make this revolutionary change while delivering a customer project. This was doomed to failure, as the time pressures of the project forced us to make decisions that worked for the project, but not for the product. Secondly, we were thinking as developers. We saw the amount of developer time, and we were focussed on what we could do to reduce this time on a project.
In 2007, we broke free. First, we invested our own money in developing a product, free from the constraints of project timescales, costs and deliverables. Second, we thought about the problem differently. The key was to ask the question: “What would it look like if we built a system that didn’t require developers and programming and, indeed, if it was possible for business users to do all the configuration themselves?”. I often describe our technology, and some of the really clever things our people have done, but this change of world view was absolutely fundamental to our transformation. Right then, we stopped being a man-time services company, and we became a product company. Right then, we started focussing on what our customers really needed.
In my next blog post I’ll discuss how we designed our software to be configurable and open to change by business users. I’ll also explain why we went to the cloud, at a time when people told us that hell would freeze over before customers would store their production data in the cloud.