OGC Interoperability Pilot Policies and Procedures

Date: 2006­03­20

Reference number of this OGC document: OGC 05­131r1

Version: 1.0 Category: OGC Policies and Procedures Editor: George Percivall

Interoperability Pilot Policies and Procedures

Table of Contents

1

Introduction...1

2

Referenced Documents...1

3

Pilot Phases...1

3.1 Concept Development...2

3.2 Request for Quotation/Call for Participation (RFQ/CFP)...2

3.3 Pilot Team Formation and Kick-off...3

3.4 Pilot Execution...4

4

Execution Phase Tasks...6

4.1 Coordination...6

4.2 Assessment and Analysis...7

4.3 Architecture Development...7

4.4 Initiative Preparation...7

4.5 Specification Development...7

4.6 Component Development...7

4.7 Testing and Integration...7

4.8 Solution Transfer...7

4.9 Demonstration...7

4.10 Documentation...8

4.11 Compliance Testing...8

1 Revision history

Date Version Editor Primary

clauses modified

Description

2005-07-01 0.1 George Percivall N/A Initial Version 2005-12-17 0.2 George Percivall All Edits throughout

2006-03-20 1.0 George Percivall All Slight edits to release the document as approved by the SMAC, e.g., version number, dates, document references, etc.

1 Introduction

This document defines the policies and procedures for the conduct of an Open Geospatial Consortium (OGC) Interoperability Pilot.

Pilots are governed by policies and procedures in “The OGC Interoperability Program”.

2 Referenced Documents

The following documents are referenced in this document. In all cases the latest version of the referenced document will be used.

 OGC Intellectual Property Rights Policy and Procedure http://www.opengeospatial.org/about/? page=ipr

 OGC Reference Model. http://orm.opengeospatial.org/

 OGC Adopted Technical Baseline. http://www.opengeospatial.org/specs/?page=baseline

 The OGC Interoperability Program, OGC Document 05-127-r1, 2005-03-20

3 Pilot Phases

An OGC Pilot is a collaborative effort that applies the OGC Technical Baseline and other (non-OGC) technologies to Sponsor scenarios. In practice, a Pilot is where an OpenGIS specification – or set of OpenGIS specifications – can be “stress tested” and perfected based on real-world application and experience. While some research may be done during a pilot in terms of refining, documenting, and distributing specifications and in terms of developing prototypical software that exercises the refined specification, this research is directed at improving existing specifications rather than in creating new specifications.

The general approach to performing pilots is to go through a four step process (Figure 1). The details of these Tasks will be explained below.

Concept Concept Development Development Task A Task A RFQ/CFP* RFQ/CFP* Development Development Task B Task B Team Formation Team Formation and Kick-of and Kick-of Task C Task C Testbed Testbed Execution Execution Task C Task C

Figure 1 – Pilot Phases

1

3.1 Concept Development

Concept Development is an optional task for a Pilot and so is defined in a separate document.

Concept development begins with the Sponsors and IP Team working together to determine the Sponsors’ requirements. The main result is a feasibility report which documents a response from industry, the probable costs and benefits of given industry recommendations, an appraisal of where the recommendation seems to fit within the overall context of industry practice, and a draft technical architecture for the Sponsors’ consideration.

3.2 Request for Quotation/Call for Participation (RFQ/CFP)

Task B of an IP Pilot is to release a Request for Quote/Call for Participation (RFQ/CFP or simply RFQ) and to receive and evaluate responses to this RFQ back from Industry. The RFQ consists of general statements pertaining to contracts and relationships between potential pilot participants and OGC, general response instructions, Sponsor requirements (refined from the ones used for the RFT by the responses to that RFT), a Work Breakdown Structure (WBS) that details tasks associated with the initiative, the initiative

architecture, a Concept of Operations for the Pilot, a schedule of work for the Pilot, a communications plan for the initiative, and other miscellaneous information that a particular pilot may require. The responses should include the proposing organization’s technical solution, their cost-sharing requests for funding, and their in-kind contributions to the Pilot.

Figure 2 – RFQ/CFP Development and Release

On completion of Task A and the acceptance of the feasibility study results by the potential initiative Sponsors. At this time, the potential sponsors also decide whether to be full sponsors and to provide human, technology, facilities, and/or financial resources to support the new initiative.

