ESDS Reference Architecture In process report ESDSWG, New Orleans, LA October 21, 2010

Background Outcome of ESIP meeting Capture a baseline of NASA’s ESDS architecture –Enable evolution to support future missions Two teams formed –Writing team Emily Law, Barry Weiss, Nettie Labelle-Hamer, Chris Mattmann, Rich Ullman, Michael Burnett –Review team Alan Doyle, George Percival, Helen Conover, Jeanne Behnke, Marilyn Kaminski, SiriJodhaKhalsa, Yonsook Enloe

Activities Weekly telecons Focus on Scope and Norming Annotated outline

Reference Architecture “A reference architecture provides a proven template solution for an architecture for a particular domain.” Philosophy –Proper level –Provide guidance –Not prescriptive –Supports current, enables future –Voltaire-ian: “The perfect is the enemy of the good” Approach –Scope –Stakeholders –Requirements –Views

ESDS Capabilities

Stakeholder Survey StakeholderDescription System ArchitectThe System Architect is responsible for establishing the vision of a system that will meet specific needs, the approach for realizing that vision and ensuring that it is properly fielded. Normally this role is for systems targeting an operational capability. The System Architect typically will evaluate the target system and put it in the context of the Reference Architecture, first ensuring that the Reference Architecture is pertinent, then understanding how best to leverage it. Data ArchitectData Architects are responsible for the information modeling within systems. They are concerned with capturing the information used within a system, from conceptual through physical deployment. Project ScientistThe Project Scientist is responsible for defining and delivering the science mission requirements. The Project Scientist's particular focus is the allocation of resources (data, services, applications) deliver data tousers. Data ProviderThe Data Provider is responsible for the generation, the distribution and the archive of mission data that conforms with science mission requirements. Policy ResearcherThe Policy Researcher is interested in higher level products and applications that can be used for analysis, decisions and formulation of policy. This individual usual works applications in social science. Needs abstraction and summary of data for proper level of understanding. Research ScientistThe Research Scientist uses Earth Observation resources in the pursuit of their own science goals. The outcome of their research may or may not be introduced into the system as shared resources. Program ManagementProgram managers establish and track plans, budgets, processes and governance mechanisms within programs. These responsibilities begin during project inception, where potential programs are conceived and funding decisions are made, through mission deployment and maintenance. NASA ManagementNASA Managers are responsible for mission fulfillment, policy adherence and large scale budgetary concerns. These managers ensure that maximum value is being derived from existing investments, to identify high value areas of future investments and to validate proposed solutions in the context of existing enterprise resources.

Stakeholder Concerns and Supporting Views StakeholderConcernsApplicable Views System Architect  Scope of target system  System Architecture View (functions, componenets, interfaces)  Relationship to Reference Architecture  Technology View (standards)  Integrating with/extending Reference Architecture  Leveraging Reference Architecture for system of interest Data Architect  Data and metadata exchange  Information Architecture View  Leveraging and extending information model  Product Value Chain View Project Scientist  New Data Products  System Architecture View  Data Volumes and performance  Information Architecture View  Data Quality  Product Value Chain View  Algorithms  Legacy Data Products and availability Data Provider  System Functions  System Architecture View  System Performance  Information Architecture View  Data Model standards  Product Value Chain View Policy Researcher  Data Applicability  Technology View (tools)  Discovery  Product Value Chain View  Access  Visualization Research Scientist  Discovery and Access  Information Architecture View  Notification  Technology View (tools)  Quality and Provenence  Product Value Chain View  Data Model Program Management  Requirements  System Architecture View  Leveraging existing investments  Functional View  Budget  Schedule  Organization  Policy NASA Management  Budget  System Architecture View  Vision  Functional View  Roadmap  Product Value Chain View  Enterprise Drivers/Requirements

