View source for SPG Agenda July 22 2010

July 22, 2010 [http://www.esdswg.net/spg NASA ESDSWG SPG] meeting

'''Reference Architectures for NASA Earth Science Data Systems'''

8:30am - 5:00pm

==Agenda==

Note: Order of presentations may change

'''8:30 - Session 1'''

* Rich Ullman, NASA SPG — ''Introduction''
* Allan Doyle/Michael Burnett, NASA SPG — ''Introduction to Reference Architectures''
* Jeanne Behnke, ESDIS — ''EOSDIS Reference Architecture''

'''10:30 - Break'''

'''11:00 - Session 2'''

* George Percivall, OGC — ''Reference Architectures and Agile Development''
* Chris Mattman, JPL — ''Exploiting Reference Architecture to Guide the NASA Earth Science System Enterprise''

'''12:30 - Lunch'''

'''1:30 - Session 3'''

* Steve Hughes/Emily Law, JPL — ''Science Data System Reference Architecture Concepts and Principles''
* Chris Lynnes, NASA/GSFC — ''The End User in the NASA Data System Reference Architecture''

* Round Table Discussion — Speakers & audience discuss questions raised in the '''Topic''' section below

'''3:00 - Break'''

'''3:30 - Session 4'''

* Wrap up and conclusion — Speakers & audience develop plans for how the SPG should continue handling this topic.

'''5:00 - Session Ends'''

==Meeting Topic==

Through a series of technical workshops the [http://www.esdswg.net/spg Standards Process Group] has investigated Data Formats, Catalogs and Metadata, Emerging Technologies, and Web Services.

The July 2010 workshop will focus on Reference Architectures for NASA Earth Science Data Systems. The purpose of this workshop is to explore the potential of a reference architecture in identifying common elements of NASA Earth Science Data Systems.  

From [http://en.wikipedia.org/wiki/Reference_architecture Wikipedia:]

:''A reference architecture provides a proven template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.''

:''A reference architecture often consists of a list of functions and some indication of their interfaces (or APIs) and interactions with each other and with functions located outside of the scope of the reference architecture.''

:''Reference architectures can be defined at different levels of abstraction. A highly abstract one might show different pieces of equipment on a communications network, each providing different functions. A lower level one might demonstrate the interactions of procedures (or methods) within a computer program defined to perform a very specific task.''

:''A reference architecture provides a template, based on the generalization of a set of successful solutions. These solutions have been generalized and structured for the depiction of both a logical and physical architecture based on the harvesting of a set of patterns that describe observations in a number of successful implements. Further it shows how to compose these parts together into a solution. Reference Architectures will be instantiated for a particular domain or for specific projects''

Benefits of a reference architecture may include clearer communication about the elements and artifacts involved in producing environmental research products from NASA’s satellite remote sensing missions, identification of common interfaces  and more cost-effective reuse of system elements.

Questions we hope to address: 

* Can a reference architecture help NASA develop better Earth Science systems interoperability and encourage the interuse of NASA’s data?  
* How can reference architectures be used to lower system development and acquisition cost?  
* Can reference architectures provide guidance to current and future data systems developers while also allowing for adaptation to future developments in system design?

If the answers show that reference architectures would be beneficial, that opens up a series of additional questions:

* How should NASA best develop reference architectures for Earth Science data systems?
* Does it make sense to develop reference architecture "fragments" that address specific needs, e.g. SIPS interfaces, catalog/inventory/directories, etc.?
* How can the SPG foster development of reference architectures while still maintaining its community driven process?

The workshop will consist of a series of invited technical presentations along with panel and/or audience discussions. Speakers are encouraged to address these questions based on their own experience, both in terms of what has worked or not worked for their agency/group and in terms of what they think future directions in this area should be.

==Logistics==
Please see the overall [[July_20-23, 2010, ESIP Federation Meeting, Knoxville, TN]]  ESIP event web page for full details.