An Enterprise Architecture for GEOSS: Patterns and Compliance

1
An Enterprise Architecture for GEOSSPatterns
and Compliance

• Carroll A. Hood
• GEOSS Chief Architect

2
Outline

• The GEOSS Value Proposition
• The Least Common Denominator
• GEOSS Enterprise Architecture
• Pattern Based Reference Architecture
• Thread Patterns
• Component Integration Patterns
• Implications on Compliance
• Data Discovery Paradigms

3
The GEOSS Value Proposition

• Enable existing and new Earth and environmental
  observations, data and information systems,
  products and services (components) to be used for
  applications and activities beyond their original
  intent
• Enable environmental and/or geospatial
  perspective to be incorporated into decision
  making for selected social and economic issues
  whenever and wherever it makes sense
• Encourage the development of a value-added market
  for Earth observations data and information
  products and services
• Support capacity building in developing countries

from Emerson, J, J. Wachowitz, and S. Chun,
2000. "Social Return on Investment (SROI)
Exploring Aspects of Value Creation," Roberts
Enterprise Development Funds Publications
The underlying architecture needs to support this
Vision!
4
Beyond the Least Common Denominator

• The GEO Architecture and Data Committee (ADC) has
  defined a Least Common Denominator (LCD)
  approach for linking GEOSS Components
• Low risk
• Politically palatable
• Barrier to buy-in is low
• Elements of the LCD approach include
• Service/component registry
• Service interfaces documented in standard way
• Standard description of product syntax
• Semantics registered
• A true Enterprise Architecture
• Ought to encompass the LCD approach
• Should also provide insight into higher-level
  integration, as well

Integration will be the key to realizing the
complete GEOSS Value Proposition
5
How to Develop an EA for GEOSS

• So how do you create an effective enterprise
  architecture for GEOSS when
• Components exist at multiple, geographically
  distinct locations
• There is no central authority
• Each component evolves on its own time scale
• There are multiple ways to integrate a component
  into the enterprise, each with its own unique
  cost/benefit trade space
• Resources for integrating components are scarce
• Priorities often fluctuate
• Minimum buy-in should not require significant
  infrastructure investment
• Thesis
• A Pattern-based Reference Architecture provides a
  powerful way forward for the design and evolution
  of an Enterprise Architecture that enables GEOSS
  to optimally realize all elements of its Value
  Proposition

6
GEOSS Enterprise ArchitecturePattern Based
Reference Architecture
7
Pattern-based Reference Architecture

• Patterns Abstractions of design solutions
• Reference Architecture (RA) Abstraction of an
  architecture with common characteristics and
  quality attributes
• Tailorable
• Encourages Reuse
• Reduces Risk and Life Cycle Cost
• What and Who NOT How and Why

8
Characteristics of an RA

• Structure
• Entities
• Internal/External Interfaces
• Behaviors
• Global Rules
• Standards
• Constraints
• Enablers
• Issues

Image source http//www.nosa.noaa.gov/about_arch
itecture.html
9
Benefits of a Reference Architecture Approach

• GEOSS/IEOS/IOOS system of system of systems
• No single large procurement
• Multiple entitles evolving toward GEOSS-level
  interoperability over time
• Some new components to fill key gaps
• Reference Architectures would
• Provide a blueprint for the integration of
  components within a common interoperability
  framework (like a magnetic field)
• Provide a blueprint for the development and
  evolution of common threads or processes across
  the enterprise
• Allow for flexibility and innovation in design
  and implementation
• A repository of RAs would increase the
  probability that a component integrated into the
  Enterprise will be plug-compatible

Going beyond the LCD Approach
10
Patterns Threads and Component Integration

• Threads
• Subject of Workshop held in Washington, DC in
  October 2005, sponsored by the US GEO
• Sixty-five participants from nearly 40
  organizations spanning Government, Public,
  Private Sector and NGO stakeholders
• Developed patterns for four threads as proof of
  concept
• Spatially Enabled Search Portals
• Georeferenced Emergency Alerting
• Modeling and Data Assimilation
• Service Interface for Decision Support Tools
• Participants agreed that this approach is
  comprehensive, logical and pragmatic
• Concept included in AR 06-03 Final Report
• Documentation available on www.strategies.org

• Component Integration
• Element of the IOOS Conceptual Design Study
  conducted by Raytheon in 2006
• Developed a Conceptual Design for IOOS that was
  scalable and extensible to IEOS and GEOSS
• Defined patterns for unique levels of component
  integration (Based upon an approach that has been
  used successfully for many years in the
  intelligence community)
• Component integration patterns exist at a more
  fundamental level than thread patterns
• Documentation available on www.ocean.us