Given that the sponsors decide to move ahead with the initiatve, the IP Team will begin to develop the Request for Quote/Call for Participation. This exercise will include developing a budget for the activities required to address the Sponsors’ requirements, a prioritization of those requirements, an architecture that

incorporates the requirements, a work breakdown structure defining the tasks that will achieve meeting the requirements, and a concept of operations for conducting the initiative.

Once a draft RFQ is available, it will be presented to the Sponsors’ for their review and comments. Their comments will be addressed and incorporated by IP Team into the next version of the RFQ. The RFQ will again be presented to the Sponsors and will be either released or go through a second comment iteration. Once the Sponsors’ agree to the release, the RFQ is provided to Industry for response. The intention is that Industry (i.e., individual companies, universities, and governmental organizations within the geospatial industry) will submit proposals that explain the technical contribution they intend to make, how their contribution maps to the requirements and the WBS, the cost-sharing funds they are requesting to offset their engineering costs, and the in-kind contributions they will make to the test bed. These proposals are sent to the OGC and then submitted to the IP Team and the Sponsors.

3.3 Pilot Team Formation and Kick-off

Figure 3 – Pilot Kick­off Preparation Context

On receipt of the proposals, the Sponsors and IP Team perform a review process that includes two Decision Technical Exchange Meetings (Decision TEMs I and II). For all funded initiatives, the Sponsors determine the proposal review criteria. The Sponsors and IP Team use the sponsor defined review criteria and weight those criteria in relation the Sponsors’ objectives and requirements for the initiative.

Standing criteria for every initiative RFP proposal evaluation include the technical merits of the proposal, past performance of the participant within OGC (particularly OGC IP initiatives), adherence in the proposal to the work breakdown structure, and financial considerations (cost-sharing funding requests and in-kind contributions). The Sponsors may direct IP Team to evaluate other criteria that help discriminate amongst the proposing organizations in terms of meeting the Sponsors’ objectives. IP Team will review the proposals in light of the criteria, especially proposals planned technology and architecture approach, and make a recommendation to the Sponsors at Decision TEM I. The Sponsors and IP Team will review the IP Team recommendations in light of the Sponsors’ own evaluations. If questions arise regarding one or more proposals, IP Team will contact the proposing organization to seek clarification. If the sponsors raise other issues, IP Team will seek to resolve them and bring the resolution to the Sponsors. At Decision TEM II, IP Team will make a final funding recommendation to the Sponsors and the Sponsors will decide which

proposing organizations they will fund as well as the actual level of funding. Typically in test beds, a minimum of three proposing organizations will be funded per requirement or work item.

When the Sponsors have made their decisions with regard to participant funding, IP Team will notify the proposing organizations of the outcome of the Decision TEMs. Once the selected participants have been notified, the OGC will begin negotiations with the selected participants. These negotiations will discuss funding, tasks to be performed, in-kind contributions that will be provided by the participant, the nature of the statement of work and the work breakdown. These negotiations will form the basis of an agreed to Statement of Work (SOW) and a contract between OGC and the participant in question. While this process is expected to be iterative as terms of the contract are finalized, the contract is the basis for the relationship between OGC and the participant.

If a selected Participant is not an OGC member, they should begin the membership registration process. Membership will be required before the final Participant contract is signed.

Once the OGC IP Team has decided that negotiations are at a reasonable state of completion, they will complete work on the work package of materials to be provided to the Sponsors and participants at the Kickoff. This will include an updated technical architecture, an initiative schedule, the initiative concept of operations, and the final work breakdown. One goal of the Test Bed kickoff meeting is to obtain consensus agreement of the work package by all stakeholders within the initiative.

Additionally, OGC IP Team will provide templates for statements of work (SOW) to participants. The participants will complete the templates based on the tasks they accepted during the negotiations. Upon completion, the participants will submit their SOWs to OGC. OGC will review the SOWs for accuracy and may iterate with the participants until mutual agreement is achieved. On completion of the SOWs, OGC will develop a contract containing a Profession Services Agreement (PSA) and a statement of Rights of Patent. These contracts will follow OGC membership and other contractual precedents.

3.4 Pilot Execution

