Table by pengxiuhui

VIEWS: 14 PAGES: 26

									United States
Department of
Agriculture




  Enterprise Master Reference Tables
              Overview
                                    Version 3.5




 08/21/11       C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc   1
                                                            1
Table of Contents
1.0        Introduction .............................................................................................. 4

2.0        What is the Enterprise Master Reference Table System? .................... 5

3.0        Data Sharing ............................................................................................. 7

4.0        Benefits of the MRT System .................................................................... 8
      Agency flexibility .................................................................................................................................. 8
      Data is consistent across all systems ................................................................................................... 8
      Data is current across all systems ....................................................................................................... 8
      Duplication of effort is reduced .......................................................................................................... 8
      Time is saved on new development ..................................................................................................... 9
      Inconsistencies in data are highlighted .............................................................................................. 9
      Data-cleansing is reduced in the data warehouse .............................................................................. 9

5.0        Criteria for an MRT Table....................................................................... 11

6.0        Architecture ............................................................................................ 12
      Legacy Architecture............................................................................................................................12
      Redundant validation .........................................................................................................................12
      Loss of previous benefits ....................................................................................................................12
      Applications maintain competing sets of data ..................................................................................13
      Different update frequencies ..............................................................................................................13
      Data marts read directly from applications ......................................................................................13
      MRT Architecture ..............................................................................................................................13
      Authoritative Data Sources ................................................................................................................14
      Delivery System ...................................................................................................................................15
      Recovery and Backup .........................................................................................................................16

7.0        Business Rules ...................................................................................... 17
      General Business Rules.......................................................................................................................17
      Iterative Business Rules ......................................................................................................................17

8.0        MRT Metadata ......................................................................................... 18

9.0        Other Design Considerations................................................................ 19
      Geographic Information Systems (GIS)............................................................................................19
      Architecture of GIS.............................................................................................................................19

10.0       Master Data Strategy ............................................................................. 20

 08/21/11                        C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc                                                          2
                                                                             2
Appendix A: MRT Data ..................................................................................... 21

Appendix B: Project Team Composition ........................................................ 24

Revision History................................................................................................ 25




  08/21/11               C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc                        3
                                                                     3
1.0 Introduction
In a complex computing environment, it can be very difficult for all applications to
maintain a set of shared data that is current, accurate, and consistent with other
applications. This means that each application extracts data separately and from different
sources. This duplication of effort is expensive and labor-intensive, and makes data
sharing difficult if not impossible.
Previously, no consistent link or recognition of content existed between transaction
systems. Each of these individual systems was used as a data source for a corresponding
data warehouse. The historical approach had been to build stovepipe reference tables
from individual system resources, without an interface to other projects.
Usually applications contain two types of data. The first type is germane to a specific
use. It is unique and most often relevant to one business problem. An example of this
type of data could be financial data. The other type is common data. To a large extent,
common data shares meaning across a larger audience and multiple applications. A good
example of this type of data is county or state names.
Over the past two years, the Service Center Implementation Team (SCIT) agencies have
built various reference tables that provide data across major transaction systems. This
has been accomplished by creating a set of Enterprise Master Reference Tables
(MRTs), which become the single source of non-sensitive shared data for all transaction
systems and the data warehouse.




 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc       4
                                                                4
2.0 What is the Enterprise Master Reference Table
    System?
The Enterprise Master Reference Table System (MRT) consists of services provided to
business users and application development teams to streamline their programming
processes. This includes not only data, but also the relationships between the data and
the delivery system that updates and propagates them.
This overview document explains the architecture of the MRTs in support of systems in
FSA, NRCS, RD and OCIO while steadily moving towards a goal of standardized
common data.
The following is expanded detail of the core components of the MRT System:
Data
        The MRTs are relational database tables that contain a current and consistent copy
        of data from the original authoritative sources. This data is useful to multiple
        transaction systems and data marts, and it becomes the single source that these
        systems use for the shared data.
Transport
        The delivery system ensures that each of these tables are loaded from the original
        data sources and updated regularly as changes occur. The delivery system then
        propagates the tables in the form of standardized replicated MRT tables on the
        FSA, NRCS and RD Web Farms.
        These MRT tables are then accessed through various methods dependant upon the
        established procedures or requirements of the agency or application. Some access
        methods are Common Business Services, direct access to MRT tables, further
        downstream replication of MRT tables to support applications, replication to
        various data warehouses, and direct access to specific views for existing
        applications.
