Anyone involved in building enterprise information systems might reasonably question the feasibility of the Global Earth Observation System of Systems (GEOSS). The scope and complexity are overwhelming: In the highly technical and legacy-heavy domain of Earth observation systems, GEOSS aims to meet information requirements of 80 nations and the European Commission as well as the needs of multiple communities of practice in each of nine vast Societal Benefit Areas (SBAs): Agriculture, Biodiversity, Climate, Disasters, Ecosystems, Energy, Health, Water and Weather. For hundreds of different organizations that provide and/or use geospatial information, GEOSS is supposed to enable comprehensive, coordinated and sustained observation of the Earth and also efficient publication and use of the collected information.
Remarkably, progress has been rapid. Participants in the GEOSS Architecture Implementation Pilot (AIP) have developed and deployed a new development process and they have also deployed working components for the GEOSS Common Infrastructure (GCI) and the broader GEOSS architecture. That is to say, the basic technical foundation of a service-oriented architecture for GEOSS has been established, and it works. The technical foundation has been proven and has undergone continuous improvement in multiple pilot activities based on real-world scenarios and existing national technical resources. And the process for continuous improvement is in place.
Within the Group on Earth Observations (GEO) organization and plan, AIP is a core task (GEO Task AR-09-01b) of the GEO Architecture and Data Committee (ADC). Results of the AIP are transitioned to GEO Task AR-09-01a and affecting the evolution of the GCI.
No system of systems as large as GEOSS could be planned and built in a linear fashion, nor could anyone expect it to be built and finished as an unchanging entity, though the technical foundation’s purpose was stated clearly enough in the GEOSS 10-Year Implementation Plan (2005):
“Û_ GEOSS will depend on data and information providers accepting and implementing a set of interoperability arrangements, including technical specifications for collecting, processing, storing, and disseminating shared data, metadata, and products.” (Section 5.3)
The GEOSS architecture was necessarily designed to evolve so it would meet changing needs and take advantage of rapidly evolving information technologies. The architecture, the delivered systems, and the stakeholders must all co-evolve. Thus the Architecture and Data Committee undertook to develop a special process to facilitate this co-evolution.
The AIP process provides a structure for experimenting with prototypes that are adapted to user needs, while simultaneously capturing, increasing and sharing knowledge about GEOSS. Each phase of AIP involves extensive prototyping, testing, documentation and demonstration of interoperability arrangements. AIP-2, which was completed in October 2009, established “operational, research and technical exemplars” in six scenarios representing four SBAs:
— Health SBA: Air Quality & Health: Smoke Event: AIP-2 participants focused on air quality with a scenario entitled, “Southern California Smoke” which describes how air quality event managers would use data available through GEOSS to predict and analyze the effect of smoke plumes on air.
— Biodiversity SBA: Pika Distribution — GEOSS was used to predict how the distribution of Pika will change with climate change in the Great Basin of North America.
— Biodiversity SBA: Arctic Food Chain — GEOSS was used to assess the impact of climate change on the species of a simple food chain in the Arctic region.
— Biodiversity SBA: Polar Ecosystems — GEOSS was used to identify the extent and degree of vegetation changes in response to climate change in arctic ecosystems, and in particular, the boreal-tundra ecotone.
— Disaster Management SBA: AIP-2 participants used GEOSS components and standard services to supply forecasts, a stream of satellite and in situ observations, and derived maps integrated with local and regional data sets to support all phases of the disaster cycle. The scenario is applied to flooding disasters caused by tropical storms, hurricanes, cyclones, and tsunamis in particular, but can be easily re-cast to cover other disaster types such as earthquakes, wildfires, landslides, volcanoes, tornadoes, and many more.
— Energy SBA: Renewable Energy: AIP-2 participants developed an end-to-end scenario between a data provider on the one hand and a consulting company looking for the best place to site a solar power plant on the other hand. Both benefit from GEOSS as a centralized point of access. The needs of the data providers looking for an efficient dissemination of databases are expressed.
These scenarios provided a structure for extensive prototyping, testing, documentation and demonstration.
As noted in the ÛÏAIP-2 Summary Engineering ReportÛ, the process has been informed by the approach of Leonardo da Vinci:
ÛÏFirst I shall do some experiments before I proceed farther, because my intention is to cite experience first and then with reasoning show why such experience is bound to operate in such a way.Û
The process developed in the AIP is called a ÛÏreusable processÛ because in implementing the GEOSS service oriented architecture the various Societal Benefit Areas (SBAs) will involve many players over time, and those players will benefit from a proven formal process for implementation. Later players will benefit from the experiments and documentation that has gone before. The process begins with a scenario defined by the SBA community and then employs GEOSS resources to make a variety of Earth observation information assets available for researchers and decision makers in that SBA community. The process is now published and available for use by anyone (see AIP-2 engineering reports atåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊ http://www.ogcnetwork.net/AIP2ERs).
AIP Evolutionary Development Process
The AIP task employs an ÛÏevolutionary development processÛ whereby the architecture, the delivered systems, and the stakeholders co-evolve. Stakeholder needs are reassessed with each iteration of the architecture; the architecture is used to guide each system as it moves through development, and appropriate versions are used to evaluate each system on delivery. Architectures developed under this approach emphasize Ââexibility and adaptability. This approach is well suited to software system development in cases where it is impossible to postulate all of the requirements and the system development can proceed iteratively.
Figure 1 shows the steps for a single phase. The main result of the concept development phase is a Call for Participation (CFP) that is released to the GEO community. Organizations that respond to the CFP then gather for a kickoff workshop for the phase that begins the development process. The development phase includes design development, design review and testing activities. A phase of AIP is completed with the delivery of demonstrations, engineering reports, and the transition of new functionality to persistent operations. The AIP evolutionary development process is an application of the process defined and used in the OGC interoperability program. The OGC process has been used and refined in 35 testbeds and pilot initiatives, most notably for the development of the OGC Web Services Standards (OWS) baseline.
Certainties in the GEOSS Technical Architecture
One key certainty in the GEOSS technical architecture is that it is “service-oriented”. This means that network-resident software components interact in a client/server fashion with other network-resident software components. Internet-resident geoprocessing clients send instructions to Web servers, and those servers respond by providing processing services or data.
Another key certainty is that these client/server communications will use interfaces and encodings that implement open, not proprietary, standards. Because GEOSS clients and services implement open standard interfaces, anyone can write software that takes advantage of those clients and services (subject in many cases, of course, to access restrictions). This adheres to the basic paradigm of openness on the World Wide Web: Open standard interfaces such as HTTP and open standard encodings such as HTML enable diverse developers to write software components that reliably interoperate with countless other components on the Web.
As a “system of systems”, GEOSS is composed of contributed Earth Observation systems, ranging from primary data collection systems to systems for the creation and distribution of information products. Although all GEOSS systems continue to operate within their own mandates, GEOSS systems can leverage each other so that the overall GEOSS becomes much more than the sum of its component systems. This synergy develops as each contributor supports common arrangements designed to make shared observations and products more accessible, comparable, and understandable.
At both the global level and at the local level, identifying information resources and setting up enabling technology is necessary but not sufficient for a working GEOSS.
In the AIP, projects are being defined that link together satellite providers and value-added services with national partners andåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊåÊ regional/ international agencies in a many-to-many relationship under pilot programs. These pilot programs are local in nature, but supported on a global scale with orbital, aerial, and in situ sensors and analytical models. The data, when they are combined with underlying socio-economic data and infrastructure, can be used to predict risk and assess effective mitigation strategies.
But such resources will not be utilized unless institutional arrangements are in place. In addition to providing institutional support for the technical interoperability work described above, GEO assists in establishing framework agreements that cross country and agency lines to enable the delivery of societal benefit through open data sharing principles.
Funding, of course, is the key to success. Many components and services utilized in this AIP-2 scenario are prototypes of persistent exemplar data services, but most of them are pulled together on budgets gleaned by the individual AIP-2 participants who write competing proposal after proposal to granting agencies that request funds to support this scenario. Governments need to allocate funding at all levels to pay for data delivery infrastructure capacity. The integration of satellite data and value-added services for local use has to be in addition to funds for local utilization and capacity building activities.
AIP-2 Summary Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.1
Polar Ecosystems Biodiversity Scenario Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.0
The Impact of Climate Change on Pikas Regional Distribution Climate Change and Biodiversity WG Use Scenario Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.1
Floods Disaster Response Scenario Engineering Report GEOSS Architecture Implementation Pilot, Phase 2 Version 1.3
Chief Architect and Executive Director, Interoperability Program
Open Geospatial Consortium, Inc. (OGC)
1804 Stonegate Ave
Crofton, MD 21114
Phone: +1 301 560 6439