GEOSS Architecture for Disaster Management and Risk Assessment Enterprise Architecture Concepts

1. GEOSS Architecture for Disaster Management and Risk Assessment Enterprise ArchitectureConcepts John D. Evans, Ph.D. Global Science & Technology, Inc. /NASA Earth Science Technology Office Presented at CEOS-WGISS-32, Budapest, Hungary, 2011-09-27

2. WGISS-32 – Budapest, Hungary Using Satellite Data in Disaster Management and Risk Assessment WGISS People – Sensors – Data – Processes – Decision Support

3. WGISS-32 – Budapest, Hungary Using Satellite Data in Disaster Management and Risk Assessment • Involves coordination and linking among • Activities of many Independent Parties • Different Contexts / Communities of Practice • Esp. Vocabulary & Semantics • Also Linguistic, Cultural, Economic, Political differences • Decisions and Operations using Satellite Data • => Greater Effectiveness; Greater Efficiency • Requires a shared, precise understanding of • Disaster Management and Risk Assessment processes (decisions, operations, etc.) • How those processes use (or could use) complex data streams from satellites

4. WGISS-32 – Budapest, Hungary Using Satellite Data in Disaster Management and Risk Assessment • Involves coordination and linking among • Activities of many Independent Parties • Different Contexts / Communities of Practice • Esp. Vocabulary & Semantics • Also Linguistic, Cultural, Economic, Political differences • Decisions and Operations using Satellite Data • Effectiveness; Efficiency • Requires a shared, precise understanding of • Disaster Management and Risk Assessment processes (decisions, operations, etc.) • How those processes use (or could use) complex data streams from satellites EnterpriseArchitecture

5. WGISS-32 – Budapest, Hungary What's an Enterprise Architecture? • “A conceptual blueprint that defines the structure and operation of an organization ... to determine how [it] can most effectively achieve its current and future objectives.” (Wikipedia) • “A framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards... based on a small number of unifying concepts … may be used as a basis for education and explaining standards to a non-specialist. (ORCHESTRA Ref. Model) • “A management practice for aligning resources to improve business performance and help agencies better execute their core missions” (US Federal Enterprise Architecture) • “A framework for ensuring IT investments enable the mission and are integrated, efficient and secure” (NASA)

6. WGISS-32 – Budapest, Hungary Enterprise Architecturevs. Reference Model • An Enterprise Architecture describes the structure of an enterprise, including the business entities, their properties and behavior, and the relationships between these entities. • A Reference Model is a conceptual, technology-independent description of entities and relationships within a given environment. It includes a clear description of the problem to be solved, and the concerns of the stakeholders who need the problem solved. • These are interchangeable for our purposes – at least for now

7. WGISS-32 – Budapest, Hungary What's an Enterprise Architecture? • An enterprise architecture (/ reference model) is: • Guidance, not a fully detailed plan or blueprint • A tool, not a policy • A living document – not a fixed specification • Provides a logical rather than a physical view • Articulates a shared understanding of • Needed functions and • End-to-end data flows • But doesn’t attempt to create inventories of deployed resources

8. WGISS-32 – Budapest, Hungary What is the Enterprise? • One starting point: GEOSS DI-06-09 charter (Use of Satellites for Risk Management): • Reducing loss of life and property from natural and human-induced disasters • More specifically: “Define and facilitate implementation of satellite constellations for risk management from a multi-hazard perspective. Undertake the consolidation of the validated requirements and examine options for system development and implementation.”

9. WGISS-32 – Budapest, Hungary Requirements for our Enterprise Architecture / Reference Model • Allow for regional differences – policies, economics, language, etc. • Not an abstract, one-size-fits-all architecture • Allow for a variety of types of disasters • Support both disaster response and risk assessment • Build on / be consistent with existing architectures and semantics • GEOSS Architecture Implementation Pilot - AIP3 • GEOSS 10-Year Action Plan • UN-SPIDER • International Charter; others?

10. WGISS-32 – Budapest, Hungary Building an Enterprise Architecture: Architecture Frameworks • An Architecture Framework defines levels, layers, or views used in constructing an enterprise architecture or reference model • e.g., Business / Applications / Data / Technology

11. WGISS-32 – Budapest, Hungary Architecture Frameworks • ISO/IEC Reference Model for Open Distributed Processing (RM-ODP) • Seems like a good fit here: • Distributed data handling • Open systems approach • Used by related enterprise architectures: • GEOSS Architecture Implementation Pilot (AIP-3) • ORCHESTRA (European Union - Service Oriented Architecture for EU Risk Management) • INSPIRE (Infrastructure for Spatial Information in Europe)

12. WGISS-32 – Budapest, Hungary Reference Model for Open Distributed Processing (RM-ODP)

13. WGISS-32 – Budapest, Hungary Enterprise Viewpoint • Enterprise questions to be addressed for GA4D: • What are the purpose and scope for the use of satellite data in Disaster Management and Risk Assessment? • What activities are involved? • In what organizational structures do (or must) these activities take place? • Who are the participants in these activities? • Who are the stakeholders for this architecture – who has (or should have) a say in how these activities draw on information from satellites (and elsewhere)? • What other enterprises are linked to this one? • Include Roles • Use cases Scope

14. WGISS-32 – Budapest, Hungary Information Viewpoint • Information questions to be addressed for GA4D: • What observations or parameters are needed when responding to different kinds of disasters (or assessing their risk)? • In what forms does this information best support the enterprise? • What metadata are needed to ensure that data can be found and appropriately used? • What inter-dependencies exist among these data products? • What data transformations, interpretations, extractions, syntheses, etc. are needed between sensors and users?

15. WGISS-32 – Budapest, Hungary Information Viewpoint • Observations types vs. Societal Benefit Areas From GEO Task US-09-01a Critical Earth Observation Priorities Summary of Results • October 2010

16. WGISS-32 – Budapest, Hungary Information Viewpoint • Observations types vs. Disaster Types From GEO 10-Year Implementation Plan Reference Document • February 2005

17. WGISS-32 – Budapest, Hungary Computation Viewpoint • Information questions to be addressed for GA4D: • What service types are needed to make the necessary information available to users?(e.g., data access, visualization, catalog search) • How will these service types effect the data transformations, interpretations, extractions, syntheses, etc. that are needed between sensors and users? • What requirements apply to these services and interfaces (e.g., near-real-time performance, cross-community interoperability)

18. WGISS-32 – Budapest, Hungary Engineering Viewpointand Technology Viewpoint • Engineering questions to be addressed for GA4D: • What interface types are needed to invoke the services described in the computation viewpoint? (e.g., stateless / stateful; pull / push) • What interface standards are needed to support interoperation between different communities? • Technology questions to be addressed for GA4D: • What satellite data streams are available? Needed? • What catalogs are available? Needed?

19. WGISS-32 – Budapest, Hungary Questions / Discussion