STAFFORD, TX.–From small independents to supermajors, every oil and gas company is striving for greater efficiency across the enterprise and greater value creation in a turbulent global economy. At the heart of every energy company’s business model is an increasingly complex exploration and production workflow that holds the potential to either create or destroy value.

Except in rare cases, almost every exploration, drilling and production organization deploys software applications and data stores from multiple vendors. This situation often results from mergers and acquisitions, which bring together disparate technologies under one roof. Some companies may mandate a corporate standard–a core suite of software from a single vendor–but inevitably, they also have a number of other vendors’ tools that fill critical gaps or provide what they consider superior niche solutions. Many oil and gas companies have special widgets and proprietary techniques they have developed in-house, which represent unique differentiators from their peers.

Integrating these disparate multivendor technical applications and the proprietary software “add-ons” within a common, interoperable workflow can drive significant value creation for upstream oil and gas companies. The million-dollar question is, “How?”

FIGURE 1

Importance of Selected IT Challenges To Upstream Industry

The mix of software technologies differs from one company to the next, while relentless innovation and competition ensure this mix will continue to change. But the challenge all this technological heterogeneity presents the upstream industry is both common and widespread. In fact, a survey conducted by Welling & Company found that integrating data and applications across exploration, drilling and production processes was the single most important information technology-related challenge facing the upstream industry (Figure 1). In addition, Welling & Company’s survey found that 92 percent of majors, 89 percent of large independents, 88 percent of medium and small independents, and 89 percent of national oil companies agreed that software suppliers needed to invest more time in integrating their products with other solutions.

In short, it has proven extremely difficult for upstream organizations to connect multivendor tools into the truly unique exploration and production workflows each company would prefer. No one wants to be held hostage to a single vendor’s technology. It is risky for an operating company to put all its proverbial eggs in one basket, and no software vendor covers the entire waterfront. Instead, upstream organizations would like to create best-of-breed workflows that reflect their particular markets, business strategies and areas of expertise. Why is this so difficult?

Breaching the walls between vendors typically requires an internal information technology department or external consultancy to build one-off, hard-wired connections between multiple systems–custom configurations that prove time-consuming and expensive to construct and maintain. A single custom connection between two data stores or between a database and application actually requires two links: one to get data from A to B, and another to get data from B to A.

The number of custom hardwired links required to connect data stores and applications increases dramatically over time. Connecting three systems requires six custom links; connecting five means 20 links, and so on. The “solution” quickly becomes exponentially harder to maintain, giving oil and gas company IT managers heart attacks when vendors decide to change their data models. Updating all these connections to accommodate new applications or new versions of existing data stores is overwhelming, and ultimately unsustainable.

Merging Disparate Data Sets

“Getting the data” is not all that matters, either. Different divisions, geographic areas, acquisition companies, vintages of data, database formats and software tools attach diverse units of measure and utilize different coordinate reference systems (CRS) to locate those data in 3-D space. Merging disparate data sets for a single exploration, drilling and production project (a common practice) can create discontinuities so dramatic that, at times, the drill bit could miss the target. Imagine trying to drill a deepwater relief well in the Gulf of Mexico using a different CRS than the one used to drill the original hole. Getting the location right is the essence of the workflow.

Many oil and gas professionals, asset managers and IT departments continue to seek consistent and sustainable ways to build their own workflows out of their favorite commercial technologies and in-house tools. This would enable them to leverage their unique technical strengths to open doors to increasingly limited global opportunities. They also would like the ability–or agility–to revise their core workflows by swapping existing tools for more advanced or appropriate technologies, regardless of the vendor, without spending a fortune, wasting months or years rebuilding all the connections, or otherwise disrupting their businesses.

What would it take to make this dream come true? What would an optimal solution for multivendor workflow integration look like?

Multivendor Integration

If one was interested only in bridging multiple upstream technical disciplines more efficiently, the obvious solution would be to adopt one of the major software vendors’ next-generation infrastructures, such as Schlumberger’s Ocean/Seabed™, Landmark’s DecisionSpace™, or Paradigm’s Epos™, each of which also provides third-party interoperability through a software development kit. Yet, single-vendor, multidiscipline solutions cannot voluntarily integrate with competitors’ software products.

If, however, one was interested in bridging multiple software vendors, the most practical alternative would be some form of industry-specific, vendor-neutral middleware that could act as a mediator, or switchboard, between disparate commercial upstream applications and data stores.

FIGURE 2

Middleware Data Exchange Standards

Middleware is neither an application nor a database. Instead, it is a layer of consistent data exchange protocols or standards that sits on a server in the “middle,” facilitating communication among tools from many vendors (Figure 2). By mapping data from diverse data stores to a common data model, a vendor-neutral middleware system would enable applications from various suppliers to access and share information even from their competitors’ native data repositories–without having to move or copy the data.

Middleware also should provide tools that enable clean migration and synchronization of data from one data store to another, if desired, consistently transforming different units and coordinate reference systems on the fly. Such a middleware standard would eliminate the oil and gas technical professional’s pain in figuring out where data are located or how they are formatted. No software tool would have to be custom configured to read multiple data formats; each database and each application would require only a single connection or plug-in to the middleware layer, which would automatically manage all cross-vendor interactions.

