ESDS Reference Architecture

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

2. 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

3. Activities • Weekly telecons • Focus on Scope and Norming • Annotated outline

4. 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

5. ESDS Capabilities

6. Stakeholder Survey

7. Stakeholder Concerns and Supporting Views

8. Functions

9. Base Context Diagram

10. Legacy view

11. 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?

12. 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.)

13. 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.

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

15. 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)