OGC-IP Concept Development Policies and Procedures
Open Geospatial Consortium Inc.
Date: 20051122
Reference number of this OGC document: OGC 05128
Version: 0.1
Category: OGC Policies and Procedures
Editor: George Percivall
OGC Interoperability Program
Concept Development Policies and Procedures
Copyright © Open Geospatial Consortium (2005)
Warning
This document is a draft for OGC Member review.
OGC Document Number 05-128
Concept Development Policies and Procedures
05-128
Table of Contents
1 Introduction.....................................................................................................1
2 Reference Documents....................................................................................1
3 Concept Development....................................................................................1
4 Concept Development Policies.....................................................................3
Annex: Architecture Development......................................................................4
Concept Development Policies and Procedures
1 Revision history
Date
version
22 November 0.1
2005
Editor
George Percivall
Primary
clauses
modified
All
Description
Initial Version
i
05-128
Concept Development Policies and Procedures
05-128
1 Introduction
This document defines the policies and procedures for the conduct of an Open Geospatial Consortium
(OGC) Concept Development Initiative. The main purpose of a Concept Development Initiative is to
define a subsequent Interoperability Initiative, e.g., Testbed, Experiment, Pilot, or OGC Network.
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.
Concept Development is an optional pre-cursor to any other Interoperability Initiative and so is defined in
this separate document.
Concept Development initiatives are governed by policies and procedures in “The OGC Interoperability
Program”.
2 Reference 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 Procedures
OGC Reference Model.
OGC Adopted Technical Baseline.
The OGC Interoperability Program
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems
3 Concept Development
Typically, a Concept Development focuses on the development of a Request for Technology (RFT) and the
collection and collation of the RFT responses. These two actions are key elements to the Concept
Development task and most likely will be used through several initiatives. Information gained as a result of
the execution of these activities can be used to determine the technical viability of a prospective test bed. A
Request for Technology is outreach from the Interoperability Program to Industry. It has the following
goals:
To document in the form of an explicit request to industry a set of interoperability requirements for
a given problem domain;
To obtain from industry technical architectural and technology information to the Interoperability
Program for use in the development of a refined set of requirements, use cases, and technical
architecture for a test bed.
Figure 1 shows the steps of a Concept Development Initiative. The goal for organizations submitting an
RFT response is to suggest possible approaches and technologies relevant to solving the stated
interoperability problem(s). These responses are based on their expertise and experience to the relevant set
of issues solicited by the RFT. These documents are intended only for review by members of the OGC IP
Team and are owned by the individual RFT responders. These responses may contain Technical
Architecture concepts and RFT Responder-specific technology information. While the goal is to obtain key
1
Concept Development Policies and Procedures
05-128
technology approaches from industry, RFT responders should not include proprietary information about
their technology.
Figure 1 Concept Development Initiative
The actual steps for developing the RFT document are as follows. Concept development begins when one
or more OGC members determine that there is an interoperability issue to be solved. At this point, the
potential initiative Sponsors and IP Team work together to document and calibrate the Sponsors’
interoperability requirements for a given problem domain. IP Team evaluates these requirements within the
context of the existing OpenGIS Adopted Technical Baseline to determine how these requirements fit (or
not) into the existing OGC technical baseline. Once this evaluation is done, the sponsors and IP Team will
decide if an RFC should be released. If the decision is “Yes”, then the IP Team will develop a Request for
Technology that includes an architectural concept that addresses the potential Sponsors’ requirements and
harmonization with the existing OGC technical baseline.
Once completed and reviewed by the potential sponsors as well as IP Team, The RFT is then released to the
industry for consideration. The intention is that Industry (i.e., individual companies, universities, and
organizations that work within the geospatial market) will review their technology base, best practices,
research and development, and design ideas. From this review they may respond to the RFT with
recommended technological approaches for the OGC to consider through the test bed. Any RFC responses
are submitted to the OGC. The IP team will then review the responses received. Based on their review,
they will provide the sponsors with a feasibility report which documents the 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. On receipt of the feasibility study the Sponsors then are in a position to make a
decision on how best to proceed: whether to fund the initiative or to reconsider the requirements they
submitted and go through the process again.
2
Concept Development Policies and Procedures
4 Concept Development Policies
Policies defined the OGC Document “The OGC Interoperability Program” apply to all Testbeds.
This section contains additional policies that apply specifically to Testbeds: TBD.
3
05-128
Concept Development Policies and Procedures
05-128
Annex: Architecture Development
Future versions of the Concept Development Policies and Procedures will explicitly address the
coordination of the OGC Reference Model with the Concept Development Process. OGC relies on
standards developed by other organizations that are relevant to the development of OGC specific activities.
Two standards relevant to the OGC Reference Model and the OGC Interoperability Program are:
4.1
ISO/IEC 10746, Information technology — Open Distributed Processing — Reference model
(RM-ODP).
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems
Purpose of Concept Development (IEEE 1471 Excerpt)
A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to,
that system. Concerns are those interests which pertain to the system’s development, its operation or any
other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system
considerations such as performance, reliability, security, distribution, and evolvability.
A system exists to fulfill one or more missions in its environment. A mission is a use or operation for
which a system is intended by one or more stakeholders to meet some set of objectives.
Every system has an architecture, in the terms of this recommended practice. An architecture can be
recorded by an architectural description (see Figure 1). This recommended practice distinguishes the
architecture of a system, which is conceptual, from particular descriptions of that architecture, which are
concrete products or artifacts. Architectural descriptions (ADs) are the subject of this recommended
practice.
In the conceptual framework of this recommended practice, an architectural description is organized into
one or more constituents called (architectural) views . Each view addresses one or more of the concerns of
the system stakeholders. The term view is used to refer to the expression of a system’s architecture with
respect to a particular viewpoint.
Other information, not contained in any constituent view, may appear in an AD , as a result of an
organization’s documentation practices. Examples of such information are the system overview, the system
context, the system stakeholders and their key concerns, and the architectural rationale.
A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a
view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or
product types) to be used to describe the view, and any associated modeling methods or analysis techniques
to be applied to these representations of the view. These languages and techniques are used to yield results
relevant to the concerns addressed by the viewpoint. An architectural description selects one or more
viewpoints for use. The selection of viewpoints typically will be based on consideration of the stakeholders
to whom the AD is addressed and their concerns. A viewpoint definition may originate with an AD, or it
may have been defined elsewhere. A viewpoint that is defined elsewhere is referred to in this recommended
practice as a library viewpoint . A view may consist of one or more architectural models . Each such
architectural model is developed using the methods established by its associated architectural viewpoint.
An architectural model may participate in more than one view.
4.2
Definitions from IEEE 1471-2000
acquirer: An organization that procures a system, software product, or software service from a supplier.
(The acquirer could be a buyer, customer, owner, user, or purchaser.)
architect: The person, team, or organization responsible for systems architecture.
4
Concept Development Policies and Procedures
05-128
architecting: The activities of defining, documenting, maintaining, improving, and certifying proper
implementation of an architecture.
architectural description (AD): A collection of products to document an architecture.
architecture: The fundamental organization of a system embodied in its components, their relationships to
each other, and to the environment, and the principles guiding its design and evolution.
life cycle model: A framework containing the processes, activities, and tasks involved in the development,
operation, and maintenance of a software product, which spans the life of the system from the definition of
its requirements to the termination of its use.
system: A collection of components organized to accomplish a specific function or set of functions.
system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns
relative to, a system.
view: A representation of a whole system from the perspective of a related set of concerns.
viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from
which to develop individual views by establishing the purposes and audience for a view and the techniques
for its creation and analysis.
5
Date: 20051122
Reference number of this OGC document: OGC 05128
Version: 0.1
Category: OGC Policies and Procedures
Editor: George Percivall
OGC Interoperability Program
Concept Development Policies and Procedures
Copyright © Open Geospatial Consortium (2005)
Warning
This document is a draft for OGC Member review.
OGC Document Number 05-128
Concept Development Policies and Procedures
05-128
Table of Contents
1 Introduction.....................................................................................................1
2 Reference Documents....................................................................................1
3 Concept Development....................................................................................1
4 Concept Development Policies.....................................................................3
Annex: Architecture Development......................................................................4
Concept Development Policies and Procedures
1 Revision history
Date
version
22 November 0.1
2005
Editor
George Percivall
Primary
clauses
modified
All
Description
Initial Version
i
05-128
Concept Development Policies and Procedures
05-128
1 Introduction
This document defines the policies and procedures for the conduct of an Open Geospatial Consortium
(OGC) Concept Development Initiative. The main purpose of a Concept Development Initiative is to
define a subsequent Interoperability Initiative, e.g., Testbed, Experiment, Pilot, or OGC Network.
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.
Concept Development is an optional pre-cursor to any other Interoperability Initiative and so is defined in
this separate document.
Concept Development initiatives are governed by policies and procedures in “The OGC Interoperability
Program”.
2 Reference 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 Procedures
OGC Reference Model.
OGC Adopted Technical Baseline.
The OGC Interoperability Program
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems
3 Concept Development
Typically, a Concept Development focuses on the development of a Request for Technology (RFT) and the
collection and collation of the RFT responses. These two actions are key elements to the Concept
Development task and most likely will be used through several initiatives. Information gained as a result of
the execution of these activities can be used to determine the technical viability of a prospective test bed. A
Request for Technology is outreach from the Interoperability Program to Industry. It has the following
goals:
To document in the form of an explicit request to industry a set of interoperability requirements for
a given problem domain;
To obtain from industry technical architectural and technology information to the Interoperability
Program for use in the development of a refined set of requirements, use cases, and technical
architecture for a test bed.
Figure 1 shows the steps of a Concept Development Initiative. The goal for organizations submitting an
RFT response is to suggest possible approaches and technologies relevant to solving the stated
interoperability problem(s). These responses are based on their expertise and experience to the relevant set
of issues solicited by the RFT. These documents are intended only for review by members of the OGC IP
Team and are owned by the individual RFT responders. These responses may contain Technical
Architecture concepts and RFT Responder-specific technology information. While the goal is to obtain key
1
Concept Development Policies and Procedures
05-128
technology approaches from industry, RFT responders should not include proprietary information about
their technology.
Figure 1 Concept Development Initiative
The actual steps for developing the RFT document are as follows. Concept development begins when one
or more OGC members determine that there is an interoperability issue to be solved. At this point, the
potential initiative Sponsors and IP Team work together to document and calibrate the Sponsors’
interoperability requirements for a given problem domain. IP Team evaluates these requirements within the
context of the existing OpenGIS Adopted Technical Baseline to determine how these requirements fit (or
not) into the existing OGC technical baseline. Once this evaluation is done, the sponsors and IP Team will
decide if an RFC should be released. If the decision is “Yes”, then the IP Team will develop a Request for
Technology that includes an architectural concept that addresses the potential Sponsors’ requirements and
harmonization with the existing OGC technical baseline.
Once completed and reviewed by the potential sponsors as well as IP Team, The RFT is then released to the
industry for consideration. The intention is that Industry (i.e., individual companies, universities, and
organizations that work within the geospatial market) will review their technology base, best practices,
research and development, and design ideas. From this review they may respond to the RFT with
recommended technological approaches for the OGC to consider through the test bed. Any RFC responses
are submitted to the OGC. The IP team will then review the responses received. Based on their review,
they will provide the sponsors with a feasibility report which documents the 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. On receipt of the feasibility study the Sponsors then are in a position to make a
decision on how best to proceed: whether to fund the initiative or to reconsider the requirements they
submitted and go through the process again.
2
Concept Development Policies and Procedures
4 Concept Development Policies
Policies defined the OGC Document “The OGC Interoperability Program” apply to all Testbeds.
This section contains additional policies that apply specifically to Testbeds: TBD.
3
05-128
Concept Development Policies and Procedures
05-128
Annex: Architecture Development
Future versions of the Concept Development Policies and Procedures will explicitly address the
coordination of the OGC Reference Model with the Concept Development Process. OGC relies on
standards developed by other organizations that are relevant to the development of OGC specific activities.
Two standards relevant to the OGC Reference Model and the OGC Interoperability Program are:
4.1
ISO/IEC 10746, Information technology — Open Distributed Processing — Reference model
(RM-ODP).
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems
Purpose of Concept Development (IEEE 1471 Excerpt)
A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to,
that system. Concerns are those interests which pertain to the system’s development, its operation or any
other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system
considerations such as performance, reliability, security, distribution, and evolvability.
A system exists to fulfill one or more missions in its environment. A mission is a use or operation for
which a system is intended by one or more stakeholders to meet some set of objectives.
Every system has an architecture, in the terms of this recommended practice. An architecture can be
recorded by an architectural description (see Figure 1). This recommended practice distinguishes the
architecture of a system, which is conceptual, from particular descriptions of that architecture, which are
concrete products or artifacts. Architectural descriptions (ADs) are the subject of this recommended
practice.
In the conceptual framework of this recommended practice, an architectural description is organized into
one or more constituents called (architectural) views . Each view addresses one or more of the concerns of
the system stakeholders. The term view is used to refer to the expression of a system’s architecture with
respect to a particular viewpoint.
Other information, not contained in any constituent view, may appear in an AD , as a result of an
organization’s documentation practices. Examples of such information are the system overview, the system
context, the system stakeholders and their key concerns, and the architectural rationale.
A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a
view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or
product types) to be used to describe the view, and any associated modeling methods or analysis techniques
to be applied to these representations of the view. These languages and techniques are used to yield results
relevant to the concerns addressed by the viewpoint. An architectural description selects one or more
viewpoints for use. The selection of viewpoints typically will be based on consideration of the stakeholders
to whom the AD is addressed and their concerns. A viewpoint definition may originate with an AD, or it
may have been defined elsewhere. A viewpoint that is defined elsewhere is referred to in this recommended
practice as a library viewpoint . A view may consist of one or more architectural models . Each such
architectural model is developed using the methods established by its associated architectural viewpoint.
An architectural model may participate in more than one view.
4.2
Definitions from IEEE 1471-2000
acquirer: An organization that procures a system, software product, or software service from a supplier.
(The acquirer could be a buyer, customer, owner, user, or purchaser.)
architect: The person, team, or organization responsible for systems architecture.
4
Concept Development Policies and Procedures
05-128
architecting: The activities of defining, documenting, maintaining, improving, and certifying proper
implementation of an architecture.
architectural description (AD): A collection of products to document an architecture.
architecture: The fundamental organization of a system embodied in its components, their relationships to
each other, and to the environment, and the principles guiding its design and evolution.
life cycle model: A framework containing the processes, activities, and tasks involved in the development,
operation, and maintenance of a software product, which spans the life of the system from the definition of
its requirements to the termination of its use.
system: A collection of components organized to accomplish a specific function or set of functions.
system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns
relative to, a system.
view: A representation of a whole system from the perspective of a related set of concerns.
viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from
which to develop individual views by establishing the purposes and audience for a view and the techniques
for its creation and analysis.
5