Faster computers and better software are the keys to bringing different disciplines together.
For years software vendors have boasted of the “seamless integration” offered by their products. But those in the trenches know that seamless integration is often more wishful thinking than reality. E&P talked with Rutt Bridges, CEO and chairman of Quest International Management Co. and the former chief technology officer (CTO) for Landmark Graphics, about recent advances in data integration.
E&P You’ve talked about the continuing integration of geology, geophysics, and engineering and how the “silos” seem to be coming down. Why is that important?
Bridges Silos are expensive structures to maintain. And it isn’t just about layers of management. Silos block the view of the “big picture” for finding and developing resources. But while the “asset team” concept has often proven to add value, it’s a lot easier in PowerPoint form than in real life.
Silos also limit the flow of information. Developing resources is fraught with incomplete information. By combining the information from multiple disciplines, fewer mistakes are made. It is a bit like the parable of the blind men and the elephant. Only by sharing their knowledge can the elephant be “discovered.” And if we are to satisfy the world’s need for resources, we really need to be able to discover more elephants.
If you’re a hammer, every problem looks like a nail. Too often geophysicists are trained to see solutions from a seismic perspective, geologists from a well/log perspective, and engineers from a drilling/production perspective. It’s no surprise that engineers often rise to the top of organizations since their domain is where most of the money is spent.
To be more successful in their careers and to bring more value to their companies, geophysicists and geologists can learn a lot from the broader view of our science and economics that comes from being a part of an asset team. And engineers can better appreciate both the value and limitations of seismic, logs, and geologic models. This means working with integrated data. For companies with the long view, asset teams are a profitable way to accomplish that goal.
But it also takes integrated geology, geophysics, and engineering (GG&E) software. When I think about the communication problems created by silos I think about the Mars probe that crashed because of imperial-to-metric conversion errors. No doubt dry holes have been drilled with similar flaws. Fortunately, the powerful but invisible hand of the market has driven greater and greater integration in our software.
E&P Can you give some examples?
Bridges In 1994 the company I had founded, Advance Geophysical, was acquired by Landmark Graphics, thus bringing together leading products in desktop seismic processing (ProMAX) and interpretation (SeisWorks). Under Bob Peebler’s visionary leadership, we acquired a wide range of companies in geology, drilling, production, and economics, plus Geographix for PC-based seismic interpretation. With varying degrees of success (and a lot of baling wire) we then “integrated” these under the OpenWorks environment. I believe that this was the first really integrated suite of GG&E products, and it was certainly profitable for Landmark.
But this kind of classic business “roll-up” has its advantages and disadvantages. I served on Landmark’s board and as CTO during this period. As such I was like the pig who was committed to breakfast as opposed to the chicken who was merely involved. Trying to merge all the corporate cultures and keep everyone happy (or at least only slightly homicidal) required a saint. Unfortunately, I didn’t qualify (still don’t). But at least nobody died.
The real problem with this approach is that true integration works best when you start with nothing but a clear design vision and a clean whiteboard. Nonetheless, most of the major software vendors have made great strides in the last 10 years in integrating their existing products and acquiring products to fill gaps in their software suites.
However, integrating geology, geophysics, reservoir, and production engineering (not to mention economics, risk management, and facilities design) is a tough nut to crack.
The following, in my opinion, are some essential elements:
1. A common, shared and extensible data model: Easy to claim, hard to achieve. You’ll frequently find this in companies’ brochures, but less often in their software.
2. An effective shared earth model: That’s why Schlumberger acquired Petrel and Paradigm acquired EDS-GOCAD; Roxar built theirs.
3. A consistent user interface design across all products: This requires an “enforcer” with not just the responsibility but the authority to “make it so.” They are not always loved by developers.
4. Strong technology in multiple disciplines: Not just GG&E but computer science as well. This also requires the vision to anticipate and accommodate what’s over the horizon.
5. Object-oriented code, such as Java: A fault object can grow and accumulate information about itself as it is passed from geophysicist to geologist to engineer.
6. The ability and attitude to integrate “best of breed” third-party products: No single company can be the best at everything. Great outside technology must be welcomed and embraced.
In addition, there is a natural tension between size and speed in software development. This is related to the number of interconnects within a development project. Past a certain point, the more developers, scientists, engineers, and interested parties, the tougher (and slower) it is to create great software. Big committees simply don’t write great software.
I once encountered a project that had been under design for more than two years and had a 4-in. thick specification document to prove it. By tossing the book and selecting a highly driven developer who understood what was really needed, 98% of the client’s real requirements were satisfied in three months.
I’m currently working with a new company. The developers are serious computer scientists but have strong backgrounds in one or more other areas: geology, geophysics, reservoir studies, simulation, modeling, and advanced mathematics. That dramatically reduces the number of interconnects and, in my opinion, produces much better software and much shorter development cycles. It’s a lot more stimulating to talk about an idea and then see it the next day … or the next hour.
E&P What new computer technology is enabling this integration? Are there other trends that are also playing a part (i.e., new algorithms or new ways of thinking in 3-D)?
Bridges If I had to pick just one high-impact technology, it would be CPU chips with multiple CPU cores. The new-generation processors currently offer up to six CPU cores per chip (and eight later this year). Dual quad-core processor workstations (eight CPUs) have gotten to be fairly common, and next year we’ll likely see four-processor “octo-core” workstations with up to 32 CPUs.
All that tech-speak translates into an enormous amount of computing power at your fingertips. Those spreadsheets and expense reports will fly like never before! But the catch is, unless your GG&E software vendor has “multithreaded” its code to use all those CPU cores, you won’t see much difference. As a friend of mine once observed, “A powerful computer lets you make mistakes faster than any other human invention except for handguns and tequila.”
An alternative approach is to use a centralized compute/storage server with lighter weight desktops linked to extremely fast networks. Such servers often contain hundreds of processors, many terabytes of memory, and vast fast disk arrays. Unfortunately, you sometimes have to wait in a queue for your job to run. But once the jobs start, they run quickly.
I find it odd that so many companies continue to outsource workflows like attribute computation (coherence, curvature, spectral decomposition/inversion/enhancement, etc.) instead of doing these tasks themselves on multicore workstations or compute servers. When you look at the vendor fees and real costs of waiting on results plus the improved fidelity that comes from parameter-tweaking by the people whose interpretations depend on the results, it just doesn’t seem rational anymore.
If you really want to understand the market forces behind all these advances, look no further than your family room. The kids are playing video games and listening to iTunes over your wireless network, and the DVR is saving your favorite show. Consumers constantly demand faster, better, and more realistic. Believe it or not, today’s GG&E graphics displays owe a big debt to Halo and HDTV. How far off can inexpensive, immersive 4-D virtual reality worlds be?
E&P How will computing trends affect the software of the future?
Bridges I think the current trends in computers and software will be great enablers for asset teams.
For example, if a geophysicist is to really understand geology, reservoir modeling, or facilities planning, he or she is bound to make mistakes. That’s how you learn. As Will Rogers said, “Everyone is ignorant, only in different subjects.” Fortunately, “ignorant” doesn’t mean “stupid.” The secret is to be able to make mistakes quickly, recognize them, learn from them, and move on.
Of course, some basic education is needed. You don’t need to understand Maxwell’s Equations for electric and magnetic fields to use a power saw. But you do need to know enough to keep from cutting your fingers off.
Software should play a strong role in this education process. Being able to play what-if scenarios and quickly see results has a lot of value. Modern computers have the power to accomplish that. But analytical tools and graphics have to be good enough to make the errors obvious. It doesn’t take a genius to spot a goat in a flock of sheep.
But the graphics have to make that goat stand out.
In some cases it isn’t just about learning other disciplines. A lot of geophysicists know that seismic inversion can help them find oil, but too few of them feel qualified to run today’s inversion software. That’s unfortunate, as it costs time and money to contract out such so-called “specialty” disciplines. And the problem isn’t the people — it’s the software.
Documentation shouldn’t just explain parameters. People must create and exercise the workflows, not just read about them. Modern documentation should lead you through case histories, ones that aren’t all sweetness and light. Users should be challenged to solve real problems rather than be spoon-fed easy results. For example, anyone who uses a sonic log without looking at the associated caliper log needs to learn the value of data quality control and how to edit logs. As Aristotle said, “The roots of education are bitter, but the fruit is sweet.”
Beyond that, far more powerful computers can make it possible for software to be a lot “smarter.” Many of the parameters users currently must specify can be made adaptive, with the computer essentially dynamically adjusting the algorithms to match the data. And I am always annoyed and disappointed when GG&E software demands that I provide information that is already in the project database. Finally, software should learn from how I use it, offer intelligent defaults, and let me know when I appear to be making a mistake, all without being annoying. But it should also let me make that mistake. I just may have a good reason that is beyond its silicon comprehension.