Functions Descriptions 1Process Level Zero Data Decode, separate and rate buffer data. Provide temporary storage 2Ingest DataIdentify requisite data, check data integrity, register and store data in Life of Mission Storage 3Generate Mission Data Products Identify available data for processing, run executables, check for successful completion, iterate through processing sequence, upon approval deliver data to long term archive, reprocess data 4Monitor Mission Performance Ascertain data quality, validate mission data, monitor spacecraft and instrument performance, recommend operational changes 5Enhance Processing Algorithms Test alternative algorithms, ascertain quality improvements, ascertain performance impact, recommend data processing changes 6Archive and Distribute Data Check data integrity, register, store and maintain data sets, provide data and commensurate assistance to the user community

Base Context Diagram

Legacy view

Architecture Views System Architecture View –The abstract types of pieces and how they work together Technology View –The standards and tools that are commonly used within instances of the reference architecture Information Architecture View –The information managed within ESDS and the relationships between them Product Value Chain View –The relationships and dependencies between data products. Function View –What functions happen within the ESDS, their relationships and consumers. User View –What do users (non-operators) see and interact with. Where do they go to get their jobs done?

Glossary Actor – A UML construct that is used to represent something, or someone, that interacts with a system. Actors are external to a system – they are not part of it. Actors typically stimulate the system to perform some behavior, or are the recipients of a systems work product. Components – Physical entities (hardware or software) that have one or more specific tasks within a system. Components offer their capabilities, and interact with other components through interfaces (often APIs). Within the ESDS Reference Architecture, components are representations of capabilities that will be realized by actual software or hardware. Functions – High-level activities that systems support. The components of a system collaborate to provide these high-level functions. Within the ESDS Reference Architecture, functions are those enterprise or program level things that occur within the Earth Science Data System domain. [Keep, but not part of definition. Not all functions may be provided by all instantiations of an ESDS. However, to the extent that an instantiation of the ESDS Reference Architecture is valid, it provides capabilities to exercise any of the ESDS Functions.] Mission Level Use Cases – High-end Use Cases that describe the responsibilities of projects and the organizations that support them, in the language of its user community and in terms that are independent of technology or solution. Fundamentally, these use cases describe the processes that mission actors (people or external systems) perform to achieve their goals. Within the ESDS Reference Architecture, Mission Level Use Cases help define the high level requirements that are shared by all instances of the reference architecture. (NOTE: Mission Level Use Cases are analogous to Business Use Cases.)

Glossary (con’d) Scenarios – Low level interactions between actors and components within a system. Scenarios support the realization of System Use Cases, and are often reusable in many differing use cases. Services – Functionality offered by components, provided to other components and actors within a system. Services are accessed via interfaces, which are described through interface definitions. Within the ESDS Reference Architecture, services are standardized in their interfaces, allowing many different component instances to contribute and participate in instantiations of the ESDS Reference Architecture. System – An organized composition of Information Technology components (software, hardware, network and data), processes and people that work together to provide capabilities. Users gain access to a system through a well defined and managed set of interfaces. Within the ESDS Reference Architecture, systems realize some subset of the ESDS Functions, and provide access to that functionality in a manner consistent with the reference architecture. System Use Cases – Use Cases that describe a system’s responsibilities. The responsibilities are captured in the context of how users interact with that system and what those users can expect of the system. System Use Cases can be written with varying degrees of formality. Use Case – A mechanism used to define a set of interactions that lead to a specific goal being realized. Use Cases are captured in the language of the user (called an Actor in UML) and are technology independent. Typically Use Cases are used to capture the functional requirements of a system or organization. There are three levels of Use Cases discussed within the ESDS Reference Architecture: Mission-level Use Cases System Use Cases and Scenarios.

Annotated Outline Current baseline – Seven pages long – Work in process, alignment to current scoping is iterative Current Outline

Going forward… Programmatically –Continue weekly telecons through the norming process (through 11/10) Finalize the scope (context, functions) Define the views –Build the reference architecture (through Mar/Apr 2011) –Document (monthly releases?) Evolve the annotations Build the draft Review iterations Architecturally –Evaluate evolution of Reference Architecture (NOTE: All timeframes are nominal at this point)