The Kick-off marks the beginning of the Execution phase of the initiative. Using the agreed upon work package as the governing documents for the conduct of the initiative, the stakeholders will begin the principal tasks of refining engineering specifications as needed, developing prototypical software

components that exercise the draft specifications, and testing those components and specifications. The key outcome of the initiative is an Interoperability Program Report. In the stages where the IPR is being developed and reviewed it will be typically referenced as a Draft Interoperability Program Report (DIPR).

Figure 4 ­ Pilot Execution 

The participants in conjunction with one another, the Sponsors, and OGC IP Team will begin developing relevant DIPRs pertaining to requirements identified by the Sponsors. One stakeholder representative will act as the lead author for the document, but a group of participants are expected and obligated to support the actual creation and development of the DIPR; this group is referred to as a Work Group. The author may be a participant technical representative, a Sponsor representative (typically technical), or on some rare occasions an IP Team member. The DIPR is iterated until the Work Group believes it to be sound enough for prototypical interoperable software components to be developed or enhanced to test the specification. This act of testing specifications and the prototypical software components exercising them is called a Technology Integration Experiment (TIE). It is anticipated that a TIE will go through some number of iterations before Prototypical Software Components share information interoperably. A TIE is generally understood to minimally include a participant providing a client component and another participant providing a server component working in conjunction to test the implementation of a particular specification.

The primary goal of a pilot from the perspective the sponsors is to implement a prototypical set of software components that exercise the set of OGC specifications and draft specifications for which the Sponsors have requirements in terms of enabling interoperable geospatial technologies within their environment. This prototypical capability will be instantiated in an environment determined by the Sponsors. This environment will form a node on the OGC Network. Therefore, participants will provide their prototypical software components and will conduct TIEs to determine if these components can function in an

interoperable environment. Typically there will be several “software builds” until interoperability in the environment is demonstrated via the TIEs. Various systems may be required by the Sponsors to measure the performance of the system. Once the prototypical system is deemed complete it most likely will be

demonstrated to the Sponsors and any audience they may indicate. The participants will support efforts to install and integrate the system into the Sponsors designated environment. They will provide necessary documentation to support these efforts. The integrated prototypical system most likely will limited compared to a fully operational system that the Sponsors may use in their day-to-day business. However

the prototypical system should exercise a reasonable subset of the functions the Sponsors use in their enterprise.

If, during the course of Pilot Project execution, modifications to an existing OpenGIS specification are found necessary, then a change proposal must be developed that documents the change. This change proposal does not need to be adopted, rather it is intended to serve as documentation of both the change and the requirement that led to the change. The change proposal will be submitted to appropriate Revision Working Group using OGC communications. If a RWG does not exist, then the TC Chair must be notified of the pending change proposals.

4 Execution Phase Tasks

This section describes a flexible framework of standard, repeatable tasks for the execution phase of a pilot. These tasks may be performed by any of the Pilot Team members. The task are adapted as necessary to address the requirements of the specific Pilot. These tasks are executed with a Virtual Team Infrastructure. These tasks are used to define the SOW for in a Participant Agreement.

Figure 5 – Pilot Execution Phase Tasks

4.1 Coordination

Enables overall Pilot coordination between OGC Staff, OGC IP Team, Sponsors, Participants, and other TC/PC Members as required. Initiative Coordination includes the following Subtasks:

 Collaborative Environment - OGC IP Team provides synchronous and asynchronous

collaboration environments for cross organizational, globally distributed, virtual teams working interdependently to execute Initiative Orders

.

Activities under this subtask include reading email and engaging in collaborative discussions such as regular teleconferences.

 Initiative Plan Development – Support development of Project Plans, Project Schedules and Work Breakdown Structures (Work Package). May include Technical and Project Management Approach, Tasks/Schedules, Communications Plans, Resource Plans, Risk and Mitigation Strategies, and definition of the Specification and/or Component Development and Integration Tasks necessary to realize the Technical, Operational and Systems Architectures.

 Management - Services ensuring Initiative Order participants are staying within designated budgets, that the work is progressing according to the agreed schedule, and that the tasks identified in the Statement of Work are executed. Including status reporting.

 Communication – Includes communicating ongoing and planned Initiative and Work Item Status to OGC and other organizations such as ISO. This task does not include IP Business Development functions.

