Introduction

• POSC has received over 25 responses. Many, but not all, followed the questionnaire.
• The responses came from members and non-members, from all segments of the industry.
• There were responses from a seven of the ten organizations that have directors on the POSC Board.
• The results are presented in two ways:
1. The 27 suggestions made in the responses are identified along with consensus views of the active team members for each one.
2. The tally of responses to the questions on the questionnaire are presented.
• The original responses are filed at POSC. The content of the responses has been summarized here. Since responses are being treated as confidential, numbers were assigned to each response. These appear in brackets with the summarized comments.
• If any comments presented here are not clear or do not properly represent the intent of the response, please contact Alan Doniger <Doniger@POSC.org> for clarification.
• POSC expresses it appreciation to all those who participated in this important component of our open process. These comments will be seriously taken into consideration in planning and executing the next stage of this work effort.

RFC Suggestions

Section 2. Problem Statement.

2. We should include performance as an integral part of the problem statement.
- Mixed replies. Many tried to distinguish between the primary importance of the content-
related requirements and the need to allow / support (if not encourage) good performance.
Some noted the difficulty and/or the need to quantify performance targets.

27. We should clarify further the distinction between application integration and data integration.
- Mostly NO OPINION, although adding these terms to the glossary was proposed and sounds
like a good idea.

Section 3. Interoperability Requirements

7. We should consider the requirements for data reformatting as an integral part of this work
effort.
- Strong NO.

Section 4. Business Objects as the Key to Interoperability

4. We should require a layer of data objects close to the POSC/CAESAR product model to be
used by higher level object implementations over POSC/CAESAR repositories / warehouses.
- Mixed replies that generally follow the pattern for #3 although more investigation is needed to
clarify this idea. I believe that the POSC/CAESAR community is interested in pursuing this. I
propose to ask them to conduct workshops on this and then prepare a detailed proposal.

6. We should clarify that the proposal to organize business object specifications around the E&P
Domain concept (1) does not take anything away from the need for inter-domain
interoperability through shared use of an asset life cycle data model (Epicentre) and (POSC)
data stores, and (2) does not take anything away from the need to drive business object
definition from use cases related to E&P business processes. Therefore, a focus on the
combination of inter-domain (life cycle), domain, and use case requirements must be
maintained.
- Strong YES.

8. We should clarify that project data stores can be (or should be) asset-working data stores
with full (potential) life cycle coverage.
- Strong YES, at least to "can be".

9. We should provide another example of transient data and objects in use.
- Moderate YES. There is support for more examples in the upcoming RFT.

10. We should require mappings for each relevant object behavior rather than each distinct
object behavior.
- Mixes replies. I believe that the distinction between ‘relevant’ and ‘distinct’ was not
understood. The comments emphasize that the mappings should define the interface
completely in any case.

11. We should apply similar requirements for mapping between objects and other data models as
for those between objects and Epicentre.
- Mixes replies. For the most part, the Yes’s pointed out that mapping with other data models
should be as comprehensive as those with Epicentre, and the No’s pointed out that it is not
POSC’s (primary) responsibility to define mappings with other data models. Both contentions
appear to be true.

12. We should confirm that the use of Microsoft technology will not be precluded.
- Strong YES.

13. We should confirm that for object implementations over POSC data stores to be compliant,
DAE and Epicentre must be used.
- Strong YES. There was one negative reply, which argued (correctly) that DAE use does not
bear on the compliance of an application using business objects, because the use of DAE is
hidden within the business objects implementations.

14. We should ensure that business objects are defined at a high-enough level so that
applications can use them easily.
- Strong YES. One made an interesting observation by turning the point around saying that
applications should be (re) designed so they can use business objects easily.
-
15. We should prepare a more complete update example of an object / Epicentre mapping using
EXPRESS-X.
- Strong YES. One reply cautioned not to let an example prejudice the RFT search for good
business object definitions.

5. Section 5. Proposed Process

17. We should conduct two separate evaluation processes on the two RFT's with two evaluation
teams.
- Mixed replies. The YES replies recognize the different skills needed to evaluate each RFT.
The NO replies caution that the business object definitions must integrate well with the
architectural features and vice versa. Both points are valid. The plan is to have a single team
with two skills-based sub-teams that will operate separately most of the time but coordinate
as needed to ensure overall consistency.

18. We should abandon the Subsurface Interpretation Domain Object Model and Business
Objects RFT in favor of a POSC work team approach.
- Strong NO. One reply did promote a work team approach as being superior to an RFT
approach. This contrary point of view can best be taken into account by issuing the RFT and
then calling for a workshop of likely submitters to confirm the best way to go forward.