Consulting, Analysis and Expertise
        This service is provided by the MRT team due to their analysis of the data,
        familiarity with the complete scope of data and management of the repository. It
        consists of:
               Relationship management with authoritative data sources.
               In-depth analysis of data and metadata.
               Monitoring and quality control of transport processes.
               Consulting with users to derive the common standardized meaning from
                the data.
        Maintaining the integrity of the application specific data can often be a daunting
        task. Maintaining the common data can also be time consuming and costly. The
        effort required to identify where the data is located, validate its integrity, provide


 08/21/11            C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc         5
                                                                 5
       analysis and feedback for data cleansing, create the mechanism to regularly
       transport it between systems and monitor the performance is expensive and labor
       extensive. It is prudent to perform these activities once and then leverage the
       effort across agencies and applications. This eliminates the need for each
       application to develop the multiple feeds from a variety of sources to retrieve
       common data.
       By using these services, business users and application developers can focus their
       efforts on those activities relevant to development and management of their
       unique data requirements. Common data is synchronized with the authoritative
       sources and transported to a location readily accessible to the applications and
       business users. Essentially the developer only needs to understand what common
       data they require and how to access the data.




08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc      6
                                                               6
3.0 Data Sharing
Some MRTs will contain data that is useful to applications across all agencies, while
others will be relevant only to one agency. The tables will fall into the following
categories:
1. Table structure and contents are shareable across agencies – These tables will
   contain a data structure that is compatible with systems in more than one agency. In
   addition, the contents of the tables will be consistent across all agencies. The result is
   that one table can be used in more than one agency.
   Example: interest rate and non-sensitive employee data are shared across agencies
2. Data structure is shareable, contents are not – These tables will be present in more
   than one agency. However, the records in the table are distinct for each agency. In
   this situation separate views will be maintained for each agency.
   Example: state and county is maintained separately for FSA, NRCS, and RD.
   (A future goal is to eventually, when possible, migrate to a common standard set of
   state and county data)




 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc        7
                                                                7
4.0 Benefits of the MRT System
The creation of Enterprise Master Reference Tables provides many benefits. Each of
these is examined in more detail below.

Agency flexibility
Each agency has the ability to consume the MRT data in a manner that is appropriate for
their use. One agency may decide to set a policy that allows access to the MRT data via
Common Business Services while another may have a policy for direct application access
or further downstream replication of MRT tables.

Data is consistent across all systems
When applications pull data directly from different sources, it is very difficult to share
data between those applications. Because each application may use different methods for
retrieving the data from original sources, they may have different definitions and values
between these systems, and there may be no practical way to map these values to each
other.
Enterprise Master Reference Tables resolve that problem by extracting data from the
original sources, then providing a consistent data set to the applications. This consistency
has two key components:
   Records (completeness) – Where appropriate, all applications have the same records,
   with no records missing. This eliminates “holes in the data” which prevent
   applications from sharing data successfully.
   Values (accuracy) – Where appropriate, all applications have the same values for all
   data elements in the records.
In addition, each record contains all the data elements used by all the applications. So this
becomes a natural source for mapping values between two different applications. This
philosophy is called “everything for everyone” and is discussed in more detail in the
“Business Rules” section.

Data is current across all systems
In addition to ensuring data values are consistent between applications, the Enterprise
Master Reference Tables provide a current set of data that all the applications can share.
In the previous model, there was no way to verify that data in various applications had
data that was the same age. Applications frequently stored a local copy of data that was
months or years out of date. The Enterprise Master Reference Tables solves this
problem, because the loads and updates from original sources are performed once for all
systems.

Duplication of effort is reduced
Instead of each application bearing the burden of retrieving data from original sources, a
single data extract/update process is maintained for the Master Reference Tables. Then a

 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc        8
                                                                8
copy of the tables is maintained on each web farm for NRCS, RD and FSA to be used by
the various applications. This reduces the duplication of effort that exists when each
application references the original sources directly.
A prime example of this is the current development of the Interest Rate MRT. The
Department of Treasury issues interest rates. Then notices are sent to multiple
individuals and web sites for publication. Previously, the interest rates were manually
entered into various applications. Now, many interest rates are entered in the MRTs once
by an official data steward and many applications can share them.

