13 September 2006 Carroll A. Hood GEOSS Chief Architect

1. Moving SECOORA ForwardConceptual Design of an Enterprise Architectural FrameworkFact and Speculation 13 September 2006 Carroll A. Hood GEOSS Chief Architect

2. Fact

3. GEOSS Framework IOOS Framework Governance and Funding WG Product Development and Marketing WG Operational and Systems Performance WG Research and Development WG • Regional Research Priorities • Pilot Projects • Workforce Sustainment .Training Plan • RA Goals and Objectives • Governance Plan • By-Laws, Articles of Incorporation • Budget Requirements • Outreach Plan • Marketing Plan Observations And Data Transmission SG Data Management and Communications SG Data Analysis and Data Products SG • Modeling/Forecasting Strategic Plan • User Interfaces • Private Section Coordination • System Performance Milestones//Metrics • Ocean Data Partnership • Standards/Protocols • System Performance Milestones/Metrics • RCOOS Design Document • Asset Inventory/Future needs • System Performance Milestones/Metrics SECOORA Planning Framework IEOS or GOOS Framework

4. Higher Level Frameworks • Designed to ensure that the GEOSS Value Proposition can be fulfilled • Individual assets can be easily discovered, accessed, and exploited by as wide range of potential users as possible; • Assets can readily be combined to support any number of value-enhancing end uses; and • The implementation strategy proactively strives to expand empowerment at all levels, promote equal opportunity access and reduce life cycle costs by facilitating sharing and reuse. • Designed NOT to • Dictate local priorities • Prescribe which assets can become part of the enterprise, • Dictate the business model that an asset or organization can employ, • Specify how assets operate internally

5. Proposed SECOORA Enterprise Architecture Framework • Purpose • Provide guidance to the Working Groups and Subgroups to ensure that SECORRA development activities consider the context of IOOS, IEOS, GOOS, and GEOSS architectural frameworks • Use what we need • If we decide to go in a different direction, we do so with full understanding of the cost, the benefits and the implications • Activities • Develop an EA Framework for SECOORA • Vet framework through Working Groups • Publish/maintain SECOORA EA Framework Document • Constraints • Top-down guidance incomplete and not single source • NOAA is currently normalizing the results from two IOOS Conceptual Design Studies • GEOSS Secretariat is currently investigating options for developing Reference Architectures for GEOSS • Bottom-up driver required consensus across stakeholders • We’re not there yet

6. SpeculationWhat Does it Mean to be GEOSS Compliant?Based On Raytheon's Proposed IOOS Conceptual Design

7. GEOSS Architecture Framework • Assets. A GEOSS asset is any data stream, system, application, product or service that has utility or value to any potential GEOSS user. This definition is extremely broad and expansive – by design. We do not wish to constrain creativity or innovation in the ways in which GEOSS can create value to society. • Adapters. Adapters are the software that integrate assets into the GEOSS Enterprise. Adapters expose products or services to the Enterprise without impacting the systems or applications that they connect. Adapters are also used to connect users into the Enterprise. • Services Infrastructure. A GEOSS Services Infrastructure provides the “Backplane” or place where adapters physically integrate assets into the enterprise. A Service Infrastructure provides a common Asset Registry as well as the underlying communication, security and workflow services for the Enterprise. Replication of these services at multiple sites provides Enterprise-wide interoperability.

8. User Adapter (Portlet) Common Services Other Services Workflow Security Registry Security Workflow Communications Communication Adapter (Data/Application Access) Asset Service Infrastructure GEOSS Enterprise GEOSS Architecture Framework (Logical View)

9. GEOSS Node (geopolitical, thematic) Asset Asset Common Services Asset Asset Asset Asset Common Services Asset Asset Asset Asset Asset Asset Common Services Asset Asset Asset Asset Common Services Asset Asset Asset Asset GEOSS Architectural Framework(Physical View) SECOORA

10. GEOSS Asset Compliance • All GEOSS assets need to be registered with in a node of the GEOSS Asset Registry. • The required set of attributes for this registry have not yet been defined, but it will need to go beyond a typical Federal Geospatial Data Committee (FGDC) profile. • All data and information products will need to include • Machine readable description of product format • Semantic characterization (ontology) • Full detailed history of relevant milestones with the complete product life cycle (full provenance) • Characterization of quality • All applications and services will need to include: • Full characterization of the service interface • Full detailed history of relevant milestones with the complete application life cycle (full provenance) • Characterization of its Service Level Agreement (SLA) • Availability • Business Rules or Constraints • Quality

11. GEOSS Adapter Compliance • All GEOSS Adapters should be registered in the GEOSS Asset Registry and placed into a software reuse library. • An item in the reuse library shall consist of • Documented source code • Full detailed history of relevant milestones with the complete adapter life cycle (full provenance) • Test procedures • Relevant Use Cases

12. GEOSS Service Infrastructure Compliance • The evolution towards GEOSS will be facilitated by the development of a basic services infrastructure that can be replicated across the enterprise. • Replication provides a degree of local autonomy in terms of what assets need to be brought to bear for a particular national, regional or thematic community of interest; yet, because the service infrastructure is common, it promotes interoperability across the enterprise. • Replication provides a set of “common services” • Components of this basic service infrastructure include: • GEOSS Asset Registry (single system distributed across multiple sites) • Semantic Services (ability to create, update and map ontologies) • Discovery/Access Services (ability to plug in tailored portlets) • Security Services (ability to provide authentication, authorization) • Workflow Services (ability to chain together applications) • Development Services (support the development of adapters, portlets)

13. SECOORA Testbed • Raytheon is working to develop a Demonstration of the proposed architecture that utilizes SECOORA assets • Use demo to establish support and develop business case for a SECOORA EA Testbed • Establish SECORRA Leadership in RA EA Development • Working Facility to test and improve interoperability • Springboard for R&D to extend the state-of-the-practice • Testbed would be a SECOORA asset, not a Raytheon asset