Note These patterns are examples. There are
likely many patterns that would be relevant to
GEOSS development
Artifacts generated by the Modeling and
Data Assimilation (MDA) Working Group are
presented in later slides as examples
11
Enterprise Architecture Thread Patterns
12
GEOSS Architecture
13
GEOSS Value Streams
Archive/ Manage Products
Collect Obs
Process Products
Transmit Telemetry
Conduct Primary Mission
Push Products
Information Creation (Supply Side)
Develop Algorithms
Employ R-to-O
Create/ Enable Services
Make Better Informed Decisions
Generate Predictions
Validate Models
Conduct Research
Develop Models
Service Creation (Public Domain Market Driven)
Stimulate Value-added Market
Research/ Modeling
Develop DST
Employ R-to-O
Stimulate Capacity Building
Exploit Decision Support Tools
Access (Pull) Products
Discover Products
Visualize Products
Impacts/ Outcomes
Information Exploitation (Demand Side)
Requirements/Feedback
Information
14
Modeling and Data Assimilation (MDA)
Archive/ Manage Products
Collect Obs
Process Products
Transmit Telemetry
Conduct Primary Mission
Push Products
Information Creation (Supply Side)
Develop Algorithms
Employ R-to-O
Create/ Enable Services
Make Better Informed Decisions
Generate Predictions
Validate Models
Conduct Research
Develop Models
Service Creation (Public Domain Market Driven)
Stimulate Value-added Market
Research/ Modeling
Develop DST
Employ R-to-O
Stimulate Capacity Building
Exploit Decision Support Tools
Access (Pull) Products
Discover Products
Visualize Products
Impacts/ Outcomes
Information Exploitation (Demand Side)
Requirements/Feedback
Information
15
MDA Structure (Process Flow)
Validate activity
Identify quality improvements
Continuously improve service type
Research to Operational Transition
Employ repeatable SE processes
Exploit Decision Support Tools (Visualize results)
Assimilate Data (observa-tions, other data)
Assess Decision-Maker and Societal Needs
Develop Model
Generate Predictions/Scenarios
Create Services (and, Enable the Creation of
Services)
16
MDA Structure (Use Case)
User Community
Collect requirements
Evaluate prototypes
Optimize system
Operations and analysis
Observing Community
Collect requirements
Develop architecture
Develop system
Deploy system
Modeling Community
Collect requirements
Evaluate prototypes
Tune system
Continuous improvement
Cyber- infrastructure
Collect requirements
Evaluate prototypes
Optimize system
Operations and analysis
Based on ROI-based continuous improvement, build
validated refinements into next-generation systems
17
MDA Behaviors

• Pursuit of Excellence
• Faster, higher resolution
• Creation of long-term, self-consistent records
• Pursuit of Relevance
• General and tailored predictions
• Domain applicability
• Pursuit of Effectiveness
• Cost and latency
• Ease of use

18
MDA Standards/Issues/Enablers/Constraints

• Standards
• Earth System Modeling Framework (ESMF)
• SOA-related (WSDL,SOAP, UDDI . . ..)
• FGDC/OGC
• Issues
• Funding
• Gaps between modeling/simulation and societal
  applications
• Data glut
• Enablers
• Need and awareness for coupled models and
  forecasts
• Ability to leverage legacy assets (EOS, NPOESS,
  NCEP . . .)
• Technology maturation
• Constraints
• Funding
• Interoperability
• Education and Training

19
How are Thread Patterns Relevant?

• Lets say that someone has a desire to create or
  integrate an existing component into the GEOSS
  enterprise that relates to the modeling/data
  assimilation thread
• The Thread Patterns provide
• Context of the thread within the enterprise Value
  Stream
• Articulation of a high-level process flow
• Identification of stakeholders and their
  individual perceptions
• Recognition of relevant standards
• Appreciation of both enablers and constraints
• Awareness of potential issues

20
Key Findings from Workshop

• A collection of key stakeholders had the
  opportunity to review a high-level architectural
  approach for both IEOS and GEOSS
• The initial direction is basically comprehensive,
  logical,and pragmatic
• Given the realities of GEOSS/IEOS, namely
• Required evolution/integration of numerous legacy
  components along with selected new components to
  fill key gaps
• These components span all dimensions of the GEOSS
  Value Stream (discipline, geo-political,
  functional)
• The Pattern-based Reference Architecture
  Paradigm provides a logical and powerful way
  forward for GEOSS/IEOS design and implementation
• Each Sector has much to offer in this area in
  terms of experience, tools, methodologies and
  best practices
• The effort will not succeed unless there is
  on-going active collaboration between all
  stakeholders

21
GEOSS Enterprise ArchitectureComponent
Integration Patterns
22
GEOSS Integration Framework Elements

