JMX

Lessons Learned

Project Objective

November 2009

Create a statewide Juvenile Migrant database

To establish a prototype juvenile out-migrant data

exchange format for Washington

To share Juvenile out-migrant collection data

Ultimately to share other data streams regionally

(...still to be determined…)

What is the JMX?

A comprehensive database for juvenile migrant data along the lines of SGS

The JMX data exchange template should be thought of as a vehicle to share data in a common format.

JMX is a method to promote communication of primary and derived data.

JMX is a tool to promote collaboration.

JMX is an idea to encourage consistency.

What's in it? Steps to derive juvenile production estimates from primary data

(e) Expanded catch (f) Efficiency strata

Derived data #1

(i) Total production estimate

Derived data #3

(b) Catch data (c) Efficiency trial

Primary data (a) Trapping Period Information

(d) Individual data

(g) Stratified migration estimates

Derived data #2

(h) Extrapolated migration estimates

Our Approach:

Data Template Development

Juvenile out-migrant data collection survey based on HQ data widely circulated

Draft Data Template and Database Schema developed based on outcome of November (2009) Kick-off meeting. Draft data template includes cross walk with existing juvenile databases (RMIS, FPC, ISEMP ATM).

Created a DB schema and data flow configuration document outlining how data might move from field to central DB including sync w NWIFC data

Created a prototype database in use in Olympia and R5 to capture historic data

JMX Data Flow Tribal data sources

WDFW regional data sources

DB

DB

PSP Node

and/ or

Exchange Network

Something

Else

Other

Things

Complete Xfer

JMX

Node

JMX

Node

WEB

UI

WDOE

Node/

WQX

Something

Else Again

JMX Exchange Overview

NWIFC

Tribal Partners

Tribal Juvenile Migrant

Data Management &

Exchange Client

WDFW

Other Partners

Aquascape

Node

Node

WDFW Juvenile Migrant

Data Management

and Reporting System

Server

Exchange Network Node

Exchange Network Client

Datastore

Data Flow

Legend

Train-the-Trainer

JMX Exchange Summary

What will the JMX Exchange allow me to do?:

• Share juvenile migrant data with exchange partners (e.g., Tribes, NWIFC, WDFW, PSP and NMFS)

• Request and receive juvenile migrant data from NWIFC / WDFW supplied by JMX partners (e.g., other Tribes, PSP, WDFW, etc.)

Train-the-Trainer

Juvenile Migrant Client Summary

What will the Juvenile Migrant Client allow me to do?

• Search for, enter and manage juvenile migrant data

• Review raw data for abundance estimation purposes

• Provide juvenile migrant data to partners (e.g., WDFW, NWIFC)

• Request and receive juvenile migrant data from NWIFC / WDFW supplied by JMX partners (e.g., other Tribes, PSP, WDFW, etc.)

• View JMX Client Activity/Transaction Log

• Configure JMX Client

• Receive notification of data Submissions / Receipts / Errors

SCoRE

„CoRE?‟

Barriers Wild Hatchery

SoftData/

TOCAS

LIFT

BroodStock

People

FishBooks

HWS

SGS

SaSI FMPs

FRAM

Age &

Scales

Maint

PSSDB

H2O

Qual

CRC

JMX

FishDist

SSHIAP

Harvest

Actions

$

Wildlife

Fish

Habitat

Exists

In development

Does Not Exist

WGA DSS

Coord Asses

PSP SOS

Key

External Reporting Drivers

Why Brodie ..Why?!?

Greater transparency in the way we do our work

Ability to share data

A home for historical data in an era of Agency

institutional knowledge loss.

A way to document data collection and analysis methods

and protocols

A way to centralize JM data for consistent reporting