4.2 Assessment and Analysis

This task analyzes and documents an organization’s or domains existing capabilities and assesses requirements for OGC compliant technology. This task can occur as part of any pilot planning process. .

4.3 Architecture Development

This task defines the architectural views for any given Initiative. In the context of the Open GIS

Interoperability Program, there are potentially three–and perhaps more - architectural views for any given effort. These views are the Operational Architecture, Technical Architecture, and System Architecture. Part of the Architecture Development task may be the use of an RFQ/CFP to industry to enable

organizations interested in participating in an Interoperability Initiative to respond with a proposal. This task may also be implemented during Planning Studies.

4.4 Initiative Preparation

This task defines the participant budget (if any) and defines and executes agreements and contracts that outline\ roles and responsibilities of each participant. This task may refine the Work Package.

4.5 Specification Development

This task defines and develops models, schemas, encodings, and interfaces necessary to realize required Architectures. Includes specification Pre-design and Design tasks. This task may also include activities to coordinate ongoing Initiatives with Specification Program activities.

4.6 Component Development

This task develops prototype interoperable commercial software components based on draft candidate implementation specifications or adopted specifications necessary to realize the required Architecture.

4.7 Testing and Integration

This task integrates, documents and tests functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements. Includes Technology Integration Experiments (TIEs).

4.8 Solution Transfer

This task prepares prototypical interoperable components so that they can be assembled at required sites.

4.9 Demonstration

This task defines, develops and deploys functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements.

4.10 Documentation

This Task ensures development and maintenance of the pre-specification, pre-conformant interoperable OpenGIS technologies (including Interoperability Program Reports) and the systems level documentation (example user documentation, etc.) necessary to execute the Initiative. This task may include coordination with OGC Specification Program activities including the Documentation Team.

4.11 Compliance Testing

This Task ensures development of draft compliance test guidelines (at a minimum) and test suites for engineering specifications detailed in Interoperability Program Reports. This task includes coordination with OGC Specification Program activities including the Compliance Testing and Interoperability Evaluation Subcommittee.

5 Pilot Policies

Policies defined in the OGC Document “The OGC Interoperability Program” apply to all Pilots. No additional policies specific to Pilots have been identified.

incorporates the requirements, a work breakdown structure defining the tasks that will achieve meeting the requirements, and a concept of operations for conducting the initiative.

Once a draft RFQ is available, it will be presented to the Sponsors’ for their review and comments. Their comments will be addressed and incorporated by IP Team into the next version of the RFQ. The RFQ will again be presented to the Sponsors and will be either released or go through a second comment iteration. Once the Sponsors’ agree to the release, the RFQ is provided to Industry for response. The intention is that Industry (i.e., individual companies, universities, and governmental organizations within the geospatial industry) will submit proposals that explain the technical contribution they intend to make, how their contribution maps to the requirements and the WBS, the cost-sharing funds they are requesting to offset their engineering costs, and the in-kind contributions they will make to the test bed. These proposals are sent to the OGC and then submitted to the IP Team and the Sponsors.

3.3 Pilot Team Formation and Kick-off

Figure 3 – Pilot Kick­off Preparation Context

On receipt of the proposals, the Sponsors and IP Team perform a review process that includes two Decision Technical Exchange Meetings (Decision TEMs I and II). For all funded initiatives, the Sponsors determine the proposal review criteria. The Sponsors and IP Team use the sponsor defined review criteria and weight those criteria in relation the Sponsors’ objectives and requirements for the initiative.

Standing criteria for every initiative RFP proposal evaluation include the technical merits of the proposal, past performance of the participant within OGC (particularly OGC IP initiatives), adherence in the proposal to the work breakdown structure, and financial considerations (cost-sharing funding requests and in-kind contributions). The Sponsors may direct IP Team to evaluate other criteria that help discriminate amongst the proposing organizations in terms of meeting the Sponsors’ objectives. IP Team will review the proposals in light of the criteria, especially proposals planned technology and architecture approach, and make a recommendation to the Sponsors at Decision TEM I. The Sponsors and IP Team will review the IP Team recommendations in light of the Sponsors’ own evaluations. If questions arise regarding one or more proposals, IP Team will contact the proposing organization to seek clarification. If the sponsors raise other issues, IP Team will seek to resolve them and bring the resolution to the Sponsors. At Decision TEM II, IP Team will make a final funding recommendation to the Sponsors and the Sponsors will decide which