19. We should consider a licensing arrangement for the use of POSC-specified business objects.
- Strong NO.

20. We should initiate a Seismic Acquisition and Processing Domain Object Model and Business
Object RFT within the next 3 months.
- Strong NO OPINION. Those interested in promoting this or any other domain to be
addressed in a near-term RFT should gather together a group of interested participants and
approach POSC with such a proposal. Until the first round of RFT’s has been completed
successfully, I am not in favor of issuing additional RFT’s unless there is significant member
interest in doing so.

21. We should include guidelines (and examples) for combining business objects into virtual
applications (Level 4) in the RFT's.
- Moderate YES.

22. We should abandon the Architecture RFT in favor of a POSC work team approach.
- Strong NO.

23. We should instruct POSC to develop and distribute business object definitions and sample
implementations (when these are not forthcoming from the industry).
- Mixed replies. The Yes’s point out that this would result in a faster process and that the
POSC staff would gain valuable hands-on experience. The No’s point out that industry
interest is essential and for POSC to do this may inhibit such interest or mask the lack of it. I
believe that some way should be found for POSC to obtain the hands-on experience without
formally establishing POSC as the business object definer of last resort.

24. We should clarify that business objects submitted for registration will go through a
compliance verification process, including compatibility with the architecture and semantic
equivalence with Epicentre.
- Strong YES.

25. We should clarify that the first RFT's are the beginning of a series of RFT's / collaborative
work team efforts that will progressively reach higher levels of interoperability and more
complete coverage of the E&P life cycle.
- Strong YES. One reply cautioned that this concept should not be taken so far as to lower
expectations of the usefulness of near-term deliverables and unnecessarily lengthen the
overall process.

26. We should ensure that adequate POSC resources are allocated to this work commensurate
with the response to the RFC that this work is at least as important as other areas.
- Strong YES.

Questionnaire Replies

Section 2. Problem Statement

• [14] Data administration is a greater concern for us than interoperability or the use of POSC specifications.
• [13] Consider the need for interoperability between asset team members, e.g. annotation, versioning, authorization, work flow, etc.
• [10] Use Epicentre to help define domain object models. Use Epicentre as the fundamental way to ensure overall interoperability.
• [7] Performance must be part of the problem statement.
• [6] The asset manager is the primary stakeholder with an interest in interoperability. We believe that the goal of a common logical data model is sound and realizable.
• [21] From our point of view, business objects defined with respect to the POSC/CAESAR product model can make it easier to understand and easier to implement. We agree that business objects should be used to achieve integration and interoperability while work continues on application integration and data integration through a common data model.
• [3] Common data model use promotes interoperability. It does not enforce interoperability.
• [9] The RFC accurately describes the problems that our customer base has.

Section 3. Interoperability Requirements

C. Please rank (from 1 = the most important through 6 = the least important) the Levels of Interoperability defined in Section 3 of the RFC in terms of importance to be available within the next 2 to 3 years. The scores presented below are the number of responses that chose a Level as the "most important" to be available within the next 2 to 3 years, i.e. Level 3 was the most popular "most important" target level.

__1__ Level 0 (via same data store access)

__2__ Level 1 (standardized data objects across multiple data stores)

__3__ Level 2 (+ change notification)

__5__ Level 3 (+ shared process / presentation objects)

__1__ Level 4 (+ system integrator built virtual applications)

_____ Level 5 (+ end-user built virtual applications)

D. Comments on Section 3.

• [15] Technology for Level 1 is currently immature.
• [28] Concentrate on defining business objects. Use mainstream object technology.
• [14] Asset data stores using Epicentre are our focus.
• [13] Don't focus too closely on old application needs as opposed to end-user, business process needs.
• [10] Level 0 corresponds to the use of a shared physical data model, whereas Level 1 corresponds to the use of a shared logical data model.
• [7] Reformatting should be recognized as an important subject and addressed as an integral part of this work.
• [21] We would prefer to have seen the requirements listed separately from the solutions or levels. For us, the goal is to enable integration of data and applications using interoperating objects.
• [20] I would like to focus on business object definition, i.e. behavior/methods, interfaces, and presentation. I do not understand the levels as presented.
• [9] Level 0 is the current situation. Level 1 is vitally important and is a major step towards true interoperability.
• [17] Unified data access is not a bottleneck for interoperability. Separate shared process (higher priority) from presentation objects (lower priority).

Section 4. Business Objects as a Solution Approach

• [14] The RFC explains object technology well but it does not explain why object technology is the best solution to this set of problems.
• [3] Epicentre should be the reference model for mapping business objects with priority given to object identification and encapsulation.

