Burrows Exchange Notes 2006-01

From Earth Science Information Partners (ESIP)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Developing the ESIP Exchange will involve a number of iterations through the following five steps:

Vision Document

Purpose
We need a list of specific purposes that we can prioritize against cost.
Our general purpose is given in the Strategic Plan as follows, :
Federation_Strategic_Plan
Stakeholders
Definition
Not just users
Will want to estimate specific cost/benefit for features in relation to each stakeholder
Need to be able to show overall return on investment in relation to our prioritized purposes
Primary: Foundation, Federation, Partners
Secondary: Earth scientists, modelers, decision tool providers, education, decision makers
Components
Definition
The ESIP Exchange will be built from existing components.
What are they?
How do we estimate cost/benefit for incorporating each?
Base list
wiki.esipfed.org, esipfed.org, GOS2, GCMD, ECHO, ESG, CLASS, NOMAD
Scope
Definition
Which changes relate to which target purposes?)
Planned milestones, benchmarking, and target
Express targets as the tests that would show success for explicit stakeholder and explicit purpose

Requirements

Glossary
Functional Requirements (relating to ESIP mission)
Specify and prioritize elements from the various Federation Documents.
Capture viewpoints of each of the various stakeholders.
Nonfunctional Requirements (relating to technology and implementation)
Performance, Interoperability, Security, Hardware
Use Cases
Key scenarios that exemplify the functional and nonfunctional requirements
Raise each scenario to a family of use cases
Tests
Each requirement defined as an explicit test that would show success

Analysis and Design

This step depends on the evolving requirements and will involve managers and the implementors: Atlantic BT, NGDC, ESRI, etc. Budget contingencies and fund raising efforts should be a specific part of the design documentation.

Implementation

FEA Implementation Diagram.jpg
Figure 2. Federal Enterprise Architecture Implementation Diagram


This will involve staged implementation according to a sequencing plan depending at least initially on heavily recruiting already-existing components. We expect implementation to involve multiple components, each having their own separate implementation state, level-of-effort, and sequencing plan.


Deployment

Roll out and promotion
All components are currently deployed with a variety of levels of use. Advertising and marketing the integrated ESIP Exchange will take place for targeted communities based on tests at each stage of integration involving sample audiences. We are essentially “Building our ship at sea”.
Impact evaluation
At each stage we will set benchmarks and targets and evaluate performance.
Continual Redesign
As the system evolves we expect both evolutionary and revolutionary changes involving coordination and support from initially independent components. We hope to move from aggregates to become and integrated “system” across components and knowledge environments.


(I am using this page to begin a discussion that I hope will become the development plan (and eventual budget) for the ESIP Exchange. As of now, these are the comments of one person. (Howard Burrows 18:09, 20 January 2006 (EST)) This plan is based on a book by Jim Conallen entitled "Building Web Applications with UML Second Edition". In addition, it adopts elements of the Federal Enterprise Architecture (see Guide to FEA and e-Gov Site).)


FEA Reference Models.jpg
Figure 1. Federal Enterprise Architecture Reference Models


Eventually, it might be useful to construct the ESIP exchange using a collection of interrelated "reference models" as employed by the US Government in the Federal Enterprise Architecture.

The most important aspects of our development strategy are shown on the left and right of Figure 1. Construction will be driven by the "business" of the Federation as described in our Federation Documents. The result will follow a component-based architecture.

In addition, we will be performance-driven and will design-to-test (DTT).