Time is saved on new development
Pulling data from multiple sources can be a difficult and time-consuming part of new
development. Each new application that repeats this process is essentially “re-inventing
the wheel” of analysis that was performed in another application. The MRT system will
provide a single authoritative source of current, consistent data with well-defined
methods for access and receiving updates.
   REAL-WORLD EXAMPLE
        The Rural Utilities Service Loan Servicing System identified a need for several
        daily U.S. Treasury interest rates. The rates were available in XML files on
        Treasury’s web site. The MRT team developed a process to pull the XML files
        and load the interest rate data into the Interest Rate MRT, thereby removing this
        time-intensive task from the application development team’s schedule.

Inconsistencies in data are highlighted
Once Master Reference Tables have been created, they can be used to validate existing
data in each application. In the current architecture, each application is responsible for
loading its own data from original sources. Once the table is deployed, it can be used to
identify missing records or inconsistent values.
   REAL-WORLD EXAMPLE
        This inconsistency in data was uncovered by the implementation of the Interest
        Rate MRT. During the load of the Interest Rate MRT, data from existing
        production databases were compared to the original interest rate notices. Several
        inconsistencies were identified; i.e., gaps in data, time periods where more than
        one interest rate was entered and incorrect rate values.

Data-cleansing is reduced in the data warehouse
When data is imported into a data mart from production systems, inconsistencies in the
data must be resolved. This can be a time-consuming and costly step if the source data
contains many inconsistencies.
But in the MRT system, this work has already been done during the creation of the
Master Reference Table. So this data can be cleanly replicated into the data warehouse
and used by all the data marts.



 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc          9
                                                                9
       REAL-WORLD EXAMPLE
             Currently, while working through the “County Codes” for FSA, FLP
             (PLAS), CMA, LSA and DMA it was discovered that applications
             “understood” their County Codes to mean different things. For example,
             County Code means Split Counties, Offices, Servicing Areas and true
             FIPS Counties. (See diagram 1 for example)


       FIPS Alaskan Boroughs                                 FSA Alaskan Location Areas




       RD Alaskan Location Areas                         NRCS Alaskan Location Areas




       Diagram 1: Alaska boroughs and location areas




08/21/11          C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc      10
                                                             10
5.0 Criteria for an MRT Table

MRT tables are identified in multiple ways based on business need. The MRT Oversight
Group with representatives from FSA, NRCS and RD can recommend they be developed
or an application group or business user from any service center agency may identify an
MRT data requirement. Once the business need has been identified and the data has been
requested, it will be presented to the MRT Oversight Group for approval to be
implemented. In general, the following criteria are used to identify data that qualifies as
an MRT:

     Used by more than one application
     Standardized MRT
     Updated from an authoritative source
     Supports multiple OLTP, Data Marts and specific views
     Has a Business Sponsor




    08/21/11         C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc     11
                                                                11
6.0 Architecture
The following information compares the Legacy Architecture to the Master Data
architecture. Although the Master Reference Tables are in production at this time, many
of the attributes of the Legacy Architecture still exist in the service center agencies.

Legacy Architecture
Much of the legacy architecture had several qualities that led to difficulties in data
sharing. These are described in more detail below:




Redundant validation
Because various applications are maintaining separate sets of data, each production
system performs validation independently. This leads to a duplication of effort, and
when inconsistencies are found in the data, each application uses different methods for
resolving them; therefore, inconsistent business rules are employed across all systems.

Loss of previous benefits
As new applications have been developed or re-engineered on new platforms, their
databases and sources of common data changed. Frequently these applications chose to
store the common data in their application database, rather than develop the methods for
retrieving the data from their old source. Thus the concept and benefits of the common
data were lost.




 08/21/11            C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc      12
                                                                12
   REAL-WORLD EXAMPLE
        For FSA, the System/36 SCOAP tables previously provided a consistent shared
        set of data for name and address and state and county use. The AMANAM table
        had all the information that other systems needed for these tasks; however, this
        system is no longer used by other applications as the single source of data.

Applications maintain competing sets of data
In the current data sharing architecture, several different versions of data are maintained
by separate production systems. This data is accessed directly by various applications,
and in many cases they maintain a local copy specifically for the application. The end
result is that many copies of the shared data are being maintained – even on the same
platform.

Different update frequencies
No coordination is currently done to make sure that updates are synchronized across all
applications; therefore, each separate set of data may be updated from the original
sources at different intervals.

