# Presentation: 090123

## SEEDS Reuse and Reference Architecture Study

**Software Reuse Process Definition **
**Workshop 2 (June 17 – 19) Results**
**Breakouts with Community Input**

## Agenda

**Workshop instructions (15 min)**
- Workshop goals
- Workshop format
- Reuse goals
**Group exercise (20 min)**
- Problems & opportunities
**Reuse process breakout teams (2 hr + 10 min break)**
- Guiding principles
- Reuse program strategies
- Reuse enablement strategies
- Evolutionary processes
- Reference architecture purposes
- Model reuse initiatives
- Critical success factors
**Wrap-up: key recommendations (15 min)**

***Focus topics for today’s workshop***

## Workshop Results Summary

**Good community participation...thank you!**
- 10+ active community participants
**Identified many important aspects of a reuse initiative**
- 35 problems and opportunities affecting reuse
- 5 additional guiding principles
- 8 program strategies
- 5 technical reuse enablement strategies
- 3 recommendations on evolution of the process
- 1 recommendation on use of reference architecture
**Details of inputs and recommendations included in following slides**
- Results are only lightly summarized

## Workshop Goals

**Develop high-level recommendations for reuse processes to be incorporated into a SEEDS management plan**
**Focus on cross-organizational enablement**
- Independent organizations will use their own processes

***ESE Reuse Process Definition***
* **Goals*
* **Principles*
*  **Strategies*

*Organizational SW Development + Reuse Process & Tools*

*ESE Reuse Enablement *
*Mgmt Plan*

***Organizational SW Process Definition***

*ESE Reuse Enablement Process & Tools*

## Workshop Format

**Participatory**
- Study team is only here to get discussion started and capture ideas
- Study team will synthesize results and plan follow-up sessions
**Focus on idea generation and capture**
- Identify as many good ideas as possible
- Considerations/possibilities are provided to help get you started
- Add/delete/change as you see fit
**Prioritizing recommendations to be done later**
- Consensus is not required at this point
- Remember: different environments may have different needs!
- Numbering of ideas is for reference only and does not indicate importance or priority
- Critiquing of ideas should be limited
- Criticizing the originator of an idea is not allowed
**Two teams**
**“****Mission critical”**: focus on “**improved** **clone & own**” reuse approach
- Driven by launch schedules and a need for daily, highly reliable production or archiving needs (e.g. SIPS, DAACs for standard products and high volume distribution)
**“****Mission success”**: focus on “**open source**” reuse approach
- Driven more by need for research in science, applications, or information systems, need to experiment with differing products, approaches, mechanisms and adapt to new understandings (e.g. ESIP-2s, -3s, analysis, etc.)

## Reuse Goals

**These are the ultimate qualitative and quantitative results that are desired from a reuse initiative**
**Established Goals**
- Reduce the cost of providing a given set of capabilities in ESE data systems, and thereby enable ESE data systems to better meet mission/science/application requirements within available budgets
- Increase the flexibility and responsiveness of ESE data systems to better meet mission/science/application requirements in a timely and cost effective fashion
- Increase effective and accountable community participation to better meet ESE goals
- Reduce technical/schedule/cost risks associated with developing ESE data systems

## Problems & Opportunities

**What are the positive and negative factors that contribute to the ability to reuse software and meet the stated goals?**
**Considerations/Possibilities**
- Intellectual property policies restrict sharing of reusable assets
- Mission-oriented funding does not encourage development of assets for reuse
- Developers of potentially reusable components do not have funding to document and support components for use by others
- Access to experts (esp., component authors) reduces the effort and risk associated with reusing a component
- “NIH”

## Problems & Opportunities – Community Input

**Mission Critical Environments**
- Modularity (+)
- Highly skilled workforce (+)
- Contractual relationships w/ vendors that limit access to software assets (-)
- Organizational bias to use certain software (-)
- Organizational knowledge about available software (+)
- Fit with application (+/-)
- Lack of contributions back to asset base (-)
- Lack of schedule/funds to make contributions to the asset base (-)
- Choice of language, esp. at beginning of mission may or may not current preference (+/-)
- Changes to languages/technology (-)
- Proven code that does a hard or expensive function (+)
- Test cases (+)
- Lack of time at the beginning of a mission or on first of several missions (not practical to redevelop after the fact) (-)
- No community infrastructure for reuse (e.g., asset library  moderator) (-)
- Ability to start a small/simple process...get it out there! (+)
- Recognition that reuse could shorten schedule or get preliminary functions/foundation up quickly (+)
- No existing library of usable assets (-)
- NASA culture/mission (technical and management) encourages new tech prototypes over reuse (-)

## Problems & Opportunities – Community Input

