Linking Tasks, Data, and Architecture

Doug NebertAR-09-01AMay 2010

GEO Task Role in GEOSS

The majority of GEO Tasks and Systems that are identified as contributions have an uncertain role in GEOSS

The data and service requirements that are required by and result from Task activities need to be identified in a consistent way

Construction of a viable System-of-Systems requires understanding and deployment of predictable data and services that supports SBA interests

Data and Architecture Inspection Strategy

AccessRequirement

DataRequirement

DeliveryRequirement

DeliveryRequirement

ProductRequirement

DataRequirement

By working with each Task/System to address data input and output needs, we can identify the data, dissemination, and service requirements for GEOSS. Through progressive exploration, we can identify the requirements for a network of connections between tasks, systems, and users from a task/user point of view..

Inputs Outputs

Task,Project, System,

Application

Data maturity scale

1 – Semi-structured information resource A – Report, document, website, HTML B – Image or map as file document C – Reference published in GEOSS

2 – Structured data product A – with metadata B – with detailed metadata incl. data dictionary C – detailed metadata published in GEOSS

Data Requirements (Input/Output)

Data Characteristics to document, e.g. Data 'field' name and definition (semantics) Source, Methodology Quality, Accuracy, Resolution Temporal properties (date of collection, periodicity) Locational properties, extent, and accuracy Data format and data types Units of measure Data access, pricing, redistribution

Ideally collected through Structured Documentation (metadata, with data dictionary)

Service Requirements

Support for data content and syntax options, input and output

Transformation or processing algorithm or model applied, if any

Service protocol detail, capabilities description (metadata)

Access control

Service Maturity Scale

Data Available via: 0 – email, phone request 1 – ordering on website 2 – static download via website link or ftp 3 – selection user interface on 'data portal' 4 – ad-hoc access or processing web service 5 – standards-based access or processing web

service 6 – standards-based service interface registered in

GEOSS SIR

Inspection by Task/project/system For each data requirement, input and output,

Perform an assessment of the current and projected state of maturity

Document the data and access requirements combinations for your activity

Identify the opportunities to register your needs and your offers within GEOSS

This will allow us to properly populate GEOSS and define a web of actual task/system-based needs and capabilities within GEOSS

Consultation between ADC experts and Task experts will be required for meaningful progress

Contributors – on your system/task What interfaces exist that can be contributed or

shared? Evaluate what standard system interfaces and

data from the SIR could be adopted and deployed to enable connection in a system-of-systems environment?

When a system interface is constructed, register it with GEOSS for advertising and interconnection

What technical assistance is required to enable this process?

Approach Prepare a methodology and engage all Tasks and

Systems to identify data and service capabilities that should be identified in GEOSS

Provide assistance to Tasks and system operators to understand the data/architecture context and how to adapt their systems with standard data and services to promote interoperability, and to register them

Interactions suggested with: Data management (DA-09-01A) User requirements (US-09-01A) Expand STC survey efforts to include data, processing,

and service capabilities documentation (ST-09-01) Engage CBC to develop tutorial materials on how to

deploy and use GEOSS (CB-09-04, -05)

17

Potential maturity model for GEOSS

Technology: complexity, adaptability

Po

licy:

acc

ess

ibili

ty, g

ove

rna

nce

Affiliation

Identification

Confederation

Federation

IntegratedSystem-of-Systems

Current state-of-play based on contributed Components and Services

18

Elements of the maturity model Identification: Members identify resources and provide basic information

for further contact. Little/no direct access to data or services. Web pages and documents predominate. (e.g. Web model)

Affiliation: Members brand contributions with a common group identity (GEOSS) for recognition. Information access and technology are limited but diverse. Integration of resource content is difficult. (e.g. Membership model)

Confederation: Members adopt a common approach but retain rights of self-governance, access terms, and technology. Information access is enhanced but multiple interfaces predominate. Developers can assemble interfaces to multiple systems in weeks (e.g. Community of Interest model)

Federation: Members agree to adopt common practices, data access principles, terminology, devolving some authority to a common governance body. Information content and services are well-described and some common interfaces and formats are deployed by requirement. Integrators can assemble interfaces to diverse systems in days (e.g. Governmental or professional network model)

Integrated System-of-Systems: Members encapsulate systems and offer standardized service interfaces to process/access data with identified and common semantics and common format/syntax. Data access rules are deployed transparently across all systems. Client software can be deployed to access diverse system interfaces in real-time based on familiar patterns (e.g. Enterprise System model, System-of-Systems model)

19

Applying the maturity model

Adoption of a new operational paradigm that imposes both policy and technology requirements takes time and may follow a natural progression

Some participants will remain in one position based on a number of constraints

Identifying the current and future levels of desired performance for GEOSS in general may help in the vision, promotion, and mitigate overselling of capabilities and provide a phased target over time