Data marts read directly from applications
The data warehouse faces a similar problem in the current architecture. Individual data
marts retrieve data from production systems and maintain a copy of that data for their
own use.
This duplication of data is a waste of storage. In addition, the data marts end up in a
similar situation to the production systems – this shared data becomes un-shareable due
to its inconsistency.

MRT Architecture
The MRT architecture resolves many of the data-sharing issues that exist under the
previous architecture. They are addressed in more detail below.




 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc       13
                                                               13
Authoritative Data Sources
Part of the analysis for creating a new Master Reference Table is to determine which
production systems or tables will serve as the authoritative data source for the table.
This analysis may reveal that a single system exists with the set of data to be included in
the table. In other cases, there may be several potential data sources and they must be
reconciled.
The tables can be arranged into the following categories, based on the source of their
data:
1. Production system becomes the Master Reference Table – If a production system
   is found that can serve as the single authoritative data source, this system becomes the
   de facto authoritative data source for the MRT.
2. Multiple sources feed a new MRT – If several valid original sources are identified,
   an MRT is created and updates are fed from these sources.

   REAL WORLD EXAMPLE
       The Country MRT was created using information from both FIPS Publication 10-4
       and ISO 3166. These sources have different sets of codes to represent countries.
       The Country MRT includes both sets of codes and includes a cross-reference

 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc       14
                                                               14
       between the two sets where applicable. In addition, there were several records in
       each source that did not exist in the other. All these records are included in the
       MRT, with a special annotation for each source in which they are contained.

3. A new MRT is created from generated data – Data for the MRT is generated using
   an outside process and loaded into a new MRT. There is no original source to feed
   data into this MRT.

   REAL WORLD EXAMPLE
       The Calendar MRT combines the traditional calendar with federal holidays,
       workdays, and fiscal year. For the initial load of this table, twenty years (1990-
       2010) of information was generated in Microsoft Excel, and loaded into the Master
       Reference Table. Future additions to the data will be loaded in a similar fashion.

4. A new MRT is created with a data entry application – A new MRT is created
   along with some type of application for entering data directly. There is no
   authoritative source to feed data into this table. A formal Data Steward methodology
   is also identified and implemented.

   REAL WORLD EXAMPLE
       The Interest Rate MRT contains information that is shared among the service
       center agencies. This information is updated on a regular basis by authorized data
       stewards using the MRT Data Steward Application. This data is then sharable by
       all applications that require Interest Rate information.


Delivery System
The delivery system contains all the processes necessary to propagate the MRTs to the
transactional and data warehouse systems. The primary methods currently used to
propagate MRT data are SQL Server Replication and the Ascential DataStage Extract,
Transform, and Load (ETL) tool. The scheduling of these updates varies according to the
requirements of the individual MRT table.

References:
MRT Production Architecture Diagram
I:\INFOMGMT-Internal\Projects\MRT\Deploy\MRT Architecture\Diagram\MRT and
Related Architecture – Production.ppt

MRT Database Environments Document
I:\INFOMGMT-Internal\Projects\MRT\Deploy\MRT Architecture\Document\MRT
Database Environments 2.1.doc




 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc         15
                                                               15
  Destination            Platform          Technique          Additional software
                                                              required
  Kansas City web        SQL Server        SQL Server         none
  farm                   2000              replication

  Ft. Collins web        SQL Server        SQL Server         none
  farm                   2000              replication

  St. Louis web          SQL Server        SQL Server         none
  farm                   2000              replication

  FSA data               Informix IDS Batch ETL               Ascential DataStage
  warehouse              9.40         processes

  FSA mainframe          IBM DB2 on        Batch ETL          Ascential DataStage
  DB2                    mainframe         processes

  FSA DB2 in web         IBM DB2 on undetermined              undetermined
  farm – no current      Windows NT
  requirement


Recovery and Backup
The Master Reference Tables are hosted in SQL Server 2000 databases in the FSA web
farm. These databases are subject to the standard backup and recovery procedures
executed by the web farm staff. In addition, the MRTs are replicated nightly to the
NRCS web farm via the EDARCH Storage Area Network (SAN) system.




 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc   16
                                                               16
7.0 Business Rules

General Business Rules – Apply to the project as a whole:

1. Everything for everyone
   Previous efforts at data sharing between agencies have been limited to data elements
   that were shared across all systems. These were identified as being “useful to link
   whole sets of data or even whole systems.”
   In contrast, the Enterprise Master Reference Tables will contain a rich superset of all
   fields used by all agencies, including non-standard codes. Each application can use
   the elements that are useful to them, and ignore the additional fields.