• [23] Visualization is not a responsibility of business objects.

• [20] Focus on business processes as a context.

• [10] Normalizing a domain requires ensuring suitability of the domain's business objects for applications in that domain. Cross-domain interoperability is more important than intra-domain interoperability.
• [3] We propose that business objects be defined from use cases / business scenarios. These normally cross multiple domains. Do not focus on domain-specific business objects so as to recreate silos of computing.

• [13] There is work to be done to validate that domains are proper clusters of related business activities, e.g. sharing an earth model.

• [3] Define semantic equivalence on an overall basis, i.e. without reference to "each business object behavior."

• [14] Our emphasis on asset data stores suggests that corporate and project data stores should have the same data model.
• [17] End-users must have read-only access to corporate data. Business objects are relevant in this context, e.g. with end-user application building tools.

• [14] Each asset (project) should have a full life-cycle data model even it it contains a subset of data.

• [10] A data change made by a compliant application can not be seen by a legacy application. The best solution to achieve interoperability is to wrap the legacy application with a business object.

• [28] Provide another example
• [20] Note that what is transient data in one usage may be persistent in another.

• [20] Use the concept of business process between domain and business object.

• [14] Focus more on interoperability between domains.
• [10] The definition of domain remains fuzzy.
• [17] UML is a good candidate for domain model definition.

• [3] Refer to the need for mapping for each relevant rather than each distinct business object behavior.

• [3] The same or similar requirements must apply when mapping to other data models as when mapping to Epicentre.

• [14] Require mappings between business object internal data models and Epicentre. This is the basis for the business object functionality.

• [28] Infrastructure specifications should come from the industry. (We agree to make maximum use of generic IT infrastructure specifications. Specifications for application and business object services may be unique to E&P or may be refinements of generic specifications.)
• [13] This will be more valuable over the medium term than seeking a single relational projection of Epicentre.
• [10] All levels can not be achieved today for lack of the needed technology.

• [13] E&P users must help define business architecture.

• [13] Multiple, competing implementations are needed.
• [13] Do not prevent implementation using Microsoft technology.
• [10] Use OMG specifications where they exist and apply.

• [14] Work processes often span domains, while a domain covers several work processes.
• [10] The concept of domain is fuzzy.
• [3] Emphasize inter-domain rather than intra-domain dependencies. Focus on work-process orientation more than on domain-specific orientation.

    F. Comments on Section 4. 
    (Can you offer an alternative solution approach? Please explain.)

• [20] Very useful to define standardized business objects between applications and the life-cycle logical data model as an abstraction layer.
• [20] Reuse what emerges from OMG and other standards efforts.
• [20] Defining business objects will highlight weak points in Epicentre, such as inconsistent use of high-level concepts, which should be addressed.
• [20] Define data objects close to Epicentre to avoid proliferation.
• [20] Clarify POSC's position on the use of business objects not mapped to Epicentre. (The RFC proposes that business objects specified by POSC (or registered by POSC) must have Epicentre mappings.)
• [20] Separate the issue of using business objects to achieve interoperability from the issue of how (of whether) business objects are linked to data stores.
• [13] An alternative solution approach? No.
• [12] Business object implementations over POSC data stores should require the use of Epicentre and DAE to be fully compliant.
• [7] Defining meaningful methods is the most difficult aspect of this work. Good use cases and examples are needed.
• [6] Business object interfaces should be defined at a high enough level so that applications can easily use them. Doing this will accelerate the use of Epicentre in oil companies. We applaud the statement that business object internal data models must have acceptable Epicentre mappings and the recommendation to use EXPRESS-X to define them. We would add that both Epicentre and DAE should be used for business object implementation over POSC data stores.
• [10] Interoperability between domains will be achieved through shared use of an integrated logical data model, i.e. Epicentre. To enhance business object implementation over POSC data stores, inter-domain interoperability, and interoperability among non-compliant business objects, a layer of Epicentre objects can be specified.
• [10] It would be useful to see a more complete example of a write mapping using EXPRESS-X than the one presented in the RFC to help validate the feasibility of this approach to defining business object / Epicentre mappings. It is important to pursue discussion on mapping techniques during future workshops.

Section 5. Proposed Process

• [14] Base domain models on Epicentre to facilitate interoperability between domains.