proposing organizations they will fund as well as the actual level of funding. Typically in test beds, a minimum of three proposing organizations will be funded per requirement or work item.

When the Sponsors have made their decisions with regard to participant funding, IP Team will notify the proposing organizations of the outcome of the Decision TEMs. Once the selected participants have been notified, the OGC will begin negotiations with the selected participants. These negotiations will discuss funding, tasks to be performed, in-kind contributions that will be provided by the participant, the nature of the statement of work and the work breakdown. These negotiations will form the basis of an agreed to Statement of Work (SOW) and a contract between OGC and the participant in question. While this process is expected to be iterative as terms of the contract are finalized, the contract is the basis for the relationship between OGC and the participant.

If a selected Participant is not an OGC member, they should begin the membership registration process. Membership will be required before the final Participant contract is signed.

Once the OGC IP Team has decided that negotiations are at a reasonable state of completion, they will complete work on the work package of materials to be provided to the Sponsors and participants at the Kickoff. This will include an updated technical architecture, an initiative schedule, the initiative concept of operations, and the final work breakdown. One goal of the Test Bed kickoff meeting is to obtain consensus agreement of the work package by all stakeholders within the initiative.

Additionally, OGC IP Team will provide templates for statements of work (SOW) to participants. The participants will complete the templates based on the tasks they accepted during the negotiations. Upon completion, the participants will submit their SOWs to OGC. OGC will review the SOWs for accuracy and may iterate with the participants until mutual agreement is achieved. On completion of the SOWs, OGC will develop a contract containing a Profession Services Agreement (PSA) and a statement of Rights of Patent. These contracts will follow OGC membership and other contractual precedents.

3.4 Pilot Execution

The Kick-off marks the beginning of the Execution phase of the initiative. Using the agreed upon work package as the governing documents for the conduct of the initiative, the stakeholders will begin the principal tasks of refining engineering specifications as needed, developing prototypical software

components that exercise the draft specifications, and testing those components and specifications. The key outcome of the initiative is an Interoperability Program Report. In the stages where the IPR is being developed and reviewed it will be typically referenced as a Draft Interoperability Program Report (DIPR).

Figure 4 ­ Pilot Execution 

The participants in conjunction with one another, the Sponsors, and OGC IP Team will begin developing relevant DIPRs pertaining to requirements identified by the Sponsors. One stakeholder representative will act as the lead author for the document, but a group of participants are expected and obligated to support the actual creation and development of the DIPR; this group is referred to as a Work Group. The author may be a participant technical representative, a Sponsor representative (typically technical), or on some rare occasions an IP Team member. The DIPR is iterated until the Work Group believes it to be sound enough for prototypical interoperable software components to be developed or enhanced to test the specification. This act of testing specifications and the prototypical software components exercising them is called a Technology Integration Experiment (TIE). It is anticipated that a TIE will go through some number of iterations before Prototypical Software Components share information interoperably. A TIE is generally understood to minimally include a participant providing a client component and another participant providing a server component working in conjunction to test the implementation of a particular specification.

The primary goal of a pilot from the perspective the sponsors is to implement a prototypical set of software components that exercise the set of OGC specifications and draft specifications for which the Sponsors have requirements in terms of enabling interoperable geospatial technologies within their environment. This prototypical capability will be instantiated in an environment determined by the Sponsors. This environment will form a node on the OGC Network. Therefore, participants will provide their prototypical software components and will conduct TIEs to determine if these components can function in an

interoperable environment. Typically there will be several “software builds” until interoperability in the environment is demonstrated via the TIEs. Various systems may be required by the Sponsors to measure the performance of the system. Once the prototypical system is deemed complete it most likely will be

demonstrated to the Sponsors and any audience they may indicate. The participants will support efforts to install and integrate the system into the Sponsors designated environment. They will provide necessary documentation to support these efforts. The integrated prototypical system most likely will limited compared to a fully operational system that the Sponsors may use in their day-to-day business. However

