NASA’s Process of Community Endorsement Standards or: How the NASA Standards Process seeks to “Cross the Chasm” CEOS WGISS, Annapolis MD Richard Ullman, NASA GSFC

Motivation One initiative after another has stressed the need for interoperability standards. Many standards initiatives, both formal and grass roots have put forward specifications or demonstrated various ways to enable access to data. NASA, or NASA funded projects are often in the forefront of these activities. However, NASA participation in a standards development activity does not imply that NASA projects endorse the results of that activity. There is an adoption gap between the research data systems activities and the mission data systems activities.

Network Effect From Wikipedia, 2006 The network effect is a characteristic that causes a good or service to have a value to a potential customer dependent on the number of customers already owning that good or using that service. One consequence of a network effect is that the purchase of a good by one individual indirectly benefits others who own the good - for example by purchasing a telephone a person makes other telephones more useful. This type of side-effect in a transaction is known as an externality in economics, and externalities arising from network effects are known as network externalities.

Crossing the Chasm Diagram Geoffrey Moore, 1999 modified after Everett Rodgers, % 0% Adoption Time

Decision Criteria Innovators/Early Adopters Enthusiastic for technology. Vision of what a technology might do. Ability to cope with a high degree of uncertainty. Pragmatists (Early majority) Pragmatists do not look to the specification or the marketing claims, but rather look to members of their pragmatic cohort for trusted opinion. Need both references and relationship Reference from Early Adopter won’t do. Deliberate before adopting a new idea.

Crossing the Chasm Diagram The NASA Chasm InnovativePragmatic Research/DemonstrationMission Reliability/Stability 100% 0% Adoption Time

The NASA SPG Request For Comment Process Modeled after example of Internet “IETF RFC”. Tailored for responsiveness to NASA. Proposed standards are documented as specifications according to SPG guidelines and submitted by practitioners within the NASA community. The Standards Process Group forms a Technical Working Group (TWG) to coordinate evaluation. What does “implementation” of this specification mean in the context of NASA Earth Science Data Systems? What constitutes successful “operational” experience? The community is invited by means of announcement to comment on the specification and particularly to address questions formulated by the TWG. The TWG also identifies key stakeholders that are likely to have particular experience with the technology and solicits their opinion. The TWG reports to the SPG and the SPG makes recommendations for final status of the RFC.

Proposed Standard CommunityCore Draft Standard CommunityCore Standard CommunityCore RFC CommunityCore Review of Operation Recommendation SPG Evaluate Implementations and Community Response TWG Evaluate Implementations Stakeholders Review of Implementation Recommendation SPG Evaluate Implementations and Community Response TWG Evaluate Implementations Stakeholders Initial Screening Initial review of the RFC Provide RFC submission support Form TWG; set schedule The Three Step Standards Process

Responsibilities Community Leader Identify someone in their community who will document standard according to SPG guidelines. Work with the community to get an extended review of the proposed standard. SPG Assign “RFC editor” to advise on RFC document. Publish and publicize RFC Assign “TWG”, technical working group to organize community review and evaluate responses. Recommend action to NASA HQ.

Kinds of Practices Suitable for SPG Any data system practice that increases interoperability or interuse of data within a community or among communities. Standard - Documents Operational Use Tech Note - Builds community awareness; sometimes a precursor to a standard Examples: Describe science content (e.g. Content standard for a level-2 precipitation product, surface reflectance product content) Describe interface (e.g. Data Access Protocol, Web Map Server) Describe metadata (e.g. DIF, ECHO) Describe File Format (e.g. HDF, GeoTIFF) Best Practices (e.g. File naming conventions, fast search algorithm for polar data)

Successful RFCs will have Well documented standard specification At least two implementers. Demonstrated operational benefit. Strong community leadership to support and use standard Leadership in generating the RFC. Community willing/able to review Potential for “impact” and spillover to other communities

Crossing the Chasm? A specification or practice is recommended as a standard … Only after practices have been shown to: (1) have demonstrated implementation and (2) benefit to operation will they be endorsed for preferential use. Ideas come from innovators and are tempered by the significant demands of writing an RFC. Review process permits adoption only after “significant” community endorsement. Pragmatic criteria of usability and the RFC process can provide the leadership references that pragmatists seek.