**Mission Success Environments**
- Ability to assume some risk in development (+)
- Knowledge of--and communication with--those who have software assets (+)
- Hesitation to share because code was not designed/documented to be shared (e.g., TRMM IDL viewer) (-)
- Modularity (+)
- Lack of incentive to reuse (e.g., no payment for support, mission-oriented funding, etc.) (-)
- Open source approach...inherently removes barriers, encourages design for reuse, improves quality, incorporates enhancements, results in feeling of shared ownership, etc. (+++)
- Licensing that requires contributions back to code base (+)
- Reuse approach established _within_ a development team (+)
- Acceptance of limitations in existing SW (same as COTS)  (+)
- Starting as open source vs. releasing to open source through lengthy export review (+)
- Issues regarding liability/copyright (-)
- Perceptions about security of open source- easy to find security holes (good if the good guys find them, bad if the bad guys find them) (+/-)
- Pride over authorship, control over functionality, and ability to match specific needs (-).
- Fear of having to support software released for reuse (-)
- Concern that effort to make it reusable will be wasted...asset might not be reused (-)
- Documentation not in consistent form (-)
- No ESE journal that supports advertising available assets (-)
- Perceived contribution toward interoperability (+)

## Guiding Principles

**What are the desired high-level attributes of a reuse initiative (and associated processes)?**
**Considerations/Possibilities**
- Defined by actual stakeholders in the ESE community
- Tailored to different environments rather than one-size-fits-all
- Starts simple and evolves
- Ensures a practical focus
- Leverages existing activities & organizations
- Enables but does not force reuse
- Has cross-organizational emphasis...does not dictate individual organization practices
- Provides recommendations and guidance, but is not prescriptive

## Guiding Principles – Community Input

**Mission Critical Environments**
- Training and knowledge accompanies software asset
- Different levels (granularity) of reuse can be appropriate
- New code developed should be written with reuse in mind
- Use competition to drive reuse
- Incentives to enable #3 above  (across missions)

## Guiding Principles – Community Input

**Mission Success Environments**
- Encourage reuse to be built into the original programming (e.g., team-programming approach, extreme programming)
- If you’re programming it right the first time, then sharing it is not a problem
- Everyone has ownership of the code
- Define criteria to determine appropriateness of reuse
- Reuse is not always appropriate: encourage reuse only in appropriate areas/components
- Focus on areas that are likely to be successful
- Feedback from community is needed to identify these areas
- Determine criteria for components to be included in open source repository
- Criteria can include community, size of community, interest of other communities in component (likelihood of reuse), structure of software
- Create open source authoring environment / infrastructure
- Determine the authority(ies) to modify open source software
- Include a cookbook for communities to be able to evaluate whether they should provide their software as open source
- Be scalable
- Define fast and streamlined approval process for proposed open source components
- Define peer-reviewed process for selecting components for open source

## Reuse Program Strategies

**What are the high-level plans of action for a reuse initiative that could be incorporated into a SEEDS program management plan?**
**Considerations/Possibilities**
- Establish two working groups (mission, science/apps) chartered with defining reuse processes and supporting architecture processes
- Establish a working group to develop program policies regarding reuse
- Establish teams to mine assets (how many?)
- Establish forums to share reuse practices
- Enlist software engineering specialist support (e.g, CMU Software Engineering Institute)
- Enlist stakeholder representatives (or proxies) into the formulation study team until working groups can be established
- Top down vs. bottom-up: Start w/ architecture and work down to components vs. start with high-payoff functions and work up to system level
- In-place vs. external: have authoring organizations provide reuse support vs. have one or more non-mission orgs support reuse efforts
**Check: does each program strategy follow the preceding principles?**

## Reuse Program Strategies – Community Input

**Mission Critical Environments**
- Start with single working group for mission critical reuse
- Use working group(s) to set the policies/targets for level of reuse
- Minimize effort expended on infrastructure to enable reuse
- Clearly identify originator of software
- Have authoring organization provide technical support for reused components (for efficiency)
- Provide additional funding to cover overhead for initial activities needed to advertise and package reusable code (this is not to be confused with re-writing for reuse)
- Facilitate communication needed for reuse
- Do not enlist software engineering specialist support (CMU is overkill)
- Develop proper incentives to facilitate reuse

## Reuse Program Strategies – Community Input

**Mission Success Environments**
-  Create environment for (conformance) testing
-  Validate actual need for components
-  Provide institutional support: create a program to encourage reuse
- includes computers and staff
- solicits software from community
- polls community for validation of components
- makes decisions about whether to support component
- designs testbeds for testing component
- identifies champion to oversee and support code
- publish what’s available
- Start with prototypes to test/show/compare success
- Leverage existing reuse-related resources (eg. Source Forge, Google) (issue with licensing)
- Start with something small, simple and general enough (for interest) and see if it works
- More general component is likely to draw broader reuse interest
- Try two prototypes: one involving outside communities and one involving ESE communities only
-  Do #4 first then #3
-  Reach out to outside communities that may have interest only in specific components
- Outside communities (in different domains) may share the need for specific components used in the ESE domain