Iterative Business Rules – Applied to each MRT sub-project individually:
1. Official source of data
   An official source or sources are identified for each Master Reference Table. These
   may be current production systems, or new data, which is generated or entered
   specifically for this MRT.
2. Audit controls
   Audit control processes are defined to capture changes to the data. This may take the
   form of an audit field in the Master Reference Table or a separate audit table. The
   amount of audit control information captured depends on individual requirements
   from the business sponsor or the table data stewards.
3. Security
   Rules are defined regarding which users and applications are allowed to view or
   change the data. The sensitivity of each MRT’s data is the primary driver of this
   decision.
4. Outputs
   Business rules are defined concerning which platforms receive updates from the
   Master Reference Table. OCIO, service center agencies, business sponsors and
   application developers provide input into this decision. Availability of the platform
   and cost are also considered when making platform decisions. The timing of the
   updates and the methods used to propagate the data is determined by the MRT team
   based on business and technical input.




 08/21/11           C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc        17
                                                               17
8.0 MRT Metadata
Understanding data contained within the Master Reference Tables is vital. Metadata for
the MRTs, including table and element business names, data element definitions, data
types, sample domain information, and various physical name implementations are all
captured in the Enterprise Metadata Repository (EMR). The authoritative sources for the
MRTs are also referenced.

The EMR contains metadata that has been documented by working with application
developers and business sponsors to provide a common understanding of the systems
utilized by OCIO-ITS and Service Center agencies. It is available to business sponsors,
managers, developers, and end users. In order to access the EMR, a user must have a
Level 2 eAuth ID.

The EMR can be accessed at the following URL:
https://metadata.sc.egov.usda.gov/web-emr/




 08/21/11          C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc    18
                                                              18
9.0 Other Design Considerations

Geographic Information Systems (GIS)
The USDA is developing many GIS applications. These are generally web-enabled
applications that display key information using maps. These applications allow users to
view data at a national level, and then drill down to get additional detailed information.
Many of the MRTs contain information related to geography, such as countries, states,
counties, and congressional districts. For this reason, several GIS applications are
already using the MRTs in a variety of ways:
     Cross-references to Standard Codes
      The FSA/ITSD/GISC is currently using the State and County MRTs to provide the
      cross-reference between FIPS and FSA county codes so that FSA data (using FSA
      codes) can be displayed on a national map (using FIPS codes). Examples of this
      include the AS/400 Backup Status Map and the AS/400 Storage Space Map.
     Authoritative Source for Textual Attributes
      The MRTs provide textual attributes such as names, descriptions, and abbreviations
      for GIS applications. An example of this is the Congressional District map
      application. Another is FSA Debt GIS Website; the MRTs will provide cross-
      references between the FIPS and FSA State and County codes for GIS applications
      related to the FSA Financial Data Marts.

Architecture of GIS
The data-driven, web-based GIS applications are developed by FSA/ITSD/GISC using
ESRI software tools, which are integrated with the SQL Server 2000 DBMS.
Application summary data is extracted from the source application database on a
scheduled basis, and loaded to the SQL Server 2000 database on the ESRI ArcSDE
server. At that point, the data is combined with the MRT data and displayed in web-
enabled maps, using ESRI ArcIMS.




    08/21/11          C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc      19
                                                                 19
10.0 Master Data Strategy
The future of the MRTs is bright and new uses of the data are continually being
discovered. Some of the immediate future considerations are as follows:


     Web Services
     Provide select MRT data on public site for 3rd party business users to access
     Continued development of newly identified common shareable data sets




    08/21/11          C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc   20
                                                                 20
                                Appendix A: MRT Data
           Table              Agency           Estimated                 Status                Source and
                              Usage         Production Date                                    Key Points
Calendar                        FSA                                  Production                Includes
                               NRCS                                                             Federal
                                RD                                                              Holidays
State and County                FSA                                  Production                FIPS, FSA
                               NRCS                                                             Split counties
                                RD                                                             CMA, LSA,
                                                                                                DMA
                                                                                               Linking to
                                                                                                GIS data
State and County (FLP)           FSA                                 Production                FLP (PLAS)
                                 RD
OIP Lite                         FSA                                 Production                Site, Office,
                                NRCS                                                            Servicing
                                 RD                                                             Area, Office
                                                                                                Closure