the prototypical system should exercise a reasonable subset of the functions the Sponsors use in their enterprise.

If, during the course of Pilot Project execution, modifications to an existing OpenGIS specification are found necessary, then a change proposal must be developed that documents the change. This change proposal does not need to be adopted, rather it is intended to serve as documentation of both the change and the requirement that led to the change. The change proposal will be submitted to appropriate Revision Working Group using OGC communications. If a RWG does not exist, then the TC Chair must be notified of the pending change proposals.

4 Execution Phase Tasks

This section describes a flexible framework of standard, repeatable tasks for the execution phase of a pilot. These tasks may be performed by any of the Pilot Team members. The task are adapted as necessary to address the requirements of the specific Pilot. These tasks are executed with a Virtual Team Infrastructure. These tasks are used to define the SOW for in a Participant Agreement.

Figure 5 – Pilot Execution Phase Tasks

4.1 Coordination

Enables overall Pilot coordination between OGC Staff, OGC IP Team, Sponsors, Participants, and other TC/PC Members as required. Initiative Coordination includes the following Subtasks:

 Collaborative Environment - OGC IP Team provides synchronous and asynchronous

collaboration environments for cross organizational, globally distributed, virtual teams working interdependently to execute Initiative Orders

.

Activities under this subtask include reading email and engaging in collaborative discussions such as regular teleconferences.

 Initiative Plan Development – Support development of Project Plans, Project Schedules and Work Breakdown Structures (Work Package). May include Technical and Project Management Approach, Tasks/Schedules, Communications Plans, Resource Plans, Risk and Mitigation Strategies, and definition of the Specification and/or Component Development and Integration Tasks necessary to realize the Technical, Operational and Systems Architectures.

 Management - Services ensuring Initiative Order participants are staying within designated budgets, that the work is progressing according to the agreed schedule, and that the tasks identified in the Statement of Work are executed. Including status reporting.

 Communication – Includes communicating ongoing and planned Initiative and Work Item Status to OGC and other organizations such as ISO. This task does not include IP Business Development functions.

4.2 Assessment and Analysis

This task analyzes and documents an organization’s or domains existing capabilities and assesses requirements for OGC compliant technology. This task can occur as part of any pilot planning process. .

4.3 Architecture Development

This task defines the architectural views for any given Initiative. In the context of the Open GIS

Interoperability Program, there are potentially three–and perhaps more - architectural views for any given effort. These views are the Operational Architecture, Technical Architecture, and System Architecture. Part of the Architecture Development task may be the use of an RFQ/CFP to industry to enable

organizations interested in participating in an Interoperability Initiative to respond with a proposal. This task may also be implemented during Planning Studies.

4.4 Initiative Preparation

This task defines the participant budget (if any) and defines and executes agreements and contracts that outline\ roles and responsibilities of each participant. This task may refine the Work Package.

4.5 Specification Development

This task defines and develops models, schemas, encodings, and interfaces necessary to realize required Architectures. Includes specification Pre-design and Design tasks. This task may also include activities to coordinate ongoing Initiatives with Specification Program activities.

4.6 Component Development

This task develops prototype interoperable commercial software components based on draft candidate implementation specifications or adopted specifications necessary to realize the required Architecture.

4.7 Testing and Integration

This task integrates, documents and tests functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements. Includes Technology Integration Experiments (TIEs).

4.8 Solution Transfer

This task prepares prototypical interoperable components so that they can be assembled at required sites.

4.9 Demonstration

This task defines, develops and deploys functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements.

4.10 Documentation

This Task ensures development and maintenance of the pre-specification, pre-conformant interoperable OpenGIS technologies (including Interoperability Program Reports) and the systems level documentation (example user documentation, etc.) necessary to execute the Initiative. This task may include coordination with OGC Specification Program activities including the Documentation Team.

4.11 Compliance Testing

This Task ensures development of draft compliance test guidelines (at a minimum) and test suites for engineering specifications detailed in Interoperability Program Reports. This task includes coordination with OGC Specification Program activities including the Compliance Testing and Interoperability Evaluation Subcommittee.

5 Pilot Policies

Policies defined in the OGC Document “The OGC Interoperability Program” apply to all Pilots. No additional policies specific to Pilots have been identified.