## Reuse Enablement Strategies

**What specific plans of action and technical approaches should be used to accomplish the stated goals of a software reuse initiative?**
**Considerations/Possibilities**
- Establish a reusable component library
- Establish a testbed to help identify and qualify reusable components
- Empower a team of experts to evangelize reuse
- Develop a software experience library with links to experts, assets, and other resources
- Develop a reference architecture to enable component reuse by enhancing component compatibility
- Document architecture/design patterns to enable design reuse
- Establish policies and incentives that counteract disincentives to reuse (e.g., NIH)
- Provides tools (e.g., reuse library software) to support reuse activities
- Incorporate reuse into NASA development standards
- Use formal methods and application generators to assemble systems from existing assets
**Check: is each enablement strategy supported by a program strategy****?**

## Reuse Enablement Strategies – Community Input

**Mission Critical Environments**
- Develop software experience library with links to experts, assets, and other resources
- Do NOT focus on component library...#1 above is preferable
- Provide standard “checklist” of items that must be provided to make assets reusable; refine the checklist periodically
- Do NOT establish a formal independent testbed...“testbedding” should be done at provider and customer site
- Conduct reuse workshops/forums to share lessons learned,  advertise,  obtain ideas, etc.   at international meetings and other venues
- Document architecture/design patterns to enable design reuse
- Do NOT use formal methods and application generators to assemble systems from existing assets...this approach is overkill

## Reuse Enablement Strategies – Community Input

**Mission Success Environments**
- Host NASA open source workshops for awareness and training
- Collect and publicize success stories
- Clarify intellectual property issues
- Define management roles and responsibilities to encourage reuse (e.g., encourage team members to participate in open source forums)
- Provide incentives for sharing and reuse
- Identify and fund software to enable it to become successful open source  (e.g., improving quality, going through the steps to provide it as open source, active engagement with community, moderating, etc)
- Examine other institutional models (HP, IBM, other governmental organizations, universities)

## Evolutionary Processes

**In what ways can the process evolve over time?**
**Considerations/Possibilities**
- Strategy employed: enhancing communications  in-place-reuse  component library
- Specificity: Notional architecture  drill down to concrete architecture
- Formality: Prototype process  actual process
- Functional scope: highest-payoff functional areas/components  next highest areas

## Evolutionary Processes – Community Input

**In what ways can the process evolve over time?**
**Mission Critical Environments**
- Highly used module could over time be open-sourced
- End user feedback to original provider  (enhancements, bug fixes, etc.) acts like mini tech infusion, obsolescence fighter
- On-going participation of working group: more instances of reuse over time will help to map out the future directions
**Mission Success Environments**
- Start with prototype process and learn from experience
- Identify and extend existing tools to support community needs (e.g., extend ENVI to support HDF)
- Start with high payoff and highly reusable areas

## Reference Architecture Purpose

**How should a reference architecture be used to enhance software reuse?**
**Considerations/Possibilities**
- Enhance communications between groups with software assets to share
- Standardize definition/functionality of components to help categorize components, enhance compatibility, and enable components to be independently acquired
- Make near-plug-and-play integration of components possible
- Enable black-box plug & play

## Reference Architecture Purpose – Community Input

**Mission Critical Environments**
- Enhance communications between groups with software assets to share
**Mission Success Environments**
- Enhance communications between groups with software assets to share
- Standardize definition/functionality of components to help categorize components, enhance compatibility, and enable components to be independently acquired
- As a guide, communication mechanism
- Document set of requirements that a data system would meet (components needed, etc.)
- Enable reusing requirement specs
- Document criteria for accepting components
- Create a market for components

## Reuse Initiative Models

**What existing organizations and processes should NASA’s ESE use as a model for implementing a reuse effort?**
**Considerations/Possibilities**
- ESIP Federation IDL cluster (plug-in components)
- MODAPS/SeaWIFS/DODS (various strategies)
- Earth Science Modeling Framework (common tools, architecture/conventions)
- National HPCC Software Exchange (reuse tool broker)
- Reuse Information Clearinghouse (information dissemination)
- National Association of State Chief Information Officers ComponentSource (library)
- Workshop on Institutionalizing Software Reuse (information dissemination)
**Check: do the program strategies cover the key strategies used by these models?**

*Note: there was not sufficient time to address this topic during the breakout sessions*

## Wrap-Up: Community Input Highlights

**Mission Critical Environments**
- Don’t spend a lot of effort creating a reuse infrastructure
- Focus efforts on actual reuse efforts, not preparing for reuse
- Provide appropriate incentives to encourage reuse
**Mission Success Environments**
- Don’t spend a lot of effort creating a reuse infrastructure
- Use existing open source infrastructure (e.g., Freshmeat.net)
- Start with a simple process and evolve