ICAMS Lite                       FSA                                 Production                Employee
                                NRCS                                                            Details –
                                 RD                                                             non-sensitive
                                                                                               Terminated
                                                                                                Employee
                                                                                                Detail (most
                                                                                                current six
                                                                                                months)
Interest Rate                    FSA                                 Production                ACIF Rates
                                NRCS                                                           KCFO Rates
(approximately 52                RD                                                             – FSA
different rates)                                                                               Penalty
                                                                                                Charge
                                                                                               LIBOR
                                                                                               Current
                                                                                                Value of
                                                                                                Funds –
                                                                                                Treasury
                                                                                               Daily
                                                                                                Treasury
Congressional District          NRCS                                 Production                Census Data
                                 FSA
Country                          FSA                                 Production                ISO-3166
                                NRCS                                                           Purchased
                                 RD                                                             Data set


     08/21/11            C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc                21
                                                                    21
          Table                Agency           Estimated                 Status             Source and
                               Usage         Production Date                                 Key Points
Race & Ethnicity                NRCS                                  Production             OMB
                                 FSA                                                          standards
Indian Tribe and Tribal         NRCS                                  Production             Sourced by
Land                             FSA                                                          Federal
                                                                                              Register as
                                                                                              provided by
                                                                                              Bureau of
                                                                                              Indian
                                                                                              Affairs
Organization                      FSA                                 Production             NFC data
                                 NRCS
                                  RD
                                  ITS
eAuthentication                   FSA                                 Production               ERSR, others
Common Employee                   FSA                                 Production               ERSR, others
Database (CED)
Disaster Counties                RD                                   Production               FEMA data
Zip Code Cross                 FSA, RD,                               Production               3rd party data
Reference                       NRCS                                                            set
City                             FSA         Phase I                  Analysis                 US Cities
                                NRCS         Phase II                 Candidate                Foreign
                                 RD                                                             Cities
Conservation Codes               FSA         TBD                      Candidate –              NRCS has
Conservation                    NRCS                                  FSA Business              NRT
Component List                                                        Interest                 NRCS
                                                                                                waiting for
                                                                                                feedback
                                                                                                from NRCS
                                                                                                business
                                                                                                managers
County Demographic               TBD         TBD                      Identifying              For GIS
                                                                      source                    purposes
                                                                                                ESRI/Census
                                                                                                Bureau shape
                                                                                                files
Land Classification               FSA        TBD                      Analysis                 Requested by
                                 NRCS                                                           NRCS
                                                                                               Project on
                                                                                                hold – Carol
                                                                                                Ernst lead
Agency                                       TBD                      Candidate                NFC data
                                                                                                source
CBAPIMS – Program                NRCS        TBD                      Candidate –              Program

     08/21/11             C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc               22
                                                                     22
            Table          Agency           Estimated                 Status             Source and
                           Usage         Production Date                                 Key Points
data                        FSA                                   NRCS pilot              Delivery,
                             RD                                                           Program
Farm/Tract                  FSA          TBD                      Candidate              PARMO data

Watershed                    NRCS        TBD                      Candidate                NRCS
                                                                                            requested

Standard Animal ID            FSA        TBD                      Candidate                FLP
                              RD                                                           Used by
                                                                                            disaster
                                                                                            recovery
Standard Crop Codes           FSA        TBD                      Candidate                FLP
                                                                                           Not FSA
                                                                                            Codes
                                                                                           Universal
                                                                                            Codes
                                                                                            provided by
                                                                                            3rd party
                                                                                            software
                                                                                            vendors
Commodity                     FSA        TBD                      Candidate                FLP
                                                                                           Many people
                                                                                            need this
Ports of Export               FSA        TBD                      Candidate                Export
                                                                                            Operations




       08/21/11       C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc              23
                                                                 23
                 Appendix B: Project Team Composition
       Name            Agency/                     Role                 Phone
                       Division
Paul Chevalier      FSA/ITSD/OTC/          DBMO Chief              816-823-2455       MRT Responsibility
                        DBMO
David Butler            NRCS               MRT Oversight           970-295-5545       Subject Matter Experts
Edward Lindblad           RD               Group                   314-335-8143       and Technical Support
Paul Sperling             FSA                                      816-926-2141
Cheryl Pallas             ITS                                      816-926-1965
Norma Westbrook          OCIO              Project Team Lead       816-926-2688       Task Lead
                     ITS/IOD/IMB




     08/21/11       C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc          24
                                                               24
                                    Revision History