• [5] The evaluation team should consider asking for a second round of submissions (as OMG's procedure does) if the team believes that major changes to the initial submissions are required.
• [10] Two separate teams would be more efficient.
• [3] We recommend collaboration on defining business object content and an RFT approach for defining the architecture.

• [14] Take submissions in all domains. It is valuable to validate and register business objects early on even if they are not part of the eventual domain model specifications.
• [13] POSC should consider a licensing approach.

• [14] POSC facilitation and coordination.
• [13] Web-resident.
• [3] Incremental deployment.
G5. E&P Domain Object Model and Business Objects Change Management Procedure

If successfully implemented, can this procedure contribute positively to your organization?
Yes __9_ No _____

State a key characteristic that this procedure needs to be successful:

• [13] Extensibility, cross-domain consistency, upward compatibility.
• [3] Address cross-domain dependencies, stability, and backward compatibility.
G6. E&P Domain Object Model Extension Registration and Sharing Procedure

If successfully implemented, can this procedure contribute positively to your organization?


Yes __9_ No _____

State a key characteristic that this procedure needs to be successful:

• [13] A consistent business architecture.
• [3] Address cross-domain dependencies, stability, and backward compatibility.

• [17] This must happen within the next three months.

• [14] Consider delegating this as a task for POSC/CAESAR.

H. Comments on Section 5.

• [13] What do these processes mean for POSC in the medium term?
• [5] The timing of RFT's for additional domain object models should depend on the presence of a critical mass of willing participants to define and implement within a given domain.
• [12] The RFT's should state guidelines for combining business objects into virtual applications (reference level 4 interoperability) and should include examples.
• [7] An RFT process is not appropriate to develop an architecture without a much more detailed problem statement than is currently present. A work team approach may be more fruitful. The scope of the subsurface interpretation domain must be defined more precisely before the RFT is issued.
• [6] POSC should also develop and distribute for comments business object definitions (where members have not provided them) and sample implementations.
• [3] We continue to emphasize the criticality of cross-domain orientation.
• [10] There must be a definition of compliance for business objects privately defined by application developers (or others) but not specified by POSC as part of a formal domain model specification. This would include compatibility with the POSC architecture and semantic equivalence with Epicentre.
• [10] The Architecture RFT is likely to be the beginning of an iterative process of RFT's and collaborative work group activities reaching progressively higher levels of interoperability.

Summary

• [14] No. Data management is most important.
• [13] More important. POSC should outsource the old work and move ahead.
• [5] More important. This work is key to engaging application developers and realizing the original goal for POSC of application interoperability.
• [6] More important. This is the most important area for POSC to focus on in the next two years.

• [15] The distinction between application integration and data integration is not made clear in the RFC.
• [13] Plus need for business architecture and need to enable Microsoft technology implementations.

• [28] Industry is moving towards business objects. POSC should supply standardized business objects.
• [13] Target full E&P coverage in ten years.
• [12] It will take considerably longer than three years to achieve full coverage.
• [10] The objectives are good, but the proposed processes can be improved.

• [19] Agree with the problem statement and the proposed solution. Concentrate on the long-lived, stable content when defining business objects.
• [15] Support the initiative. Will contribute to the work effort. Standardizing a basic set of business objects (content and interface) is critical to achieve interoperability. However, reaching standardizing architecture and shared services is ambitious for the near term.
• [28] An encouraging initiative. Business objects and plug-and-play applications is where industry is going. Use OMG's work on infrastructure.
• [14] A very important initiative.
• [13] A timely initiative that deserves and needs POSC Board support, i.e. resources.
• [5] Our operating units support this initiative. Skilled POSC resources should be allocated to drive this initiative forward. Consultants with appropriate expertise should be sought. This initiative is a challenge which requires a broader range of member contacts than POSC has had in the past.
• [7] Insufficient attention is paid to process and presentation objects. The business model for achieving commercial use of the results of this work should be defined.
• [18] We agree that standardized business objects must be defined.
• [6] We fundamentally support these proposals.
• [21] We strongly advise POSC to continue this effort.
• [3] It is important to follow a use-case driven approach to defining business objects. We recommend a collaborative approach to defining business object content as opposed to an RFT approach.
• [8] Adoption and use of business objects will be vital to timely and efficient data management.
• [23] This initiative will ensure focus on the key end-user interoperability objectives of POSC. We strongly encourage POSC to continue this initiative.
• [16] The central issue is how E&P applications can best be constructed in a heterogeneous environment which will evolve in an unpredictable manner. We strongly subscribe to POSC's intent to address this in an incremental manner. We regard interoperability and business objects as extremely important issues.
• [17] We strongly believe that this work will ensure interoperability. Work and support for Epicentre must carry on in parallel to this work.

Copyright © 1994-1997 Petrotechnical Open Software Corporation. All rights reserved.
POSC ® and the POSC Logo are registered trademarks of Petrotechnical Open Software Corporation.