(hopefully alleviating some reporting requests placed on

field staff.

A model for regional datasets

Brodie, What else can I do with a node?

WDFW

Node

PSP

BPA Coord

Assessments

WGA

DSS

SoTR

GSRO

SoS

DART

????

Lessons Learned

General

Overall, The team thought the project ran smoothly.

From conception to implementation, the overall process was probably too long, due to a number of factors.: contractor availability, # of tribal entities, split systems & needs, etc. NWIFC/WDFW thought that accelerating this process next time would be helpful.

Due to the contractor, Windsor, getting involved later in the process, a readiness assessment was needed and some elements of the project were repetitive for the participants who were involved from the onset. NWIFC/WDFW would like to get Windsor involved earlier in the process to prevent repetition of concept communication, however this tradeoff comes at the cost of cost.

Project Exploration, Initiation &

Strategic Planning

This process could have been aided by having more consistent, executive level support/sponsorship from the PSP. Due to changes within the PSP organization, support waned as the strategic plan was being established.

It could have been helpful to get Windsor more involved in this process to help facilitate and coordinate this part of the process. There was a general feeling that if Windsor were involved earlier, the process may have been able to be accelerated.

The high-level strategy established during this process was effective in setting the stage for the project moving forward and was established with the appropriate level of details based on what was known at the time.

Project Scoping/Contracting

Given the planning work NWIFC/WDFW/PSP had performed

to this point, there was a clear vision for the effort and the

scope of the components needed was well defined.

The contracting process seemed to be smooth and without

issue as we were able to reuse many of the standards that

were established in the first WQX contract.

One key missing component in the JMX Exchange is a tool

that PSP (a consumer) can utilize to receive information from

the exchange. The exchange support PSP‟s ability to request

information from the NWIFC/WDFW Nodes, but PSP will

need to utilize the Node Client Lite tool or a Node to make

such a request and this will take some configuration.

Project Planning/Approach/Management

The meeting facilitation techniques utilized during the workshops helped keep the meetings and process clear, organized, focused and effective.

The approach/methodology utilized for project worked well. We discussed the possible use of an Agile development methodology and it was determined that given the number of parties involved and the limited availability of the team members, an Agile methodology may not be a good fit. The team thought the current waterfall approach (for NWIFC client and exchange template/ plugin development) was the best fit for the time being.

The monthly status meetings were scheduled at the appropriate times and keeping these to a ~ one hour meeting was effective.

The team was composed of the appropriate skill sets and representatives to progress the process effectively.

Design Due to the way the process evolved and some of the political issues

encountered, the data entry/management schema was established prior to the exchange/sharing schema. A fairly significant simplification process was required when establishing the unified exchange/sharing schema. In a perfect world, the exchange/sharing schema would be established first or at least in conjunction with the design of the data entry/management schema to prevent rework and divergent designs.

Probably would revisit the dual JMX design and explore some sort of third party hosting to mitigate political/ ownership concerns.

Defining the design of the user-interface using high-level mockups allowed the contractor to understand the desired intent and goals for the system while still allowing the contractor to have some flexibility to implement functionality in the most cost-effective manner. This approach seemed to work well and allowed NWIFC/WDFW to retain some budget at the completion of development which can be used to implement other important functionality.

It would have been helpful to involve non-NWIFC member tribes in the design process to engage them early on and to get their feedback on the design.

Implementation Development and Internal Testing

Everyone seemed happy with the development process.

System Testing

NWIFC would like to have at least three tribes actively involved in the testing effort next time. Three tribes were invited to test, but one tribe was unavailable and another tribe was only partially available to test. Next time, NWIFC thought it would be more effective to physically visit the tribes to confirm the system is correctly installed, walk them through the application functionality and to ensure testing actually occurs. In addition, it may be helpful to schedule (block out) testing time with each test tribe.

It was very helpful for NWIFC and the contactor to have one person (“a gate keeper”) at NWIFC triage, compile and communicate feedback to Windsor on issues that arose during testing. This allowed NWIFC and Windsor to better communicate and track the issues that arose.

WDFW more hierarchical structure naturally lead to a gate keeper model of communication.

Historical Data Compilation

Much woe experienced here

WDFW commenced with concurrent historical data entry, prior

to JMX mothership DB completion -- tighter reign on design

standards for these staging sets would be advisable in future

efforts.

Would‟ve been helpful to have a pre-developed template for

historical data

Some suggested that the loading of historical data should be a

second phase operation of the project after current Data entry

exchange was stabilized.