• Components. A GEOSS Component 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 elements that
  integrate Components into the GEOSS Enterprise.
  There are different types of adapters depending
  of the level of integration desired. 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 Components
  into the enterprise. A Service Infrastructure
  provides a common Component 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.

Component
Adapter (Portlet)
Adapter (Data/Application Access)
Services
Workflow
Security
Registry
Communications
23
Logical View of GEOSS Architecture
24
Logical View of GEOSS Architecture
25
Integration PatternsLevel 0 Publish Interface
Description Document
26
Integration PatternsLevel 1 Tap into Legacy
Components
27
Integration PatternsLevel 2 Isolate and
Refactor Components
28
Integration PatternsLevel 3 Build New
Components w/i Service Paradigm
29
How are Integration Patterns Relevant?

• Lets say that someone has a desire to create or
  integrate an existing component into the GEOSS
  enterprise
• The Integration Patterns provide
• A cost/benefit trade space
• An option that does not required significant
  investment in infrastructure
• An ability to promulgate data and information
  integration in additional to enhanced data and
  information discovery

30
Turning Logical in Physical

• Each Community of Interest (CoI) can create and
  maintain their own node
• Thematic
• Geopolitical
• Each CoI controls its node (local autonomy)
• GEOSS may not need to be concerned about what
  goes on inside the CoI
• GEOSS is concerned about those components that
  the CoI chooses to expose outside their local
  enterprise
• A consistent Services Infrastructure across nodes
  ensures interoperability
• Any component exposed at any one node is exposed
  to the entire enterprise
• The node paradigm scales to GEOSS level of
  complexity
• Components need not be co-located with node
• Critical for capacity building

31
GEOSS Architectural Framework(Physical View)
GEOSS Node (geopolitical, thematic)
Component
Component
Common Services
Component
Component
Component
Component
Common Services
Component
Component
Component
Component
Component
Component
Common Services
Component
Component
Component
Component
Common Services
Component
Component
Component
Component
32
Implications on Compliance
33
GEOSS Compliance

• Designed to ensure
• Individual GEOSS Components can be easily
  discovered, accessed, and exploited by as wide
  range of potential users as possible
• GEOSS Components 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
• Prescribe which Components can become part of
  GEOSS,
• Dictate the business model that an Component or
  organization can employ,
• Specify how Components operate internally

34
GEOSS Component Compliance

• All GEOSS Components need to be registered within
  a node of the GEOSS Component 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 should document
  the following
• Machine readable syntactic characterization
• Semantic characterization (ontology)
• Full detailed history of relevant milestones with
  the complete product life cycle (full
  provenance)
• Characterization of quality
• All applications and services should document the
  following
• 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

This is consistent with the Least Common
Denominator approach
35
GEOSS Adapter Compliance

• Adapters can be physically co-located with the
  Component or can be remote
• All GEOSS Adapters should be registered in the
  GEOSS Component Registry and placed into a
  software reuse library.
• An item in the reuse library should be supported
  by appropriate documentation, for example
• Documented source code
• Full detailed history of relevant milestones with
  the complete adapter life cycle (full provenance)
• Test procedures
• Relevant Use Cases

Use of Adapters Implies a Higher Level of
Connectivity
36
GEOSS Service Infrastructure Compliance

• Realizing the complete GEOSS Value proposition
  will be facilitated by the development of a basic
  services infrastructure that can be replicated
  across the enterprise
• Replication provides a set of common services
• Replication provides a degree of local autonomy
  in terms of what components 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.
• Components of this basic service infrastructure
  include but are not limited to
• GEOSS Component Registry (single system
  distributed across multiple sites)
• Semantic Services (ability to create, update and
  map ontologies)
• Discovery/Access Services (ability to plug in
  customized portlets for specific communities of
  interest)
• Security Services (ability to provide
  authentication, authorization)
• Workflow Services (ability to orchestrate
  services)
• Development Services (support the development of
  adapters, portlets)

Use of Common Services Implies a Higher Level of
Connectivity
37
Discovery Current State
Environmental Product Registry
1. Figure out what I need
2. Submit Query
User
3. Deliver Results
4.. Access/contact each source, request data
6. Figure out how to interpret and use the data
I get
5. Deliver data
Registry Info
Environmental Data Sources (some are on-line,
some are not)
38
Discovery Desired Future State
2. Submit query along with my personal ontology
Environmental Product Registry
Discovery Service
1. Figure out what I need
Domain ontologies
User
4. Submit Query
3. Map ontologies
Create, update personal ontology
5. Deliver Results along with product ontologies
and machine-readable syntactic characterization
9. Deliver data elements and context
Ontology Service
Parsing Service
Registry Info including domain ontologies. product
ontologies, and machine-readable characterization
of product syntactic structure
7. Deliver data
6. Submit query
8. Parse desired data elements
Environmental Data Sources