Middleware would effectively insulate both the user and the IT or data management team from frequent version changes in databases and applications that break proprietary connections. As such, oil and gas companies could pick and choose the multivendor components they want, or string together the technologies they already have in-house into fit-for-purpose workflows, much faster and at a far lower total cost of ownership. For many independents, the best approach is cherry picking the highest-value applications from multiple software vendors and then finding ways to move data in and out of those workflows. A vendor-neutral middleware standard should provide roughly the same level of integration among vendors that a single vendor provides among multiple products of its own.

Application Interoperability

In addition, an optimal middleware solution would enable two or more applications to act at least somewhat like a single, more comprehensive application by sharing certain actions and events. The term for such interaction, normally found only in single-vendor solutions, is “application interoperability.” For example, cursor tracking would allow exploration and production professionals to look at the same x, y and z coordinates location in different types of data–say, for instance, a cross-section of well logs and a 3-D seismic cube.

Another example would be sharing “data events,” enabling users to look at the same data in different types of analyses or interpretation applications from different vendors. In this case, application adapters connected to the middleware layer would “broadcast” a key datum from one application to the other, without requiring the user to laboriously locate and manually select that same data within each application. This would further streamline fit-for-purpose, multivendor workflows while providing geoscientists a bigger, more nuanced picture of the subsurface.

Another requirement of such a middleware solution would be an open software development kit that would enable any software developer in the oil and gas industry to build a single, standard adaptor to plug its technology into a common integration infrastructure.

If a vendor-neutral solution like this did not already exist, it would be essential for someone (ideally a cross-industry consortium) to develop one. Fortunately, one does exist, as do connectors to more than a dozen leading industry data stores and adaptors for more than 45 exploration and production applications. They have been developed over the past decade by dozens of industry partners, including oil and gas companies.

FIGURE 3

Seismic Acquisition Management System

Many independents have grown rapidly through mergers and acquisitions, ending with diverse technology throughout multiple divisions around the world. Barely able to keep pace with exploration and drilling activities, they struggle with how to manage data efficiently across the enterprise.

For example, one independent with global operations lacked a consolidated view of its widely scattered seismic data. New projects took too long to load manually, data quality was questionable, untracked data were sometimes repurchased, interpretation results were not captured consistently, and divestitures required excessive time and effort. To gain control of its data assets and deliver more value to geoscientists on the front lines, the company engaged Fugro Data Solutions to implement its Trango™ enterprise data management solution (Figure 3).

Leveraging OpenSpirit’s vendor-neutral integration framework and connectors to existing project data stores, Trango provided this independent operator with a quality-controlled master metadata repository with direct links to project data and interpretation applications, regardless of their physical location. Now all available information could be displayed visually in a standard map view. Project results are returned to the corporate repository. Data managers create and maintain relevant metadata, compare new data with existing data to prevent duplication, and ensure both data quality and currency.

Coexistence Strategy

Many independent operators active in unconventional plays depend on SMT’s KINGDOM™ suite of interpretation applications. To ensure that its software would work and play well with others, SMT adopted a multivendor “coexistence” strategy based on vendor-neutral OpenSpirit technology (Figure 4). Many of its customers used Landmark’s OpenWorks™ as their primary database. Others wanted to use KINGDOM seismic and geological interpretation in an integrated workflow with Schlumberger’s Petrel™ modeling software, with upscaling to Eclipse™ for reservoir simulation. To enable cross-vendor data connectivity and application interoperability without reinventing the wheel, SMT took a three-pronged approach.

FIGURE 4

Interpretation Software with Vendor-Neutral ‘Coexistence’ Connectivity

First, the company upgraded a KINGDOM data connector to link with competitors’ native repositories through OpenSpirit. Second, OpenSpirit CopyManager technology was embedded directly in SMT’s new data management system, to enable automated data transfer among multiple, large-scale projects, while transforming coordinates and units on the fly. Third, the company began developing an application adaptor to enable users to interoperate seamlessly with other vendor’s software from directly within the KINGDOM user interface.

Users of ESRI’s GIS™ software also can share events between applications and gain access to the enterprise geodata base using an OpenSpirit data connector. The ultimate payoff for independents is that multivendor connectivity is now part of the end user’s workflow, not a separate data management function, no matter how elegant. Interpreters working in KINGDOM can share data dynamically with other applications using OpenSpirit under the hood in a seamless, user-driven workflow. They do not have to break their train of thought, get out of their software, and use a different tool to import and export data.

Apart from ASCII file transfers or hardwired point-to-point integration, the most consistent and sustainable means for energy companies to build their own cross-vendor workflows is to implement a vendor-neutral middleware platform with industry standard database connectors and application adapters. Not only are such technologies already available, more name brand and niche technology providers are connecting this way.

Why? As Herb Yuan, former manager of upstream information technology for Shell E&P, explains: “Oil companies today are taking a more strategic approach, asking themselves, ‘How can we integrate all of our applications, and not just one or two?’”