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.
Table of Contents
1
Introduction...1
2
Reference Documents...1
3
Concept Development...1
4
Concept Development Policies...3
1 Revision history
Date version Editor Primary
clauses modified
Description
22 November
2005 0.1 George Percivall All Initial Version
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 Software-Intensive 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
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.
4 Concept Development Policies
Policies defined the OGC Document “The OGC Interoperability Program” apply to all Testbeds.
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:
ISO/IEC 10746, Information technology — Open Distributed Processing — Reference model (RM-ODP).
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems
4.1 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.
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.