Date        Version     Summary of Change                                           Author
4/24/02     0.1         Initial Creation                                            Ryan Day - EDS
                                                                                    Paul Whitmore – IMSD
7/19/02     1.0         Apply updates from first review for MRT Kick-off            Ryan Day – EDS
                        Meeting
11/15/02    1.1         Apply updates from second review -                          Ryan Day – EDS
                                                                                    Cheryl Pallas – IMSD
1/23/03     1.2         Incorporate State and County Graphics to explain            Cheryl Vukas – EDS
                        how each agency views county data                           Cheryl Pallas – IMSD
7/11/03     1.9         Update document for presentation to Interest Rate           Cheryl Pallas – IMSD
                        FMD/WDC audience.                                           Ryan Day – EDS
2/3/2004    2.0         Update document to provide current MRT system               Cheryl Pallas – EDMSO
                        descriptions and status for FLP business sponsor.
2/4/2004    2.1         Removed Producer Name and Address as MRT,                   Ryan Day – EDS
                        replaced with State and County MRT, Interest                Cheryl Pallas – EDMSO
                        Rate MRT examples. Removed Data Sharing #3
                        category, no longer valid, it is now a NRT (NRCS
                        Reference Table). Under Delivery System
                        removed look-up tables bullet, no longer valid.
                        Removed references to “conformed dimensions”
                        replaced with “replicated MRT” verbiage.
2/6/2004    2.2         Added “Other Design Considerations” GIS section             Cheryl Pallas – EDMSO
                        back into document from previous version.
2/25/2004   2.3         Replaced Producer Name and Address examples                 Ryan Day – EDS
                        with other MRT examples.
                        Updated the Other Design Considerations: GIS
                        section with more recent information.
2/26/2004   2.4         Removed Abbreviation and Acronym from                       Cheryl Pallas – EDMSO
                        Appendix B: MRT Status. These two tables will
                        be provided in the Enterprise Metadata Repository
                        database
5/11/2005   2.4         Updated architecture diagram to include eAuth               Ryan Day – EDS
                        and CED.
5/13/2005   2.4         Updated architecture diagram to represent FSA-              Ryan Day – EDS
                        specific destinations.
6/23/2005   2.5         MRT team review and update of entire document               Cheryl Pallas – OCIO
                        for current representation of overall MRT project           Gloria Roth Robinson –
                        and services.                                               EDS
7/15/2005   3.0         Completed updates from 7/6 meeting:                         Ryan Day – EDS
                        - Applied various changes to wording and
                        grammar.
                        - Updated verb tense to reflect that the MRT is a
                        production system instead of a future system.

08/21/11          C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc           25
                                                             25
                        - Modified Alaska diagram to fit within margins.
                        - Clarified FSA-specific sections.
                        - Added section numbers to all sections.
                        - Removed Appendix A: Comparison of Terms
                        - Renamed Appendix B:MRT Status to Appendix
                        A
                        - Removed Appendix C: Pilot Tables in FSA DW
                        - Renamed Appendix D: Project Team
                        Composition to Appendix B
                        - Renamed Appendix E: Revision History to
                        Revision History
                        - Updated Delivery Systems table in MRT
                        Architecture section.
                        - Updated Appendix A:MRT Status to include
                        CED and eAuthentication.
                        - Updating indentation in Table of Contents.
07/25/200   3.0         Apply changes from Bill Hardrict, added Gene                EDS – Ryan Day
5                       Renken to Appendix B: Project Team
                        Composition, added section 8.0 – Metadata.
8/4/2005    3.1         Updated Appendix A title to MRT Data                        Cheryl Pallas – OCIO-
                                                                                    ITS
8/14/2006   3.2         Updated Appendix A and Appendix B to current                Cheryl Pallas – OCIO-
                        status for MRT data                                         ITS
1/19/2007   3.2         Updated terms on MRT architecture diagram.                  EDS – Ryan Day
11/14/200   3.3         Updated URL to web metadata. Added version                  EDS – Ryan Day
7                       number to document name.

11/14/200   3.4         Updated team composition.
7
4/10/2008   3.5         Updated structural inconsistencies.                         EDS – Cindy Fickess
9/8/2008    3.5         Updated with FSA organization information.                  EDS – Ryan Day




08/21/11          C:\Docstoc\Working\pdf\c49524bb-558d-449d-932f-2219e03a3354.doc           26
                                                             26

								
To top