Data Deployment Process Improvement Report

For Program: Data Access and Dissemination System (DADS)

Version No: Version 1.0

Draft as of October 10, 2006

The only controlled copy of this document is the on-line version
maintained in the DADS repository. User must ensure that this or any
other copy of a controlled document is current and complete prior to
use. Document owner must authorize all changes. Users should discard
obsolete copies.

Revision History

  -------- -------- ------------------------------------- ---------------
                                                          

                                                          
  -------- -------- ------------------------------------- ---------------

  ------------------- ---------------------------------------------------
                      

                      

                      

                      

                      

                      

                      

                      

                      

                      

                      
  ------------------- ---------------------------------------------------

Table of Contents

[1. Introduction 3](#introduction)

[2. scope and approach 4](#scope-and-approach)

[3. High level overivew of dads current "back-end" operations for data
dissemination
5](#high-level-overivew-of-dads-current-back-end-operations-for-data-dissemination)

[3.1. Overview 5](#overview)

[3.2. Description of Current Environments
8](#description-of-current-environments)

[3.3. Description of Current Tools and Associated Use
9](#description-of-current-tools-and-associated-use)

[3.4. Key Business Operations Terminology
9](#key-business-operations-terminology)

[4. Requirements 12](#requirements)

[4.1. Product Release Planning 12](#product-release-planning)

[4.2. Product Development and Configuration
14](#product-development-and-configuration)

[4.3. Product Validation and Verification
17](#product-validation-and-verification)

[4.4. Product Deployment 18](#product-deployment)

[4.5. Product Maintenance and Support
20](#product-maintenance-and-support)

[4.6. Product Development and Configuration
28](#product-development-and-configuration-1)

[4.7. Product Validation and Verification
36](#product-validation-and-verification-1)

[4.8. Product Deployment 41](#__RefHeading___Toc152740748)

[4.9. Product Maintenance and Support
48](#product-maintenance-and-support-1)

# Introduction

## 

## 

## 

## 

1.  
2.  
3.  
4.  
5.  

## scope and approach

## 

1.  

```{=html}
<!-- -->
```
6.  
7.  
8.  
9.  

## 

-   
-   
-   
-   

```{=html}
<!-- -->
```
-   

## High level overivew of dads current "back-end" operations for data dissemination

## Overview

The mission of the DADS Program is to prepare, tabulate, and disseminate
products that are complete, accurate, and formatted properly, on time
and within budget. In order to effectively accomplish this mission, DADS
has developed a comprehensive set of policies, processes and procedures;
technology tools, systems and infrastructure; and teams with varying
skills and focus areas to support the fulfillment of this mission. One
of the core components of this Enterprise System is the DADS "Back-End"
Operations for Data Dissemination. The DADS "Back-End" Operations for
Data Dissemination is the set of processes, procedures, tools, schedules
and environments currently used to acquire, extract, transform, load and
present approved products through the American Fact Finder (AFF) System.

For the purposes of this initiative, the Business Team decomposed the
DADS "Back-End" Operations for Data Dissemination into five core phases:

1.  **[Product Release Planning]{.underline}**. The primary objective of
    the Product Release Planning phase is to establish a common
    understanding of the scope, schedule and cost of the product
    release. Clear communication of the scope of the product release in
    terms of size, timing (i.e., release approach), products, and review
    capabilities establishes a common level of understanding between
    DADS and the data provider. Planning includes discussions with the
    data provider or sponsor, analysts, etc., who are involved with the
    release as well as the DADS internal team. This phase also involves
    verifying and confirming that the product release aligns with DADS
    and Census Bureau strategic objectives.

2.  **[Product Development and Configuration]{.underline}.** Based on
    the plans developed during Product Release Planning, several
    activities occur to process the delivered data and configure the
    products and application functions for the ultimate purpose of
    disseminating a census or survey. This requires the receipt of data
    and metadata, the creation of metadata, and the extraction,
    transformation, and load of data and metadata. These activities must
    be performed in order to enable Product Deployment as well as
    Product Validation & Verification.

3.  **[Product Validation and Verification]{.underline}**. The goal of
    this phase is to enable internal (Testing Team) and external (Data
    Provider) review, validation, testing and approval of the data
    products prior to dissemination on AFF. The primary business
    objectives of this Product Validation and Verification phase are to
    ensure quality and accuracy of the data products that will be
    disseminated via DADS Business Operational System; to support the
    Data Provider's product design using DADS services and systems; to
    provide validation activities to ensure that data provider
    specifications and agreed upon requirements are met; to provide a
    process to identify, manage and resolve errors; and to provide a
    process to manage corrections.

4.  **[Product Deployment]{.underline}**. The Product Deployment Phase
    establishes the existence of data and metadata in one of the DADS
    environments within an agreed upon timeframe. The activities in this
    phase include deploying the product; as well as creating a
    deployment plan and test report to document the outcome of the
    deployment. The Product Deployment Phase requires communication
    between the data warehouse team, the application development team,
    the system test team, BOC members on the DADS team and BOC data
    providers who are external to DADS. The objective of communication
    between these stakeholders is to ensure a smooth product deployment
    process and accurate dissemination of the product. The BOC (DADS
    team members and data providers) is involved in the product
    deployment process even in the development environment known as
    "dry-run." The choice to involve the BOC early in the deployment
    process is meant to accommodate the need for early preview and
    verification of the data and metadata, especially for bi-monthly
    Economic data, but also other data providers on an "as-needed"
    basis.

5.  **[Product Maintenance and Support]{.underline}**. The primary goal
    of this phase is to ensure the continued availability of the Product
    via a set of pro-active and re-active procedures. In general,
    pro-active procedures apply to all Products; These are procedures
    which have been setup for AFF and apply regardless of the number of
    Products currently available in AFF. Re-active procedures generally
    apply to specific Products and are initiated by a specific event,
    for example, an email inquiry.

The DADS "Back-End" Operations for Data Dissemination supports both new
and on-going product deployments. The operational system relies on the
inputs from several data sources, including members of the DADS
organization. The inputs are then transformed and stored within the DADS
data warehouses, metadata repositories and databases. The Virtual Table
Generator (VTG) application and Extract-Transform-Load (ETL) scripts are
two of the major mechanisms that are used to transform the inputs
received from the Data Sources. The outputs of these processes include
ASCII files or Oracle data. The following high level diagram depicts the
current Data Deployment Process.

![](media/image4.png){width="5.3875in" height="4.270833333333333in"}

1.  Receive Deliveries and Prepare Transformation Inputs

Data is delivered to DADS in a wide variety of data formats, such as
ASCII files (e.g., for product metadata), SAS files (e.g., for ACS base
tables), or binary shapefiles (e.g., the spatial file deliveries from
GEO). Data are provided as microdata or already aggregated data,
depending on the source program. Metadata are delivered by the data
owners, created by DADS, or manufactured using the VTG. The following
data are delivered as a part of the current operational system for data
dissemination:

-   Data Files (DEC, PEP, ACS, and ECON Files) -- Aggregated data from
    the associated program. This data are delivered in either SAS or
    ASCII format. The frequency of delivery depends on the program.

-   Non-Spatial Geographic Data Files -- Non-spatial geographic (NSG)
    data for each program support data processing of both micro and
    aggregated data. The NSG data files contain records that describe
    the geographic content of specific Census surveys and general
    orienting feature such as roads and railways.

-   Spatial Geographic Data Files -- ESRI shapefiles from Geography
    Division, as specified by DADS. The spatial files are loaded in
    ArcSDE and support the three main AFF mapping features -- (1)
    Thematic Maps (data visualization); (2) Reference Maps; and (3)
    Map-based selection of one or more geographic areas in support of a
    data query.

-   Address Files -- Address data that supports AFF search function is
    obtained from an external vendor, Sagent.

-   Data Warehouse Maintained Metadata (DWMM) -- Metadata produced by
    DADS that support AFF application processing including navigation
    within the site.

-   Product Metadata -- Metadata from the associated program that
    support the rendering of a program's data or derived products
    through AFF. Depending on the program, this metadata may be supplied
    by the data provider, or created by DADSO. The Virtual Table
    Generator (VTG) tool, based on inputs provided by the data provider,
    creates a subset of the Product Metadata to support the rendering of
    derived products through AFF.

-   1.  Execute ETL Processes

The data are transformed and loaded into the DADS data warehouses and
metadata repositories that support AFF. Data Transformation is different
dependent upon whether DADS is processing metadata, data, non-spatial
geographic data or spatial geographic data. Metadata is loaded or
transformed into the Metadata Repository. Some of the metadata is
provided by the Data Providers and some is created by DADS. Data is
loaded or transformed into the data warehouse. Data are provided by the
data providers. Non-spatial geographic data is loaded into the Metadata
repository. Some of the non-spatial geographic data is propagated into
the data warehouse. To support mapping and search, spatial geographic
data and address data are loaded into the spatial database.

### Store Data and Metadata for Testing and Deployment

-   **[Metadata Repository]{.underline}** - The metadata repositories
    are used by the AFF to present the data products to the users and to
    manage many pieces of the navigation in the system. The Non-spatial
    geographic data files, the Data Warehouse Maintained Metadata and
    the Product Metadata are stored in the metadata repositories.

-   **[Data Warehouse]{.underline}** - Aggregated data are supplied by
    the data providers. The data warehouse is used to store the data
    files and some non-spatial geographic data files. The data warehouse
    is designed as star schemas to assist with the data processing and
    performance of AFF.

-   **[Spatial Databases]{.underline}** - The Spatial databases support
    the map rendering functionality of AFF. The spatial databases store
    the Spatial Geographic Data files and the Address files. The design
    of the Spatial Databases is dictated by the proprietary ESRI
    Application.

## Description of Current Environments

DADSO environments exist to support the design and development of the
systems as well as on-going data deployments. These environments are
referenced as Development (Dev.), Product Assurance (PA), Internal
Review (IR), and Production (PROD).

![](media/image5.png){width="5.135416666666667in"
height="0.8854166666666666in"}

### Development Environments

The Development Environment houses the data as the data products are
being developed and configured for release. The development environment
has a dedicated Metadata Repository, data warehouse and spatial
database. The Dry Run service is provided in the Development
Environment.

### Product Assurance/Internal Review Environments

The Product Assurance/Internal Review Environments house the data that
is being validated and is pending approval for public release. The two
environments have separate Metadata repositories and share the data
warehouse and spatial database. Data housed in the Product Assurance
Environment must pass the Testing Team exit criteria prior to being
released to the Internal Review environment. The data housed within the
Internal Review Environment must receive Data Provider approval and
acceptance through the User Acceptance Process prior to being released
to the Production Environment.

### Production Environments

The Production Environment is comprised of two sets of databases that
present the products that have been approved for public release through
AFF. A set of databases includes a Metadata Repository, a data warehouse
and a spatial database.

## Description of Current Tools and Associated Use

-   The **[Virtual Table Generator (VTG)]{.underline}** is a Java-based
    GUI tool that generates virtual table product metadata. Three main
    groups of file products are produced: HTML review files, product
    metadata and views. The primary role of the VTG is to assist table
    designers in the design and specification of virtual tables. The VTG
    may be accessed from any BOC workstation mapped to the I:\\ drive.

-   The **[SAS Specification Processor]{.underline}** was created to
    support the generation of the VTG input files that are used by the
    VTG to generate product metadata. This tool is used for ACSO product
    metadata solely. ACSO delivers an Excel Spreadsheet, called a
    Specification. The SAS Specification Processor generates the VTG
    input files.

The **[Autogen Tool]{.underline}** is used by the Application
Architecture and Development Team to prepare the SAFF metadata input
files. The autogen tool is run against the SAFF sourcing specifications.
The metadata preparer (currently the AAD team) then delivers the
metadata file, which is the output of the autogen tool, to the DW Team
(Developers and Operators) for processing.

-   The **[ETL Scripts]{.underline}** are a combination of shell
    scripts, Oracle (SQL and PL/SQL) scripts, Informatica Code and other
    code objects. ETL scripts are used to take the data and metadata,
    load it into a staging area, validate it and transform the data into
    the metadata repository or the data warehouse.

-   In the development environments, additional software is used to
    develop, configure and maintain the data products and the American
    Fact Finder System. The following table is a high-level matrix of
    the additional software and databases used for development and
    testing:

  -----------------------------------------------------------------------
  Software            Description
  ------------------- ---------------------------------------------------
  ETL Shell scripts   AFF system and database administration programs

  Rational Schema DB  ClearCase and ClearQuest databases

  IBM ClearCase       Manages versions of files and directories --
  Client v2002        configuration management tool

  IBM ClearQuest      Defect and change tracking system -- change request
  Client v2002        management tool

  Informatica         ETL tool -- delivers data to AFF Data Warehouse
  PwrConnect v7.1     

  Oracle 10g          Database system development tools -- SQL, PL/SQL,
                      SQL\*Loader

  Toad v7             Database query tool (Windows)

  PUTTY v 0.57        AIX server access tools including Terminal
                      Emulation, telnet and FTP (Windows)

  LoadRunner          Automated test tool (Windows)

  ERWin               Database design and maintenance tool (Windows)
  -----------------------------------------------------------------------

**Table** 1: DADS Development and Test Tools

## Key Business Operations Terminology

-   **[ClearQuest Features and Defects]{.underline}** -- Provides a
    mechanism to initiate and track work on each change agreed to as
    part of the product release.

-   **[Clone]{.underline}** -- A copy of a database.

-   **[DADS Value Add Product]{.underline}** -- Presentation types that
    are created by DADS in support of end user needs; includes Fact
    Sheet, Economic Fact Sheet, and the Iterated Fact Sheet.

-   **[Data]{.underline}** -- The statistical information stored in the
    data warehouse. The spatial geographic data is stored in a separate
    database which is accessible for mapping.

-   **[Dataset]{.underline}** -- A logically meaningful grouping or
    collection of similar or related data. For example, all Census 2000
    Summary File #1 (SF-1).

-   **[Data Release Plan]{.underline}** -- Identifies the products and
    geographies to be included in the proposed product release as well
    as the release schedule (e.g., flow release) for a product release.

-   **[Data Warehouse]{.underline}** -- The database that stores the
    statistical information disseminated through the American Factfinder
    (AFF) application.

-   **[Dissemination Services]{.underline}** -- Services provided by
    DADS that include the business operations for processing the data
    and metadata and application (AFF) by which users can retrieve the
    statistical information.

-   **[DWMM (Data Warehouse Maintained Metadata)]{.underline}** --
    Metadata that is produced by DADS to support of AFF application
    functions like mapping features and geographic selection or to
    augment the product metadata like stubs for Geographic Comparison
    Tables.

-   **[ETL (Extract-Transform-Load)]{.underline}** -- A process by which
    data or metadata is extracted from a file or database, modified (or
    transformed) using business logic and loaded into a database.

-   **[Leg]{.underline}** -- An application leg refers to all the
    hardware, software and data which can independently support an
    application. Having more than one 'leg' for an application implies
    redundancy that reduces risks should an equipment outage or planned
    deployment make a component of one leg unavailable.

-   **[Metadata]{.underline}** -- The information that provides meaning
    to the statistical data or that enables certain functions within the
    AFF application.

-   **[Metadata Repository (MDR)]{.underline}** -- The database that
    stores metadata used for rendering the products (i.e., indicates the
    structure of the product) or supporting AFF application functions.

-   **[Presentation Format]{.underline}** -- The layout and other
    details for each instance (e.g., B01001) of a presentation type.

-   **[Presentation Type]{.underline}** -- A table or map type used for
    disseminating a product (e.g., Quick Table, Thematic Map).

-   **[Processing]{.underline}** -- Another term for executing the tasks
    (including the ETL processes) of Dissemination business operations.

-   **[Product]{.underline}** -- A survey or census.

-   **[Product Release]{.underline}** -- A specific release of a survey
    or census (e.g., ACS 2005). A product release may be a culmination
    of many deployments or involve a single deployment only (e.g.,
    Census 2000 110^th^ Congressional District Hundred-Percent Summary
    File).

-   **[Product Review]{.underline}** -- A Dads services that provides
    the data providers' analyst with an early opportunity to detect
    missteps in their own product design and/or DADS implementation of
    their derived product specs.

-   **[Schema]{.underline}** -- The tables and columns that make up the
    structure of the database. The schema does not include the content
    in the tables and columns.

-   **[Script]{.underline}** -- A software program that processes
    information.

-   **[Specification]{.underline}** -- A document that prescribes, in a
    complete, precise, verifiable manner, the requirements, design,
    behavior, or characteristics of a product, system, or system
    component.

-   **[Staging]{.underline}** -- One of the phases of the ETL process.
    Data is loaded into a staging area where it can be validated and
    eventually transformed into the metadata repository.

-   **[Traceability]{.underline}** -- Evidence of an association between
    items, such as between process outputs, between an output and its
    originating process, or between a requirement and its
    implementation.

-   **[Transportable Table Spaces]{.underline}** -- A way of copying a
    set of tables from one database to another.

-   **[VTG (Virtual Table Generator)]{.underline}** -- An application
    that produces metadata files and view definitions for a demographic
    survey's derived products based upon a set of specification files.

# Requirements

## Product Release Planning

The DADS "Back-End" Operations for Data Dissemination shall ...

### Document the DADS understanding of the scope of the product release. 

#### Document the release approach, with expected timing and content of each deployment.

#### Document the geographic coverage of the release, in terms of geographic vintage, geographic summary levels, and geographic components.

#### Document the products (i.e., presentation types) of the release.

#### Document any special handling instructions such as accommodating a data embargo.

#### Document any special operational requirements such as accommodating dry-run.

#### Document any special rules associated with presentation type display.

#### Document the existing "front-end" (i.e., AFF) functions and capabilities that should be available for the product release.

#### Document the new "front-end (i.e., AFF) functions and capabilities that should be available for the product release.

#### Document any multiple language (i.e., English and Spanish) dissemination requirements.

#### Review the product release scope (including content and schedule) with the BOC staff to obtain their agreement. 

#### Create product specifications for the data provider when data provider product specifications are not available. 

#### Create product specifications for DADS value-add products.

#### Place product specifications for DADS value-add products under version control.

#### Place product specifications received by DADS from data providers (or created on their behalf) under version control.

#### Track product release requirements as features to be implemented by downstream dissemination operation activities. 

#### Support communication with data providers with regards to the product release.

##### Document the mutually agreed upon format for the data provider's data, metadata, and other inputs (e.g., specifications) to DADS.

##### Document the agreement with the data providers regarding the number of deliveries, their size, and anticipated content (e.g., metadata). 

##### Provide a mechanism for communicating interdependencies (e.g., deliveries from the data provider, outputs from DADS) between DADS and data providers. 

## Product Development and Configuration

The DADS "Back-End" Operations for Data Dissemination shall ...

### Prepare for Product Release

#### Provide a standard the location for data and metadata deliveries from the Data Provider.

#### Provide a delivery location for a product release that can accommodate up to ten (10) gigabytes.

#### Secure access to the data and metadata delivery location.

#### Provide instruction for the Data Providers indicating where the data and metadata files are to be delivered, the format of the files, and file layout.

#### Allocate space to the requisite environments and schemas for the product release based on the size of the product release. 

#### Receive Deliveries

##### Accept metadata and data deliveries in the agreed-upon formats.

##### Maintain a copy of all previous deliveries as received for a product release.

##### Place specifications, metadata files, data files, non-spatial geographic data files, spatial geographic data files, and other deliveries (e.g., Sagent Address File) under version control.

#### Prepare Transformation Inputs

##### Create the metadata for all Decennial Census derived products based on the received product specifications (i.e., quick tables, geographic comparison tables, and thematic maps).

##### Create the metadata for all American Community Survey derived products based on the received product specifications (i.e., data profiles, subject tables, selected population profiles, ranking tables, geographic comparison tables, and thematic maps).

##### Create the metadata for all Economic Census derived products based on the received product specifications (i.e., quick reports and thematic maps).

##### Create the metadata for all Population Estimates derived products based on the Presentation Summary (i.e., geographic comparison tables and thematic maps).

##### Define the sourcing for all DADS value added products based on the underlying base products (i.e., Fact Sheet, Iterated Fact Sheet, and Economic Fact Sheet).

##### Create the metadata for all DADS value added products (i.e., Fact Sheet, Iterated Fact Sheet, and Economic Fact Sheet).

##### Create the metadata that enables applications functions (e.g., geographic selection).

#### Execute ETL Processes

##### Process data received in ASCII format for the Decennial Census, American Community Survey, Economic Census, Annual Survey of Manufactures, Non-employer Statistics, County and Zip Code Business Patterns, and Population Estimates.

##### Process data received in SAS format for the American Community Survey.

##### Process the data received to the pre-scribed format for the Data Warehouse.

##### Process metadata received in ASCII format for the Decennial Census, American Community Survey, Economic Census, Annual Survey of Manufactures, Non-employer Statistics, County and Zip Code Business Patterns, and Population Estimates.

##### Process the metadata received to the pre-scribed format for the Metadata Repository.

##### Load files for AFF COTS applications (e.g., AXL files for ESRI) to the required location.

##### Process derived metadata (i.e., metadata that is created based on the loaded data) to support the AFF application.

#### Turnaround Schedule

##### Process and deploy dry-run American Community Survey products within five (5) business days of receipt of both metadata and data deliveries (which are fully compliant with agreed upon specifications).

##### Process and deploy American Community Survey products for data owner review within three (3) business days of receipt of both metadata and data deliveries (which are fully compliant with agreed upon specifications).

##### Process and deploy dry-run Economic Census Detailed Statistics data for which metadata has already been deployed within 24 hours of receipt.

##### Process and deploy Economic Census Detailed Statistics production flow for data owner review within 24 hours of receipt of both metadata and data deliveries (which are fully compliant with agreed upon specifications).

##### Process and deploy Economic Census derived products or annual Economic survey products for data owner review within three (3) business days of receipt of both metadata and data deliveries (which are fully compliant with agreed upon specifications).

##### Process and deploy Population Estimates products for data owner review within three (3) business days of receipt of both metadata and data deliveries (which are fully compliant with agreed upon specifications). 

##### Process and deploy Decennial Census products for data owner review within three (3) business days of receipt of both metadata and data deliveries (which are fully compliant with agreed upon specifications). 

##### Deploy a product release to production within five (5) business days after receiving approval from the Data Provider, with the exception of the Economic bi-weekly deployments.

##### Deploy an Economic bi-weekly release to production within two (2) business days after receiving approval from the Data Provider.

##### Deploy Population Estimates Program products to production within five (5) business days of deployment on the Population Estimates public web-site.

## Product Validation and Verification

> The DADS "Back-End" Operations for Data Dissemination shall ...

### Provide a mechanism to enable data provider "early" review of their products during the Data Provider's product design phase.

### Provide a process to ensure data products comply with data product specifications.

### Provide a process to enable final data provider review and acceptance of their products prior to dissemination on AFF.

### Provide a review period that is compliant with the defined Service Level Agreement (SLA) for final data provider review and acceptance.

### Provide a mechanism for data providers to report problems found during their review of their products.

### Provide a mechanism to record, track status and report on "known" issues with the data products and specifications.

### Provide a process to support data and metadata corrections.

### Provide a process to remove metadata from an environment.

### Provide a process to remove data from an environment.

### Provide data extracts (i.e. data dumps) of the DADS transformed data and metadata to enable review and validation in their system for the American Community Survey Office (ACSO).

### Provide a mechanism for the Economic data provider to electronically provide final approval of their datasets prior to public dissemination.

## Product Deployment

The DADS "Back-End" Operations for Data Dissemination shall ...

### Provide environments that are adequately sized and configured to support operations.

### Make products available in a stable and controlled environment for review and approval by the data providers and subject matter experts prior to product release to the public. 

### Support the ability to deploy multiple products and surveys to production at a date and time specified by the Data Provider (Refer to Product Development and Configuration Section for more Details).

### Provide a mechanism for data providers and subject matter experts to review their prepared data and metadata before delivery for production release.

### Provide a mechanism for data providers and subject matter experts to prototype, test and review new products or functionality that are not scheduled for release to the public. 

### Support various release approaches for a product release including flow-basis, single-release deployments, or multiple deployments by geography or theme (see Table 1 -- Dissemination Release Approaches in the Product Release Planning section).

### Provide the capability to deploy to production on a bi-weekly basis.

### Obtain data provider/owner signoff of a product release before deploying to production. 

### Provide a record of the production deployment of the product release.

#### Document the features and defects covered in a product deployment.

#### Document the cause for any remaining open features or defects and a plan to resolve those features and defects.

#### Document the results of any performance tests conducted against a deployment.

#### Document the system testing strategy used to validate product functionality and accuracy.

#### Document the list of test cases used to validate product functionality and accuracy.

#### Document the product promotion and deployment methods utilized to make data available for each major release.

#### Provide a mechanism to deploy new products to production with no interruption to the end-users.

## Product Maintenance and Support

The DADS "Back-End" Operations for Data Dissemination shall ...

### Respond to Errors, Inquiries and Other Outside Events

#### Respond to system errors regardless of the source of those errors.

#### Respond to inquiries from the DADS staff and any source authorized by the DADS staff.

#### Respond to other outside events as directed by the DADS staff.

### Monitor/Manage Performance

#### Monitor database performance using appropriate tools.

#### Manage database performance preferably using pro-active procedures, but also respond to performance issues.

### Manage Compatibility of the Products with Newer Versions of the App

#### Perform AFF Application upgrades consistently across deployed Products.

### Monitor/Manage User Statistics and User Feedback

#### Respond to inquiries based on \"User Feedback\" as directed by the DADS staff.

### Permanently Remove a Product and Archive a Product

#### Discontinue dissemination of a Product (toggle off-line) without taking the entire AFF website off-line.

#### Completely remove a Product from the AFF website. The website should be returned to a status as if the Product never existed. This specifically applies to metadata and data (tabulation, spatial, or other). The only exception is logging of such activities; Logs shall be preserved.

# 

# 

+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     | -             |
|   |                            |                     | -             |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     | -             |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            | -                   | -             |
|   |                            | -                   | -             |
|   |                            | -                   |               |
|   |                            | -                   |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   | -                          | -                   |               |
|   | -                          | -                   |               |
|   | -                          | -                   |               |
|   | -                          | -                   |               |
|   | -                          |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            | -                   | -             |
|   |                            | -                   |               |
|   |                            | -                   |               |
|   |                            | -                   |               |
|   |                            | -                   |               |
|   |                            | -                   |               |
|   |                            | -                   |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     | -             |
+---+----------------------------+---------------------+---------------+
|   |                            |                     |               |
+---+----------------------------+---------------------+---------------+
|   |                            |                     | -             |
+---+----------------------------+---------------------+---------------+

# 

## 

### 

The table below specifies the roles involved in the Product Release
Planning Phase. Note that some of these roles are outside the DADS
program.

+-----------------+----------------------------------------------------+
|                 | -                                                  |
+-----------------+----------------------------------------------------+
|                 | -                                                  |
|                 | -                                                  |
|                 | -                                                  |
|                 | -                                                  |
+-----------------+----------------------------------------------------+
|                 | -                                                  |
|                 | -                                                  |
+-----------------+----------------------------------------------------+
|                 | -                                                  |
|                 | -                                                  |
|                 | -                                                  |
|                 | -                                                  |
+-----------------+----------------------------------------------------+
|                 | -                                                  |
+-----------------+----------------------------------------------------+
|                 | -                                                  |
+-----------------+----------------------------------------------------+

  ---------------------- ------------- -----------------------------------
                                       

                                       

                                       

                                       

                                       
  ---------------------- ------------- -----------------------------------

### 

![](media/image7.wmf){width="6.302777777777778in"
height="4.490972222222222in"}

### Current Process Description

#### Create Presentation Summary

The DADS team has the responsibility of establishing and owning the
working relationships with the data providers who utilize DADS
dissemination services. During the course of regularly-scheduled working
meetings, the DADS team confers with data providers to identify the
products that shall be disseminated via American FactFinder, the
geographic coverage of the release, and the release schedule.

For selected data providers, DADS summarizes the gathered information in
a document called the *Presentation Summary*. The intended audience of
the Presentation Summary is the data provider. Due to the absence of
data provider input in the form of specifications and other formal
documents, DADS created the *Presentation Summary* to capture DADS
understanding of the scope of the product release and to facilitate
mutual understanding between DADS and the data provider. The document
itemizes the presentation types and the standard AFF functional
capabilities that support those presentation types. The *Presentation
Summary* is not intended to provide information on operational concerns
such as reviews and user acceptance testing guidelines.

The DADS Requirements and Stakeholder Management team is responsible for
the creation of the *Presentation Summary*. The *Presentation Summary*
is initiated by DADS 6 -- 8 months prior to the product release in cases
for which data providers' specifications are not provided. Data
providers typically provide DADS with a high-level schedule for the
release which is included in the *Presentation Summary*.

It is important to note that the *Presentation Summary* is not created
for each data provider. The *Presentation Summary* is created for the
Population Estimates Program (PEP) and Decennial (DEC) Program that do
not provide formal product specifications to DADS.

Data provider review of the *Presentation Summary* serves as "informal"
confirmation that DADS has accurately and completely captured the scope
of the product release. The document is not officially "signed off" by
the data provider. Any changes that occur are captured in revised
versions of the document and email is sent to the relevant stakeholders
to communicate the change.

In the current operational model, the *Presentation Summary* has evolved
to serve as an input into the product release planning of a product
release by the IBM team. However, existence of a *Presentation Summary*
is not a necessary prerequisite (i.e., entry criterion) for subsequent
activities of Product Release Planning.

The business purposes fulfilled by the *Presentation Summary* are:

-   Facilitate internal communication within DADS and external
    communication between DADS and the data provider on the products of
    the release and the accompanying AFF capabilities for the products.

-   Receive validation from the data provider that DADS has accurately
    and completing captured the scope and details of the product
    release.

-   Fill gap in understanding caused by absence of data provider
    documents / specifications.

-   Provide the DADS internal teams with presentation formats for each
    product in the absence of data provider product specifications.

-   Provide initial input to the DADS Business Analysis Team to initiate
    their analysis activities.

#### Develop Data Release Plan

The *Data Release Plan* documents the requirements and design of a
product release that prompt downstream development and operational
processes. The DADS Master Program Plan (MPP) serves as the trigger for
commencing requirements and functional design for a product release.
This analysis occurs during the Functional Design phase of the lifecycle
for product releases. To define the product release, the IBM Business
Analysis team:

-   Determines which products need to be disseminated for the requested
    product release.

-   Reviews product specifications, the *Presentation Summary*, and
    other information regarding the requested product release.

-   Determines the updates to AFF functional specifications that have
    information / business rules that are specific to a product release.

-   Determines which geographies are needed for the product release.

-   Documents the proposed release schedule.

The IBM Business Analysis team is responsible for creating and
maintaining the *Data Release Plan*. Requirements captured in the *Data
Release Plan* are organized into the following sections:

-   **Release timing / phases** (with expecting timing and content of
    each release).

-   **Geographic coverage** of the release, in terms of geographic
    summary levels and geographic components.

-   **Products** (i.e., Presentation Types) included in the release,
    accompanied by any special rules for the data product display.

-   **Application** **functions** (i.e., AFF) and capabilities available
    for the data product.

-   Links to **related documents** such as product specifications,
    business rules for map and geographic selection methods, and
    functional specifications.

-   Miscellaneous information such as whether dissemination in multiple
    languages is required (e.g., Spanish).

During the functional design phase of the data product release, the
*Data Release Plan* is created by gathering, analyzing, and documenting
all known information about the scope of the release. This information
is then translated into requirements for the product release..

In the "as is" operational model, the *Data Release Plan* is an internal
DADS document that is not shared with data providers. Hence, the *Data
Release Plan* uses the terminology that reflects the technical
environment of the DADS program. The primary audience of the *Data
Release Plan* is the DADS team to define and shape the downstream
activities of DADS dissemination operations.

The *Data Release Plan* is distributed to the DADS team (both IBM and
Census Bureau) for review prior to conclusion of the functional design
phase. The document is not officially "signed off" at the end of this
phase. Once all comments are received and incorporated into the
document, the *Data Release Plan* is considered "unofficially
baselined". The requirements specified in the document are recorded
using ClearQuest features, which are used by the downstream activities
related to the dissemination operations. In the current methodology, the
*Data Release Plan* is finalized after the public release as a
contractual deliverable from IBM to DADS.

The *Data Release Plan* may be updated during the other phases of DADS
dissemination operations, as the scope of the product release evolves
over time. If any of the requirements change over the course of
development and operations for the product release, additional
ClearQuest features are opened by the Business Analysis Team and are
analyzed via the DADS Change Management process.

#### Receive or Create Product Specifications

Product specifications define the presentation formats (also called
layouts) for each presentation type that will be released by DADS.
Product specifications function as the "unambiguous blueprints" for the
products. Product specifications provide direction to DADS on the
product metadata to create and disseminate as part of the product
release. Also, product specifications are an important input to DADS
verification processes to ensure that the product released by DADS
matches specifications.

However, there are numerous types of specifications that are required
for a product release. As stated above, the product specifications
define the presentation types that are disseminated via DADS. Other
specifications define the American FactFinder functional capabilities
that are required for the product release. The table below provides a
detailed view of which specifications are created or provided for
specific presentation types or functions for each survey supported by
DADS dissemination operations.

+--------------------------+-------------+----------------------------+
| Presentation             | Survey      | Specification Provided /   |
| Type/Function            |             | Created                    |
+==========================+=============+============================+
| Detailed Tables          | Decennial   | No                         |
+--------------------------+-------------+----------------------------+
|                          | ACS         | No                         |
+--------------------------+-------------+----------------------------+
|                          | PEP         | No                         |
+--------------------------+-------------+----------------------------+
| Detailed Economic        | Economic    | No                         |
| Statistics               | Census,     |                            |
|                          | ASM, NES,   |                            |
|                          | CBP         |                            |
+--------------------------+-------------+----------------------------+
| Quick Tables             | Decennial   | No                         |
+--------------------------+-------------+----------------------------+
| Data Profiles,           | ACS         | ACSO - Product             |
| Multi-Year Profiles,     |             | Specifications (Excel)     |
| Subject Tables,          |             |                            |
| Non-Iterated Selected    |             |                            |
| Population Profiles      |             |                            |
| (i.e., Subpop Profiles)  |             |                            |
+--------------------------+-------------+----------------------------+
| Iterated Selected        | ACS         | ACSO - Product             |
| Population Profiles      |             | Specifications (Excel)     |
| (i.e., Iterated          |             |                            |
| Profiles)                |             |                            |
+--------------------------+-------------+----------------------------+
| Quick Reports            | Economic    | EPCD - Product             |
|                          | Census      | Specifications (PDF)       |
+--------------------------+-------------+----------------------------+
| Geographic Comparison    | Decennial   | No                         |
| Tables                   |             |                            |
+--------------------------+-------------+----------------------------+
|                          | ACS         | ACSO - Product             |
|                          |             | Specifications (Excel)     |
+--------------------------+-------------+----------------------------+
|                          | PEP         | DADS - Presentation        |
|                          |             | Summary (Word)             |
+--------------------------+-------------+----------------------------+
| Ranking Tables           | ACS         | ACSO - Product             |
|                          |             | Specifications (Excel)     |
+--------------------------+-------------+----------------------------+
| Thematic Maps            | Decennial   | DADS - Thematic Map        |
|                          |             | Details Spec (Word)        |
| (also see Mapping        |             |                            |
| category)                |             |                            |
+--------------------------+-------------+----------------------------+
|                          | ACS         | ACSO - Product             |
|                          |             | Specifications (Excel)     |
+--------------------------+-------------+----------------------------+
|                          | PEP         | DADS - Presentation        |
|                          |             | Summary (Word)             |
+--------------------------+-------------+----------------------------+
|                          | Economic    | DADS - Thematic Map        |
|                          | Census      | Details Spec (Word)        |
+--------------------------+-------------+----------------------------+
| Fact Sheet               | Decennial   | IBM - Layout & Sourcing    |
|                          |             | Specification (XLS)        |
+--------------------------+-------------+----------------------------+
|                          | ACS         | IBM - Layout & Sourcing    |
|                          |             | Specification (XLS)        |
+--------------------------+-------------+----------------------------+
| Iterated Fact Sheet      | Decennial   | IBM - Layout & Sourcing    |
|                          |             | Specification (XLS)        |
+--------------------------+-------------+----------------------------+
| Economic Fact Sheet      | Economic    | IBM - Layout Specification |
|                          | Census      | (XLS)                      |
+--------------------------+-------------+----------------------------+
| SAFF People, Housing     | Decennial   | IBM -- Sourcing            |
| links                    |             | Specification (XLS)        |
+--------------------------+-------------+----------------------------+
|                          | ACS         | IBM -- Sourcing            |
|                          |             | Specification (XLS)        |
+--------------------------+-------------+----------------------------+
|                          | PEP (under  | IBM -- Sourcing            |
|                          | Basic       | Specification (XLS)        |
|                          | Counts)     |                            |
+--------------------------+-------------+----------------------------+
| SAFF Business and        | Economic    | IBM -- Sourcing            |
| Government               | Census,     | Specification (XLS)        |
|                          | ASM, NES,   |                            |
|                          | CBP         |                            |
+--------------------------+-------------+----------------------------+
| Population Finder        | PEP,        | IBM - Functional           |
|                          | Decennial   | Specification (Word)       |
+--------------------------+-------------+----------------------------+
| Geo Selection (e.g.,     | ALL         | DADS - Geo Select Details  |
| list, map, keyword       |             | spec (Word)                |
| selection methods)       |             |                            |
+--------------------------+-------------+----------------------------+
| Non Spatial Geo (needed  | ALL         | DADS - Geo Bucket Spec     |
| for selection,           |             |                            |
| navigation, and          |             | DADS - Geo Names Spec      |
| rendering products)      |             |                            |
+--------------------------+-------------+----------------------------+
| Mapping (Reference and   | ALL         | DADS - Map Details Spec    |
| Thematic)                |             |                            |
|                          |             | DADS -- Spatial Details    |
|                          |             | Spec                       |
+--------------------------+-------------+----------------------------+

The DADS program creates product specifications for value-added products
available via American FactFinder such as Simple AFF (SAFF) Fact Sheets
and for some presentation types like Thematic Maps. The IBM Business
Analysis team creates the specifications for the SAFF Fact Sheets and
review is conducted by the DADS team. The DADS Stakeholder Relationship
Management team creates the specifications for Thematic Maps and
Geographic Comparison Tables on behalf of data providers. Data providers
review the DADS-created specifications for their presentation types and
provide approvals for release.

For base products (i.e., detailed tables and detailed economics
statistics), data providers do not provide specifications to DADS.
Rather, the data providers deliver metadata that provides the
information so the application can present the product correctly. .

The product specifications for derived products (e.g., quick tables,
geographic comparison tables) are not standard in documentation,
delivery, or ownership. As previously discussed, DADS prepares the
specifications for thematic maps and geographic comparison tables for
all data providers. DADS also develops the *Presentation Summary* (in
lieu of individual product specifications) to describe the presentation
formats for the Population Estimates and Decennial Census (i.e.,
ongoing, not initial releases) product releases. ACSO prepares the
product specifications for the ACS and EPCD product specifications for
the quick reports for the Economic Census, which are in Microsoft Excel
and Adobe PDF format, respectively. The product specifications for
derived products are interpreted (manually) so that metadata can be
created (see Product Development and Configuration).

One noted process improvement that has occurred as part of the "as is"
operational model involves the creation and interpretation of the
derived product specifications for ACS (as was implemented for the ACS
2005 product release). This process improvement was a joint effort
between ACSO and DADS. For DADS, these new specifications are in a
format that can be read by automated tools to produce metadata required
for downstream processes.

Downstream dissemination operations processes are dependent on
specifications that are received, gathered, or updated in this phase.

-   The System Testing team uses specifications for test case scenario
    development and automated scripting (for verification).

-   The Application Development team uses specifications to determine
    what updates need to be made to the Virtual Table Generator (VTG),
    which generates product metadata and view definitions to support
    rendering of the derived products (except quick reports).

-   During the User Acceptance Testing period (which occurs as part of
    Product Validation and Verification), the data providers and DADS
    use the product specifications to verify that DADS has accurately
    disseminated the product.

-   The DADS Data Warehouse team uses the product specifications to
    support the activities of the Product Development and Configuration
    phase (i.e., the creation of metadata and load of metadata).

#### Open Standard Features

Upon review and "unofficial" baselining of the *Data Release Plan*,
features are entered in the DADS change control repository, ClearQuest,
to track each item in the *Data Release Plan*. The IBM Business Analysis
team opens features in ClearQuest. For the purpose of consistency, the
wording of the ClearQuest feature matches the wording found in the *Data
Release Plan*. These features are high-level in nature -- the Data
Warehouse and Application Development Team open more detailed features
to track specific work items. The DADS System Testing team traces their
test cases back to ClearQuest features that were opened by the IBM
Business Analysis team.

#### Communicate Interdependencies

Interdependencies represent mutual dependence between DADS and the data
providers to accomplish the product release. Types of interdependencies
include:

-   Specifications to be delivered by data providers to DADS.

-   Metadata to be delivered by data providers to DADS.

-   Data to be delivered by data providers to DADS.

-   Availability of data product for review by DADS to data providers.

-   User Acceptance Testing phase for data providers.

-   Signoff by data providers to DADS.

```{=html}
<!-- -->
```
-   Public release by DADS.

DADS interdependencies with a data provider are first documented in a
Memorandum of Understand (MOU) for the fiscal year. The
interdependencies documented in the MOU are at a high/strategic level
and do not get into the particulars for a specific product release, as
listed above. Therefore, a DADS-Data Provider *Interdependency Plan* is
developed during Product Release Planning.

The business objective of documenting and communicating
interdependencies is to capture the required activities for predictable
and thorough planning. Tracking the interdependencies also provides
information that can be used for an impact analysis of any change in
product release requirements or change in dependency from the data
provider later in the lifecycle. Another reason that communicating
interdependencies is critical to successful DADS dissemination
operations is to baseline expectations at a working level between both
parties.

The DADS-Data Provider *Interdependency Plan* is the tool used to
communicate interdependencies and facilitate product release planning.
This tool, in Microsoft Project format, is used in the absence of a
Census Bureau inter-divisional schedule to communicate.
Interdependencies between DADS and data providers are required to align
with the DADS *Master Program Plan (MPP)*.

*Interdependency Plans* are initiated during the functional design
phase, primarily by the Business Analysis Team and maintained by the
Data Warehouse Team. The document is created in coordination with data
providers.

## Product Development and Configuration

### Overview

Product Development and Configuration is performed during the second
phase of the DADS Operational System for Data Dissemination. Based on
the plans developed during Product Release Planning, several activities
occur to process the delivered data and configure the products and
application functions for the ultimate purpose of disseminating a census
or survey. This requires the receipt of data and metadata, the creation
of metadata, and the extraction, transformation, and load of data and
metadata. These activities must be performed in order to enable Product
Deployment as well as Product Validation & Verification.

Dissemination Operations for a release may be iterative. This is due to
changes introduced by DADS stakeholders, including redeliveries of data
and changes to the defined product structure, the release schedule
proposed by the DADS stakeholder, as well as reprocessing due to errors
discovered during validation. Therefore, Product Development and
Configuration may be executed several times for a given product release.

The Product Development and Configuration phase has several stakeholders
and participants. The DADS Data Providers provide inputs to the process
in the form of product specifications, data files, and metadata files as
well as act as customers for Dissemination Operations. Currently, the
American Community Survey Office (ACSO), the Economic Planning &
Coordination Division (EPCD), and the Population Estimates Branch are
DADS Data Providers. DADS plays the Data Provider role for the Decennial
Census and the Geography Division (GEO) plays the role in providing
non-spatial and spatial geographic data.

IBM is also a stakeholder of Product Development and Configuration, not
only from the standpoint of ensuring the complete and accurate
processing of the data and metadata, but also from ensuring that the
American FactFinder (AFF) website operates correctly. The IBM Data
Architecture and Data Management (DADM) team is responsible for the
execution and output of Product Development and Configuration. However,
other IBM teams also participate including the Application Architecture
and Development (AAD) team, Business Analysis (BA) team, Systems
Engineering Operations team and the Testing Team.

The table below specifies the roles involved in the Product Development
and Configuration Phase. Note that these roles can be assumed by another
of the aforementioned stakeholders.

+-----------------+----------------------------------------------------+
| Roles           | Primary Responsibilities in the Product            |
|                 | Development & Configuration Phase                  |
+=================+====================================================+
| Data Provider   | -   Provides product specifications                |
|                 |                                                    |
|                 | -   Delivers metadata files and data files (for    |
|                 |     some products included in the product          |
|                 |     release).                                      |
+-----------------+----------------------------------------------------+
| DW Team         | -   Executes the receipt process for data and      |
| (Developers and |     metadata file deliveries.                      |
| Operators)      |                                                    |
|                 | -   Executes the ETL processes for metadata, data, |
|                 |     non-spatial geographic data, and spatial data. |
+-----------------+----------------------------------------------------+
| DW Developer    | -   Prepares transformation inputs                 |
|                 |                                                    |
|                 | -   Creates/updates/configures ETL code            |
+-----------------+----------------------------------------------------+
| DW Architect    | -   Employs ERWIN to maintain the Data Model       |
|                 |                                                    |
|                 | -   Architects solutions for metadata, data, data  |
|                 |     model and other changes (e.g. those required   |
|                 |     for an application enhancement)                |
+-----------------+----------------------------------------------------+
| Metadata        | -   Prepares metadata files manually or by running |
| preparer        |     the Virtual Table Generator.                   |
+-----------------+----------------------------------------------------+
| Database        | -   Stands-up the staging schema.                  |
| Administrator   |                                                    |
|                 | -   Configures and allocates spacing to the        |
|                 |     various databases (including the MDR and data  |
|                 |     warehouse).                                    |
+-----------------+----------------------------------------------------+
| System          | -   Deploys files needed to operate application    |
| Administrator   |     components, including the Sagent Address File  |
|                 |     and ESRI AXL files.                            |
+-----------------+----------------------------------------------------+

### High Level Process Diagram

The following high level process diagram depicts how the product
development and configuration process occurs in the current operational
system.

![](media/image9.wmf){width="4.784027777777778in"
height="4.238194444444445in"}

### Current Process Description

As previously stated, the goal of Product Development and Configuration
is to process the data and metadata needed for a product release. The
tasks that accomplish this goal fall into the one of three categories:
Receive Deliveries; Prepare Transformation Inputs; and Execute ETL
Processes.

The following description provides an overview of the processes by each
area that is being supported: processing product data, configuring the
product structure, configuring the application structure, or processing
geographic data. Tasks in the aforementioned categories (e.g., Prepare
Transformation Inputs) may be executed to support each area. Since
receiving deliveries is common to all areas, it is called out
separately.

#### Acquire Data and Metadata

Acquisition of data and metadata is the activity that initiates Product
Development and Configuration for each product release. The goal of this
activity is to acquire the requisite inputs for processing, either by
obtaining or receiving the inputs, in a manageable and consistent
manner. In order to accomplish this, the delivery location needs to be
prepared, the data and metadata need to be delivered, and the receipt
process needs to be invoked.

**Initial Preparation** -- Preparation for data and metadata file
deliveries involves the DW Developers, Database Administrator, and
System Administrator. The DW Developer creates the directory structure
for the product release in the delivery and load locations and updates
the specification with the appropriate instructions for the Data
Provider. The Database Administrator establishes the staging schemas for
the product release and allocates the spacing in the staging schema,
Metadata Repository, and data warehouse. The System Administrator
establishes AIX accounts for individuals within the Data Provider's
organization who will FTP the files to the delivery location. As a final
step, the DW Developer populates the MDR with basic fileset information
(which classifies the files for the product release).

**Data Provider Delivery** -- The Data Providers (which includes DADS
for the Decennial Census) FTP the files to the appropriate delivery
location. Metadata and view definitions created by DADS for the derived
products (see below) are also FTP'd to the delivery location.

**Receipt Process** -- The DW Team (Developers and Operators) executes
the receipt process. The receipt process archives the existing files in
the Load directory then copies the files from the directory where the
Data Provider FTP'd the files to the Load directory. An email
acknowledging receipt of the files is sent by the DW DW Team (Developers
and Operators) once the files are validated in the Load directory.

Other inputs to Product Development and Configuration are also received
from the Data Providers and other stakeholders. The receipt process has
not been standardized across data providers nor has it been standardized
across products. Usually, the specifications are placed on the I:\\
drive in the directory designated for stakeholder inputs.

#### Process Product Data

Product data is processed for base products (i.e., Detailed Tables and
Detailed Economic Statistics) and ACS derived products only. For the
base products, the DW DW Team (Developers and Operators) records the
fileset delivery then loads the data into the Data Warehouse. For ACS
derived products, the DW DW Team (Developers and Operators) processes
the product data based on the ETL developed for the product. If the ETL
is developed using Informatica (e.g., for Data Profiles), executing the
ETL will convert the delivered data from SAS to ASCII and transform the
data format from long to wide (i.e., since columnar data is delivered as
a separate row) then load the data. For other ACS derived products, SAS
is used to convert the files to text and transform the data format. SQL
Loader is then used to load the data into the data warehouse.

Loading the data (whether for base products or for the ACS derived
products) is dependent on the "seeding" the metadata with the list of
tables that are to be loaded.

#### Configure Product Structure (Product Metadata)

Products that are disseminated by DADS are rendered based on the
information contained with the Metadata Repository (MDR). Although the
metadata files delivered by the Data Provider are considered product
metadata, other inputs are used in conjunction with the delivered
metadata to configure the product structure (e.g., layout of the table,
headnotes, and footnotes). For example, metadata that is created based
on Data Warehouse Maintained Metadata (DWMM) is used to render the
headnotes or footnotes for some base products.

Therefore, configuring the product structure may be based on Data
Provider delivered product metadata, DADS or IBM created metadata and
view definitions, and DWMM created metadata. For mapping products (i.e.,
Thematic Maps), other input files and spatial geographic data is needed
to provide the mapping mechanism (see configuring the application
structure).

**Prepare Input Files** -- For base products, most of the metadata is
delivered by the Data Provider, except for the metadata that is used to
configure the application. For derived products, the metadata is created
by DADS or IBM. There are three different types of files that are
prepared: product metadata, DWMM metadata, and view definitions. Product
metadata and view definitions are created using the Virtual Table
Generator (VTG) or, for the Economic Census derived products, manually.

Product metadata input files are prepared by first creating a VTG input
file. This input file may be created by DADS or IBM. The input file is
created manually for the Decennial and PEP derived products, and the
demographic-based Fact Sheets. Product specifications are used by the
metadata preparer as the guidance for what the product should look like;
in its absence, a Presentation Summary document is used. For the ACS
derived products, the input file is created by the DW Team (Developers
and Operators) running the spec translator, which converts the ACS
Product Specifications to VTG input.

Once the VTG input files are ready, the metadata preparer or DW Team
(Developers and Operators) runs the VTG to generate the metadata and
view definitions. Those inputs are FTP'd to the delivery location and
processed similarly to input files received from the Data Provider.

For the Economic Census derived products, the metadata preparer creates
the metadata files manually and the DW Team (Developers and Operators)
creates the view definitions manually, both using the Product
Specifications as guidance. Those files are also FTP'd to the delivery
location.

DWMM input files for headnotes and footnotes, themes, and geographic
area stubs are also created manually. They are placed on the I:\\ drive
and their "delivery" is based on an email from the metadata preparer to
the DW Team (Developers and Operators) signifying their availability.

The following table indicates who is responsible for the assembly of the
various inputs needed for configuring the products:

+-------------+---------------------------+---------+------------------+
| Su          | Category                  | Del     | Responsibility   |
| rvey/Census |                           | ivered? |                  |
+=============+===========================+=========+==================+
| Decennial   | Base Products             |         |                  |
| Census      |                           |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files        | Y       | DADS             |
+-------------+---------------------------+---------+------------------+
|             | Derived Products          |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Product               | Y       | DADS             |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Value-add Product     | N       | IBM              |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files &      | Y       | DADS             |
|             |     Views                 |         |                  |
+-------------+---------------------------+---------+------------------+
|             | Application Functions     |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Specifications        | Y       | DADS             |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files        | N       | IBM              |
+-------------+---------------------------+---------+------------------+
| American    | Base Products             |         |                  |
| Community   |                           |         |                  |
| Survey      |                           |         |                  |
| (ACS)       |                           |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files        | Y       | ACSO             |
+-------------+---------------------------+---------+------------------+
|             | Derived Products          |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Product               | Y       | ACSO             |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Value-add Product     | N       | IBM              |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files &      | N       | IBM              |
|             |     Views                 |         |                  |
+-------------+---------------------------+---------+------------------+
| Economic    | Base Products             |         |                  |
| Census and  |                           |         |                  |
| Annual      |                           |         |                  |
| Economic    |                           |         |                  |
| Surveys     |                           |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files        | Y       | EPCD             |
+-------------+---------------------------+---------+------------------+
|             | Derived Products          |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Product               | Y       | EPCD             |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Value-add Product     | N       | IBM              |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files &      | \--     | DADS, IBM        |
|             |     Views                 |         |                  |
+-------------+---------------------------+---------+------------------+
| Population  | Base Products             |         |                  |
| Estimates   |                           |         |                  |
| (PEP)       |                           |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files        | Y       | DADS             |
+-------------+---------------------------+---------+------------------+
|             | Derived Products          |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Product               | Y       | DADS             |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Value-add Product     | N       | IBM              |
|             |     Specifications        |         |                  |
+-------------+---------------------------+---------+------------------+
|             | -   Metadata Files &      | Y       | DADS             |
|             |     Views                 |         |                  |
+-------------+---------------------------+---------+------------------+

**Transform and Load Metadata** -- As with processing product data, the
DW Team (Developers and Operators) records the fileset delivery for the
metadata files, whether they were delivered by the data provider or
prepared by DADS or IBM. The DW Team (Developers and Operators) stages
the metadata then builds a job for the fileset delivery. For all
products other than Geographic Comparison Tables and Thematic Maps, this
occurs in the development environment (i.e., DM); for those two
products, this occurs in the working environment (i.e., WM) due to the
size of the metadata. The metadata is validated to ensure it conforms to
the requisite format and business rules. The DW Team (Developers and
Operators) sends exceptions to the Data Provider or, in the case of
DADS/IBM prepared metadata, to the metadata preparer.

When the product metadata is valid, the DW Team (Developers and
Operators) toggles off the fileset in the Metadata Repository and
refreshes the cache. If metadata derived products are being, the DW Team
(Developers and Operators) executes scripts to create Oracle table views
from the view definition. The DW Team (Developers and Operators) then
seeds the metadata and loads the product data (see description above).

Once the data has been processed (if required), the DW Team (Developers
and Operators) executes the process that transforms and loads the
metadata from the staging schema to the MDR. The derive processes are
then executed (see below) and the fileset is toggled on. If an ACS
fileset was processed, the DW Team (Developers and Operators) creates
the data dump for ACSO's review, posts the data dump file to the DADS
delivery location, then notifies ACSO of its availability.

Note: Processing derived products (including DADS value-added products)
requires the presence of the underlying source information, so there is
a dependency on the base products. This is not the case for ACS derived
products since there is a separate data delivery for those products.
However, since Ranking Table data is the only data delivered for ACS
multi-geographic area derived products; Ranking Tables must be processed
first, then Thematic Maps, and finally Geographic Comparison Tables.

#### Configure Application Structure (Application Metadata)

Key functions within the dissemination application, AFF, are data-driven
so that changes for a product release can be implemented using metadata.
These functions include search, geographic selection, table selection
(i.e., subjects), mapping features, download center, simple AFF, and to
some degree, table and map rendering (i.e., conditional notes).

The bulk of the metadata produced to support these functions is
encompassed by the DWMM. However, the Sagent Address File is also used
for search. If the Sagent API is not changed, the System Administrator
will FTP it onto the map server. If it changes, the geocoder needs to be
updated by a developer before the file can be placed on the map server.

**Prepare Input Files** -- DWMM input files are created manually. There
are several input files created, which are based on different
specifications (e.g., Map Details specification), emails, or
communications with the DADS SME. They are placed on the I:\\ drive and
their "delivery" is based on an email from the metadata preparer to the
DW Team (Developers and Operators) signifying their availability.

SAFF metadata input files are created via the autogen tool. The autogen
tool is run against the SAFF sourcing specifications. The metadata
preparer (currently the AAD team) then delivers the metadata file, which
is the output of the autogen tool, to the DW Team (Developers and
Operators) for processing.

**Transform and Load Metadata** -- Since the DWMM files are cumulative,
the DW Team (Developers and Operators) does not record a fileset
delivery. The process starts off with staging the metadata then
validating the metadata to ensure it conforms to the requisite format
and business rules. The DW Team (Developers and Operators) sends
exceptions to the metadata preparer.

When the DWMM is valid, the DW Team (Developers and Operators) executes
the scripts to transform and load the metadata into the MDR. This
process completely replaces the metadata that had existed in the MDR for
that application function.

Note: The processing for metadata to address SAFF is the same as the
processing for DWMM.

#### Process Geographic Data

Geographic data is required for AFF to facilitate product selection,
search, and map rendering. Processing non-spatial geographic data is
required for every product release; however, spatial geographic data is
only required if maps are included in the product release.

As with product data and metadata processing, delivery of geographic
data uses the same acquisition process. Specifications used by DADM for
geographic data processing are produced by the DADS Mapping SME as input
to the Geography division.

**Prepare Input Files** -- The input files required for non-spatial
geographic data and spatial geographic data are very different.
Non-spatial geographic data requires the geographic area bucket delivery
from the Geography division and a DWMM input file that specifies the
hierarchy of the geographic summary levels for the product release.
Spatial geographic data requires the spatial files delivered from the
Geography division, driver files prepared by the IBM team, plus the AXL
files prepared by DADS and IBM.

The Geography Divisions delivery of geographic data is processed like
all files received to the delivery location. The DWMM file is created
manually and "delivered" to the I:\\ drive. The DW Team (Developers and
Operators) prepares the driver files in anticipation of the first
delivery from the Geography division and places these files in the
staging schema. The AXL file with information regarding which layers to
use is prepared by the DADS Mapping SME and placed on the I:\\ drive as
is the AXL file that the DW Team (Developers and Operators) prepares to
facilitate translation between the MDR and the mapping product.

Note: Non-spatial geographic data for Economic zip codes are delivered
by EPCD.

**Load Geographic Data** -- Non-spatial geographic data processing is
similar to product metadata processing when an initial load for the
product release is processed. The geographic area bucket received from
the Geography division is staged in the working environment for the DADM
team (i.e., WM). The DW Team (Developers and Operators) loads the geo
bucket into the MDR then updates missing information needed by the
application such as the FIPS codes to create the geo reference
information in the MDR. The DW Team (Developers and Operators) stages
then loads the DWMM metadata for the geo summary level hierarchy and
runs the scripts to build the geo trees.

If processing a redelivery, the creation of the geo trees is different.
If a new tree node is to be created (e.g., as was done for Census 2000
State Legislative District release), first a new geo bucket is created.
With the DWMM metadata, the existing geo tree for the product is
extended. If a new tree node is not needed, the geo bucket is merged
with the existing geo reference information and the geo tree is manually
re-built. This usually occurs each time a new delivery is received from
the Geography division.

Note: The processing for Economic zip codes is relatively the same
except that the delivered non-spatial data must be translated to the
requisite format for the MDR before other processing can occur.

Spatial geographic data processing involves the DW Team (Developers and
Operators), DADS Mapping SME and Systems Administrator. The DW Team
(Developers and Operators) loads the spatial data from the load
directory to the spatial database using ESRI customized tools. The
System Administrator then loads the AXL files onto the map server from
their I:\\ drive location.

**Execute Derive Processes** -- Several derive processes are executed to
complete processing of non-spatial geographic data. Firstly, the DW Team
(Developers and Operators) derives geo search values to enable AFF
Search and populate the MDR with those values. Secondly, the
geo-within-geo derive process is executed. This requires a block bucket
source file, also provided by the Geography division. For Economic zip
codes, the geo-within-geo metadata is created by pairing the states with
the zip codes, not through the GWG derive process.

As a final step for NSG processing, the DW Team (Developers and
Operators) exports the NSG from the working environment (i.e., WM-MDR)
to the development environment.

#### Execute Derive Processes

Metadata to facilitate navigation through the application is produced
using the delivered product data and non-spatial geographic data as a
source of information. The product data is assessed to see for which
geographic areas and products data is available and the MDR is updated
accordingly. The geographic, table, map, and Economic dataset selection
is then limited to those geographic areas and products. For ACS, the
derive processes also determine for each presentation type (e.g.,
Subject Tables) which geographic areas are available.

The DW Team (Developers and Operators) executes the derive processes
once processing of the product data, product structure, and NSG is
complete. This determines which metadata to produce or flag and
populates the MDR appropriately. Executing the derive processes is the
final step for Product Development and Configuration.

## Product Validation and Verification

### Overview

The Product Validation and Verification Phase is the third phase of the
DADS Business Operational System for Data Dissemination. The goal of
this phase is to enable internal (Testing Team) and external (Data
Provider) review, validation, testing and approval of the data products
prior to dissemination on AFF.

The primary business objectives of this Product Validation and
Verification phase are to ensure quality and accuracy of the data
products that will be disseminated via DADS Business Operational System;
to support the Data Provider's product design using DADS services and
systems; to provide validation activities to ensure that data provider
specifications and agreed upon requirements are met; to provide a
process to identify, manage and resolve errors; and to provide a process
to manage corrections.

Roles typically involved in Product Validation and Verification are
listed and described in the table below:

+-------------------+--------------------------------------------------+
| Roles             | Primary Responsibilities in the Product          |
|                   | Validation and Verification Phase                |
+===================+==================================================+
| Data Provider     | Conducts reviews and develops a consolidated     |
|                   | list of findings and recommendations for issue   |
|                   | resolution.                                      |
|                   |                                                  |
|                   | Conducts user acceptance testing to ensure       |
|                   | product readiness for production and             |
|                   | communicates issues back to DADS.                |
|                   |                                                  |
|                   | Provides approvals and signoffs for release of   |
|                   | the data to production.                          |
+-------------------+--------------------------------------------------+
| Analyst           | Serves as the communication liaison between the  |
|                   | Data Provider and the Business Operations team   |
|                   | to ensure that requirements, issues and status   |
|                   | are understood by all of the stakeholders.       |
|                   |                                                  |
|                   | Maintains a known issues mechanism to reflect    |
|                   | the outstanding issues and the status of the     |
|                   | issues                                           |
|                   |                                                  |
|                   | Facilitates updates to specifications            |
+-------------------+--------------------------------------------------+
| Data Warehouse    | Performs high level impact analysis of scope of  |
| and Application   | data release.                                    |
| Developer         |                                                  |
+-------------------+--------------------------------------------------+
| Tester            | Develops test strategy.                          |
|                   |                                                  |
|                   | Develops/updates automated test scripts          |
|                   |                                                  |
|                   | Develops/updates test cases                      |
|                   |                                                  |
|                   | Executes Test Cases                              |
|                   |                                                  |
|                   | Records, Tracks and Communicates Defects.        |
|                   |                                                  |
|                   | Creates Test Report                              |
+-------------------+--------------------------------------------------+

The core activities of this phase include:

-   Preparing and managing Product Review

-   Preparing and managing Dry Run

-   Preparing and managing Internal Review

-   Conducting Product Assurance

-   Supporting User Acceptance Testing

-   Preparing and sending "Data Dumps"

```{=html}
<!-- -->
```
-   Managing product approvals and sign-offs (provider)

The Product Verification and Validation phase is typically initiated
after the release scope is defined in Product Release Planning phase.
This milestone triggers the development of the Test Strategy and a
review and revision of the test cases and automated test scripts that
will be used to ensure product quality and compliance with product
specifications and to initiate the setup of the internal environments
that will be required to support the Data Release.

### High Level Process Diagram

The following high level process diagram depicts how this process occurs
in the current operational system.

![](media/image10.png){width="6.4875in" height="3.1958333333333333in"}

### Current Process Descriptions

#### Prepare and Manage Product Review

> Product Review is used by ACSO and Econ to support very early reviews
> of their table shells in AFF. The focus of Product Review is less on
> the DADS rendering of the tables and more on the data providers
> specifications for the product structures (stubs and rows). Typically
> test data is used to support this review.

#### 

#### 

#### Prepare and Manage Dry Run

> Dry run is an expanded DADS service offered to the ACSO and Econ Data
> Providers as a part of their Product Design activities. The goal of
> Dry Run is to allow the data providers to conduct an "early" view of
> their data and metadata on a DADS environment with current AFF
> capabilities in hopes that the data providers will be able to identify
> and resolve issues with their data and metadata prior to sending their
> production files. The focus is less on functionality and more on data
> / metadata using data provider inputs. The preparation and management
> of Dry Run requires close coordination when an application release
> accompanies a data release.
>
> The challenge with Dry Run is the sheer volume of data deliveries and
> re-deliveries requested by the Data Providers and locating, setting up
> and managing an environment to enable and support this service.
> Another challenge associated with Dry Run is the fact that the service
> is provided on the development environment. This environment is in a
> constant state of flux and is unstable.

#### 

#### 

#### 

#### Conduct Product Assurance

> Product Assurance is the process of ensuring that the data products
> that are being developed and configured for deployment are consistent
> with the specifications and to ensure that the application and the
> data can be successfully integrated into the Production Environment.
>
> The Product Assurance Activities are conducted by the Testing Team.
> The Testing Team is responsible for planning the overall test
> strategy, development of detailed test cases and automated test
> scripts, the execution of the test scripts and the tracking and
> managing of defects found as a result of the testing process.
>
> The Testing Team is also responsible for conducting Peer Reviews and
> Test Readiness reviews for Data Releases based upon the size of the
> and complexity of the deployment.
>
> The artifacts that are developed as a part of the Product Assurance
> Process include the Testing Strategy, the Test Plan, the Test Cases
> and Scripts, and the Test Report.
>
> Reviews and tests are done at the end of each phase of the product
> development and configuration process to ensure that the features are
> complete and testable and that the product design, code,
> documentation, and data satisfy the requirements indicated in the Data
> Release Plan.
>
> The scope of activities performed by the Testing Team includes several
> categories of testing. They include:
>
> **Functional Test Cases**
>
> The Functional Test Cases address the Application Release and verifies
> that the user interface (UI) performs correctly according to the
> functional specifications. A test case is written for each functional
> component of the application and utilizes one or more data products.
>
> The test evaluates the user's ability to: navigate the system, view
> tables and maps, select geographies, search for geographies, tables
> and maps and retrieve static and topic content pages along with
> related help and glossary functions.

-   **Data Integration Test Cases**

> The Data Integration Test Cases address the Data Products and place
> emphasis on:

Verifying that the data displayed by the application is consistent with
the data delivered by the data providers.

-   Verifying that product tables and maps meet specifications for
    presentation, footnotes, head notes, columns, row titles, and cell
    formatting rules.

-   Verifying the ability to search and select product geographies,
    tables and maps via various search methods.

```{=html}
<!-- -->
```
-   

-   **Operational Test Cases**

> The Operational Test Cases address non-functional requirements and
> verify service level performance, usability, security and the
> integration of third party software.
>
> The start of the System Test Stage, under ideal conditions, includes
> all newly developed software components including application
> software, application and product metadata, and production grade data.
> This addresses the Application Release with New Data Product
> Deployment Concurrently delivery pattern as described in the DADS
> Software Development Plan. All defined test cases are executed
> including: Functional, Data Integration and Operational test cases. At
> this stage, all design, construction, hardware, and software
> components are in place and verified as a cohesive system. During test
> execution, all components are fully integrated and tested for the
> first time. This process not only identifies the risk of implementing
> new releases into production, but; it measures the quality that is
> present in the product at a given time, under given conditions
>
> For the Application Release with new Data Product Development later
> delivery pattern, manufactured data or pre-production data is used to
> start testing. Functional Test Cases are executed. Data Integration
> test cases are executed as well, but on a limited scale, since the
> data and, perhaps, metadata are not production grade. Only those
> sections that can be tested are executed. The Operational Test Phase
> is not conducted until production grade data is delivered.
>
> The Existing Data Product with New Data Product Deployment delivery
> pattern includes Data Integration test cases, and is conducted after
> production grade data is delivered from the data providers. Depending
> on schedules and other elements, these tests will likely be conducted
> in parallel with the User Acceptance Test Stage.
>
> Clarity on beginning and end of testing is provided by the entrance
> and exit criteria. These criteria aid in determining the beginning and
> ending milestones under normal operating conditions. Exceptions will
> be made in unique situations as needed. When aberrations are
> identified between the specifications and the impending release, the
> findings are brought to management so that a decision can be made as
> to whether the system is operational and ready for production.

#### 

#### 

#### Support User Acceptance Testing

> User Acceptance Testing is the final Data Provider Review of the data
> and metadata prior to the Production Deployment. The goal of User
> Acceptance Testing is to enable the data providers to confirm that the
> Data Products are ready for public release. As a part of this process,
> the data providers develop a list of issues with an established
> severity and priority for the DADS Team.

#### 

#### 

#### Prepare and send "Data Dumps"

> Data dumps are extracts from metadata and data that has already been
> processed through the DADS Product Development and Configuration
> Process. Data Providers, specifically ACSO, utilize data dumps to
> validate the DADS data and metadata loading processes. Data providers
> review and validate that the data and metadata that has been processed
> by DADS is equal to the data and metadata that was sent by the Data
> Provider and that the data has been loaded correctly. The Data Dumps
> have more recently become an integral part of the Data Provider's User
> Acceptance Testing process. Data Dumps are typically created 1-2 days
> after a data load to the Internal Review environment. Data Dumps can
> also be completed on an as needed basis.
>
> Data Dumps are usually created by Data Warehouse Operators who
> initiate the Data Dump scripts and the Data Warehouse Developers who
> validate that the scripts have run correctly, resolve any issues if
> they occur and inform the data provider when they are available.
>
> Core processing steps involved in preparing data dumps include:

1.  Prepare and update scripts (if necessary). Typically done only if
    new products are added.

2.  Execute Scripts

3.  Monitor Progress

4.  Review Log Files

5.  If errors found, identify errors and report to DW Developer;
    Developer corrects and resolves errors.

6.  If no errors found, DW Developer Validates Results

7.  If errors found, resolve errors and return to #2.

8.  If no errors found, load to FTP directory.

9.  Archive previous data dump

10. Notify data provider.

11. Repeat steps for each data product.

#### 

#### 

#### Manage Product Approvals and Signoffs (Data Provider)

The management of Data Provider Approvals and Signoffs varies by Data
Provider. For Econ, DADS has created an automated process to allow the
data provider to review and approve on a file by file basis each
component of the Data Release. A table is automatically generated as a
part of the Product Deployment Process to allow the data provider to
enter their acceptance and approval of the file for the deployment. For
ACSO and all other data providers, an email confirmation is sent to
confirm their acceptance and approval of the Data Release prior to
deployment.

1.  []{#__RefHeading___Toc152740748 .anchor}Product Deployment

### Overview

The Product Deployment Phase establishes the existence of data and
metadata in one of the DADS environments within an agreed upon
timeframe. The activities in this phase include deploying the product;
as well as creating a deployment plan and test report to document the
outcome of the deployment.

The Product Deployment Phase requires communication between the data
warehouse team, the application development team, the system test team,
BOC members on the DADS team and BOC data providers who are external to
DADS. The objective of communication between these stakeholders is to
ensure a smooth product deployment process and accurate dissemination of
the product. The BOC (DADS team members and data providers) is involved
in the product deployment process even in the development environment
known as "dry-run." The choice to involve the BOC early in the
deployment process is meant to accommodate the need for early preview
and verification of the data and metadata, especially for bi-monthly
Economic data, but also other data providers on an "as-needed" basis.

The table below specifies the roles involved in the Product Deployment
Phase. Please note that some of these roles are outside the DADS
program.

+----------------+-----------------------------------------------------+
| Roles          | Primary Responsibilities                            |
+================+=====================================================+
| System Test    | -   Creates Test Report                             |
|                |                                                     |
|                | -   Verifies data                                   |
+----------------+-----------------------------------------------------+
| Application    | -   May test data delivery when it is needed to     |
| Developer      |     support application functionality               |
+----------------+-----------------------------------------------------+
| Database       | -   Prepares database environments for a release    |
| Administrator  |                                                     |
|                | -   Executes production deployment                  |
+----------------+-----------------------------------------------------+
| Data Warehouse | -   Promotes data to pre-production database        |
| Developer      |     environments                                    |
+----------------+-----------------------------------------------------+
| BOC Data       | -   Provides product specification files            |
| Provider       |                                                     |
|                | -   Reviews and approves data                       |
+----------------+-----------------------------------------------------+
| DADS SME       | -   Reviews and approves data                       |
|                |                                                     |
|                | -   Communicates decisions with Data Providers and  |
|                |     Data Warehouse Team                             |
+----------------+-----------------------------------------------------+

Product deployment is accomplished using a variety of different methods
to make the products available in a database environment. These methods
include:

-   FTP

-   ETL scripts

-   SQL Loader

-   Manual edits

-   Oracle import/export

-   ESRI import/export

-   Transportable table spaces

```{=html}
<!-- -->
```
-   Clone

The choice of which deployment method(s) to use is left up to the data
warehouse team, whose members are entrusted with determining what best
practice techniques pose the least risk and will most efficiently make
the product release available in a given situation. However, product
deployment methods generally vary in predictable ways based on:

-   Type of data stored in database (e.g. metadata, data warehouse,
    spatial map data)

-   Target environment (e.g. development, system test, internal review,
    production)

```{=html}
<!-- -->
```
-   (e.g., Decennial Census vs. American Community Survey )

For example, ACS metadata is almost always migrated from internal review
(IR) to production Leg 1 via a database clone; whereas a bi-weekly
Economic metadata deployment is almost always deployed into Leg 1 by
re-executing ETL scripts in the production environment. However, if ACS
and Economic metadata both need to be promoted from IR to Leg 1 at the
same time, the clone method is used for both since the clone created for
ACS will contain ECON data and will eliminate the need for executing ETL
scripts in production.

### High Level Process Diagram

The following high level process diagram depicts how the product
deployment process occurs in the current operational system.

![](media/image11.wmf){width="6.491666666666666in"
height="4.204861111111111in"}

### Current Process Description

#### Prepare and Manage Environments

The preparation and management of environments involves many activities
that are executed by the database administrator. The activities involved
in preparing database environments include:

-   Collect database statistics

```{=html}
<!-- -->
```
-   Size database

Among the tasks involved in preparing each database environment for a
deployment is sizing the database to handle the anticipated quantity of
data in a release.

#### Execute Promotion Processes

Product promotion involves one or more of the following seven techniques
that make data available in a database environment:

-   FTP

-   ETL scripts

-   SQL Loader

-   Manual edits

-   Oracle import/export

-   ESRI import/export

```{=html}
<!-- -->
```
-   Transportable table spaces

Note that cloning is only used as part of production deployment, a topic
that is discussed in the next section.

The choice of which promotion methods to use is largely driven by: 1)
the storage function of the target database; 2) the target database
environment; and, 3) the survey. These three parameters result in
divergent, but predictable process differences.

Prior to the product promotion process, the target database function,
target environment and survey are identified; promotion methods are
selected; and work is assigned to a member of the data warehouse team.
Customarily an ETL developer executes any processes that involve ETL
scripts, while a database developer works with FTP, SQL Loader, Manual
edits, Oracle Import/Export, and ESRI Import/Export. Only the Database
Administrator is permitted to clone or transport table spaces.

The first major difference in product promotion methods reflects the
storage function of the database involved: metadata storage, data
warehouse data storage, or spatial data storage. Table 2 summarizes the
promotion method(s) used to make data available for each of these
database functions. The table can be interpreted as follows: regardless
of environment (development vs. product assurance) or survey (ACS vs.
Decennial), if metadata needs to be promoted, the data warehouse team
will use one or more of the listed methods to accomplish the task.

Table 2: Promotion Methods by Database Function

+----------------------------+-----------------------------------------+
| Database Function          | Promotions Method(s)                    |
+============================+=========================================+
| Metadata Storage           | Manual Edits                            |
|                            |                                         |
|                            | FTP                                     |
|                            |                                         |
|                            | ETL Scripts                             |
|                            |                                         |
|                            | Oracle Import/Export                    |
+----------------------------+-----------------------------------------+
| Data Warehouse Storage     | Oracle Import/Export                    |
|                            |                                         |
|                            | SQL Loader                              |
|                            |                                         |
|                            | Transportable Tablespaces               |
+----------------------------+-----------------------------------------+
| Spatial Map (ESRI) Storage | ETL Scripts                             |
|                            |                                         |
|                            | ESRI import/Export                      |
+----------------------------+-----------------------------------------+

Environment is the second factor that has an influence on the promotion
method(s) utilized. For example, development and product assurance share
the same spatial database; and internal review and product assurance
share the same data warehouse. Therefore, once spatial data is loaded to
development, it is essentially already promoted to product assurance.
The same is true with data warehouse tables in the internal review
environment; once those tables are made available to product assurance,
they are available to internal review as well.

Survey is the third factor that influences the promotion method(s)
utilized. For example, ETL scripts may be used to promote ECON metadata
from one environment to the next, but non-spatial geographic metadata
may be imported from a staging database.

The matrix depicted in Table 3 summarizes the promotion method(s)
implemented by database function, target environment and presentation
type. A detailed discussion follows.

Table 3: Promotion Methods by Database Function, Presentation Type and
Environment

+--------+----------------+-------------+-------------+-------------+
| Da     | Presentation   | Environment |             |             |
| tabase | Type           |             |             |             |
| Fun    |                |             |             |             |
| ction  |                |             |             |             |
+========+================+=============+=============+=============+
|        |                | DEV         | PA          | IR          |
+--------+----------------+-------------+-------------+-------------+
| Me     | Detailed ECON  | Scripts     | Scripts^a^  | Scripts^a^  |
| tadata | Stats          |             |             |             |
| (E     |                |             |             |             |
| nglish |                |             |             |             |
| Only,  |                |             |             |             |
| S      |                |             |             |             |
| panish |                |             |             |             |
| is     |                |             |             |             |
| sl     |                |             |             |             |
| ightly |                |             |             |             |
| diff   |                |             |             |             |
| erent) |                |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Quick Reports  |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Detailed       |             |             |             |
|        | Tables         |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Quick Tables,  |             |             |             |
|        | Data Profiles, |             |             |             |
|        | Subject        |             |             |             |
|        | Tables,        |             |             |             |
|        | Iterated       |             |             |             |
|        | Profiles,      |             |             |             |
|        | Subpop         |             |             |             |
|        | Profiles       |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Ranking        |             |             |             |
|        | Tables,        |             |             |             |
|        | Geographic     |             |             |             |
|        | Comparison     |             |             |             |
|        | Tables         |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Thematic Maps  |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | DWMM           | Scripts     | Scripts^a^  | Scripts^a^  |
+--------+----------------+-------------+-------------+-------------+
|        | Non-spatial    | Oracle      | Oracle      | Oracle      |
|        | Geo            | Import^b^   | Import      | Import      |
+--------+----------------+-------------+-------------+-------------+
|        | Manually       | Scripts     | Scripts     | Scripts     |
|        | entered        |             |             |             |
|        | Metadata       | Toad        | Toad        | Toad        |
+--------+----------------+-------------+-------------+-------------+
| Data   | Detailed ECON  | Scripts^c^  | Oracle      | N/A DW is   |
| (      | Stats          |             | Import      | shared with |
| Ignore |                |             |             | PA          |
| the    |                |             | Tr          |             |
| ACS    |                |             | ansportable |             |
| wave   |                |             | Table space |             |
| sit    |                |             |             |             |
| uation |                |             | Scripts^c^  |             |
| that   |                |             |             |             |
| we     |                |             |             |             |
| re     |                |             |             |             |
| cently |                |             |             |             |
| ha     |                |             |             |             |
| ndled) |                |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Detailed       |             |             |             |
|        | Tables         |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Data Profiles  |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Subject Tables |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Iterated       |             |             |             |
|        | Profiles       |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Sub-pop        |             |             |             |
|        | Profiles       |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | Ranking Tables |             |             |             |
+--------+----------------+-------------+-------------+-------------+
| S      |                | Script      | N/A DB is   | Script      |
| patial |                | based ESRI  | shared with | based ESRI  |
| Data   |                | Flat File   | Dev         | Flat File   |
|        |                | Load        |             | Load        |
+--------+----------------+-------------+-------------+-------------+
| Other  | Sagent Address | FTP         | FTP         | FTP         |
| (      | File           |             |             |             |
| server |                |             |             |             |
| spe    |                |             |             |             |
| cific) |                |             |             |             |
+--------+----------------+-------------+-------------+-------------+
|        | AXL Files      | FTP         | FTP         | FTP         |
+--------+----------------+-------------+-------------+-------------+

a -- table structure (schema) imported from a staging database and then
scripts are run to populate tables.\
b -- metadata is created in a staging database and is exported from the
staging database into another database using Oracle Import/Export\
c -- SQL Loader is used to run all scripts except scripts for Data
Profiles and Ranking Tables. Data Profile and Ranking Table scripts are
run using Informatica.

#### Conduct Production Deployment

During the Production Deployment Phase, metadata, data warehouse data
and spatial data is moved into production environments using techniques
that ensure the data implemented is the data that has been tested and
approved. The database administrator, and sometimes ETL and database
developers conduct production deployment, making sure that databases
needed to make American Factfinder work are continually available during
the deployment.

There are a variety of potential inputs to a production deployment
depending on the selected promotion method(s). In all cases however,
approval and sign-off from subject matter experts and data providers is
required in the Internal Review environment before production deployment
can begin. Approval is obtained through a subject matter expert who
communicates via email to the data provider and forwards approval via
email back to the data warehouse team. One small exception exists for
the Economic Division which sets flags in product database to 'Y' in
order to indicate approval for individual economic products. A subject
matter expert checks this database and sends the data warehouse team an
email listing approved products.

Once approval is received, data is deployed to the Leg 1 production
environment. The data warehouse team will select the least expensive and
least risky means of moving data into Leg 1 databases.

Generally metadata will be cloned from the Internal Review environment
to the Leg 1 Production environment. However, if a data provider's
scheduled delivery does not coincide with all others, ETL scripts will
be re-executed in the Leg 1 Production environment and sometimes Oracle
Import/Export will be used to migrate an entire database object (e.g. a
table or database index). This enables the fraction of data specified by
the data provider to be made available, while preserving the state of
the rest of the data in production.

Spatial data is the outlier in the process since spatial files are
always FTP'd to the target spatial database and the ESRI import/export
utility along with ETL scripts are always used to transform and load the
spatial data.

Data warehouse data is usually moved over from Internal Review to both
production legs using transportable table spaces or Oracle
Import/Export. Both methods allow data to be moved over at level of
granularity specific to a data provider.

After data is moved into Leg 1 a second round of BOC approvals follows
before data is moved to Leg 2 databases. During the migration of data to
Leg 1, Leg 1 databases are taken out of the live production site so that
users are unaffected as the deployment proceeds. Following completion of
deployment to Leg 1, the live production site is pointed back to Leg 1
and then Leg 2 is taken out of production, updated and put back into
production. This methodology ensures that production data deployment is
invisible to users and requires no downtime. In addition, alternating
production data deployment makes it possible to prepare a product
release on one Leg and make it live at a very specific time.

The matrix depicted below in Table 4 details the production deployment
methods used.

Table 4: Production Deployment by Database Function, Product and
Environment

+-------------+---------------+-------------------+-------------------+
| Database    | Product       | Environment       |                   |
| Function    |               |                   |                   |
+=============+===============+===================+===================+
|             |               | PROD (Leg1)       | PROD (Leg2)       |
+-------------+---------------+-------------------+-------------------+
| Metadata    | Detailed ECON | Scripts           | Clone             |
| (English    | Stats         |                   |                   |
| Only,       |               | Import Staging    |                   |
| Spanish is  |               | Schema            |                   |
| slightly    |               | (stage_XXX)       |                   |
| different)  |               |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Quick Reports |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Detailed      |                   |                   |
|             | Tables        |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Quick Tables, |                   |                   |
|             | Data          |                   |                   |
|             | Profiles,     |                   |                   |
|             | Subject       |                   |                   |
|             | Tables,       |                   |                   |
|             | Iterated      |                   |                   |
|             | Profiles,     |                   |                   |
|             | Sub-pop       |                   |                   |
|             | Profiles      |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Ranking       |                   |                   |
|             | Tables,       |                   |                   |
|             | Geographic    |                   |                   |
|             | Comparison    |                   |                   |
|             | Tables        |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Thematic Maps |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | DWMM          | Scripts           | Clone             |
|             |               |                   |                   |
|             |               | Import Staging    |                   |
|             |               | Schema            |                   |
|             |               | (stage_dw_meta)   |                   |
|             |               | -- have seen hand |                   |
|             |               | edits             |                   |
+-------------+---------------+-------------------+-------------------+
|             | Non-spatial   | Oracle Import     | Clone             |
|             | Geo           |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Manually      | Scripts           | Clone             |
|             | entered       |                   |                   |
|             | Metadata      | Toad              |                   |
+-------------+---------------+-------------------+-------------------+
| Data        | Detailed ECON | Oracle Import     | Clone             |
| (Ignore the | Stats         |                   |                   |
| ACS wave    |               | Transportable     | Transportable     |
| situation   |               | Table Spaces      | Table Spaces      |
| that we     |               |                   |                   |
| recently    |               | Scripts           |                   |
| handled)    |               | (sqlloader used   |                   |
|             |               | for all except    |                   |
|             |               | Data Profiles and |                   |
|             |               | Ranking Tables    |                   |
|             |               | which use         |                   |
|             |               | Informatica)      |                   |
+-------------+---------------+-------------------+-------------------+
|             | Detailed      |                   |                   |
|             | Tables        |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Data Profiles |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Subject       |                   |                   |
|             | Tables        |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Iterated      |                   |                   |
|             | Profiles      |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Sub-pop       |                   |                   |
|             | Profiles      |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | Ranking       |                   |                   |
|             | Tables        |                   |                   |
+-------------+---------------+-------------------+-------------------+
| Spatial     |               | Script based ESRI | Script based ESRI |
| Data        |               | Import/Export     | Import/Export     |
+-------------+---------------+-------------------+-------------------+
| Other       | Sagent        | FTP               | FTP               |
| (server     | Address File  |                   |                   |
| specific)   |               |                   |                   |
+-------------+---------------+-------------------+-------------------+
|             | AXL Files     | FTP               | FTP               |
+-------------+---------------+-------------------+-------------------+

#### Prepare Test Report

A Test Report is an artifact of the Production Deployment Phase. The
Test Report is used to document and summarize the system testing
activities that were used to verify and validate the readiness of the
products and the application prior to public release.

The components of a test report are:

-   Risk assessment

-   Test cases that were executed

-   Features and defects

-   Environments tested

```{=html}
<!-- -->
```
-   Test strategy

The report utilizes many input sources including:

-   Features and Defects from defect management system

-   Functional requirements written by business analysts

```{=html}
<!-- -->
```
-   Builds received

The System Test team compiles the Test Report after data is deployed to
production. The System Test team sends the test report the BOC to
collect initial comments. Additional testing or modifications to the
Test Report may be required as a result of the BOC's initial feedback.
Once System Test has closed issues brought up by the BOC, the System
Test team sends the Test Report to the DADS PMO team to obtain signoff
from the Bureau. The outcome of the Test Report is either signoff from
the BOC or a request for more information about an open item. In general
all defects marked HIGH must be resolved to gain approval.

#### Prepare Deployment Plan

The Prepare Deployment Plan Phase documents the deployment process,
contents, issues and lessons learned. This phase consists of activities
such as compiling a list of contributing data providers and sources and
gathering feedback from the data warehouse team. The business objective
of the deployment plan is to provide traceability.

Typically the data warehouse team lead has responsibility for creating
the deployment plan after a product release to production. The team lead
then sends the deployment plan via email to the DADS project management
office and subject matter experts to obtain sign-off.

#### Manage Product Approvals and Signoffs (BOC)

Approvals are obtained from data providers to promote and deploy
products. The objective of these approvals is to ensure the data
provider is verified the accuracy of the data and is comfortable with
releasing it to the public. Approvals are obtained before promoting from
Internal Review to Production Leg 1 and before deploying from Leg 1 to
Production Leg 2. On occasion, approval may be required at an earlier
promotion stage. For example, bi-weekly Economic Census data deployments
are delivered to a development environment; reviewed and approved by the
data provider; and then promoted directly to the Internal Review
environment.

Approvals are primarily managed by email communication with one
exception. The Economic Census Division uses a product database to flag
the products they are approving for promotion/deployment.

The data warehouse team will notify a subject matter expert when data is
ready for review. The subject matter expert will send an email request
to the data provider requesting a review. Once the data provider has
reviewed the data, the data provider sends an email back to the subject
matter expert approving/disapproving the product. The subject matter
expert communicates this correspondence back to the data warehouse team.

The result of the approval process is that data is corrected, made
available to the public or retracted.

#### Manage Workflow

Product deployment workflow management involves specifying roles and
responsibilities, organizing the sequence of work units, coordinating
transitions and monitoring status. The objective of workflow management
is to inform stakeholders of status and ensure product delivery occurs
on time and without error.

During the workflow management phase several documents are created.
These include:

-   Detailed Work Plan

-   Project Plan

```{=html}
<!-- -->
```
-   Deployment Checklist

Generally the data warehouse team lead compiles the detailed work plan,
project plan and deployment checklist with input and guidance from the
data warehouse team. These documents are created at the beginning of
each product release.

As the product promotion or production deployment precedes,
communication between teams, subject matter experts, and data providers
is necessary to coordinate hand-offs. Email is the primary tool used to
communicate status and initiate hand-offs in the workflow. For example,
after the data deployment team promotes data to the product assurance
databases and email alert is sent to the system test team. The system
test team performs a smoke test and sends an email to the data warehouse
team indicating success or failure.

The result of the workflow management process is the successful
deployment of data.

## Product Maintenance and Support

### Overview

The Product Maintenance and Support phase is the fifth phase in the DADS
Operational System for Data Dissemination. The primary goal of this
phase is to ensure the continued availability of the Product via a set
of pro-active and re-active procedures. In general, pro-active
procedures apply to all Products; These are procedures which have been
setup for AFF and apply regardless of the number of Products currently
available in AFF. Re-active procedures generally apply to specific
Products and are initiated by a specific event, for example, an email
inquiry.

This phase begins after a Product has been deployed to External
Production. If a Product has to be re-delivered that process is covered
by the Product Deployment phase.

Activities covered by this phase apply equally to all Products
disseminated by the AFF system. Therefore, when a Product is deployed it
is added to the list of Products covered by this phase. For example,
after a Product is deployed it is inherently monitored for availability
by Topaz and Red Alert.

+----------------+-----------------------------------------------------+
| Roles          | Primary Responsibilities                            |
+================+=====================================================+
| SysTest        | -   Responds to errors, inquiries, and other        |
|                |     outside events.                                 |
|                |                                                     |
|                | -   Establishes and monitors Web-Trends.            |
|                |                                                     |
|                | -   Establishes and monitors Topaz and Red Alert.   |
+----------------+-----------------------------------------------------+
| Application    | -   Responds to errors, inquiries, and other        |
| Developer      |     outside events.                                 |
|                |                                                     |
|                | -   Unofficially monitors user feedback for early   |
|                |     indication of application problems.             |
+----------------+-----------------------------------------------------+
| DBA            | -   Responds to errors, inquiries, and other        |
|                |     outside events.                                 |
|                |                                                     |
|                | -   Monitors database performance                   |
|                |                                                     |
|                | -   Performs regular operational tasks to move user |
|                |     feed back information from the External         |
|                |     Production environment to the Internal Review   |
|                |     environment.                                    |
+----------------+-----------------------------------------------------+
| Data Warehouse | -   Responds to errors, inquiries, and other        |
| Developer      |     outside events.                                 |
|                |                                                     |
|                | -   Ensure upward compatibility of existing         |
|                |     Products when new application releases occur.   |
+----------------+-----------------------------------------------------+

#### Tools/Applications used by this phase.

+---------------------+------------------------------------------------+
| Tool                | Description                                    |
+=====================+================================================+
| Topaz               | External monitoring service that routinely     |
|                     | checks to see if the application is running    |
|                     | appropriately. Our profile tests availability  |
|                     | (of AFF) from 5 pre-determined locations       |
|                     | across the US approximately once an hour.      |
|                     |                                                |
|                     | The primary difference between Red Alert and   |
|                     | Topaz is that Topaz is initiated from outside  |
|                     | of the Census firewall and provides a view of  |
|                     | the External system as seen by a public user.  |
+---------------------+------------------------------------------------+
| Red-Alert           | Internal monitoring tool that routinely checks |
|                     | to see if the application is running           |
|                     | appropriately.                                 |
+---------------------+------------------------------------------------+
| Web-Trends          | Tool that scans the web server logs to produce |
|                     | a set of web based metrics.                    |
+---------------------+------------------------------------------------+
| Wrtie Now           | Trouble ticket system used by DADS.            |
+---------------------+------------------------------------------------+
| User Feedback       | System built into the AFF application to       |
|                     | accept and capture user feedback.              |
+---------------------+------------------------------------------------+
| Scripted tools      | Set of scripts developed by the DBA to monitor |
|                     | and report on database performance. Used for   |
|                     | ongoing monitoring of the AFF system.          |
+---------------------+------------------------------------------------+
| Various (Toad,      | Data access tools used for diagnostic and/or   |
| SQLPlus, etc.)      | normal work activities.                        |
+---------------------+------------------------------------------------+

### High Level Process Diagram

![](media/image12.wmf){width="6.434722222222222in"
height="4.034027777777778in"}

### Current Process Description

#### Respond to Errors, Inquiries and Other Outside Events

This core activity collectively applies to all Products available on the
external website. It also applies to all other environments with
decreasing emphasis from external thru development. In other words,
external has the highest priority, development the least.

This is a general purpose process that handles the various requests that
are directed to the team. The process can be initiated by a phone call,
a conversation, an email (from a BOC source), a user feedback, or by
simply looking at the External website and noting something out of the
ordinary. All team members are empowered to initiate this process.

All team members may be involved in this activity; However the number
and level of involvement is based on several factors such as scope (does
it apply to the metdata, data, application, software), subject matter
(does it require subject matter expertise), and severity. A error on
External Production, for example, can immediately command all resources.

#### Monitor/Manage Performance

This core activity collectively applies to all Products available on the
external website. It also applies to all other environments with
decreasing emphasis from external thru development. In other words,
external has the highest level of monitoring, development the least.

The external website is pro-actively monitored by Topaz, Red-Alert, and
a set of DBA scripts. If one of these detection tools discovers a
performance problem a set of alerts is sent to the appropriate
individuals who then take action to further assess the situation and
optionally take corrective action.

The remaining environments are monitored by a set of DBA scripts. If
these scripts discovers a performance problem a set of alerts is sent to
the appropriate individuals who then take action to further assess the
situation and optionally take corrective action.

For all environments, the users of AFF provide real-time feedback on
performance. Indications of poor performance can be forwarded to the DBA
via email, a phone call, or in the case of the Team via a conversation.

For individual Products, especially the larger Products, it may be
necessary for the DBA to perform some specific monitoring and/or manage
some of the lower level storage aspects of the Product. These activities
do not affect the functionality of AFF and are handled in a manner such
that access to the Product is not disrupted. These activities are quite
normal and considered normal DBA activities.

This activity is primarily handled by the DBA; However any member of the
Team can be asked to assist.

#### Monitor User Feedback

This core activity collectively applies to all Products available on the
external website. In other words, it applies to the entire AFF
application. More specifically, this core activity applies to Products
on the External Production site -- since User Feedback is generated from
that environment.

Monitoring user feedback is a duty carried out by the BOC staff. They
may enter user feedback into the BOC RightNow system depending on the
type of feedback. It is a BOC responsibility to respond to the user (if
appropriate) and/or take actions to \'close\' the user feedback. In
other words, the IBM team is not responsible for monitoring or
responding to user generated feedback.

A member of the Application Development Team, on a pro-active basis,
monitors user feedbacks once a day -- or more often if the circumstances
warrant more frequent monitoring, for example, the day after a major
application release. This un-official duty gives the IBM team advanced
warning of any systemic problems related to the AFF website. The IBM
team may also provide the BOC staff will additional information about a
specific user feedback either on a pro-active or re-active basis. In
either case, the information is always given to the BOC staff and never
to the user that originated the user feedback.

This activity is handled by a designated member of the Application
Development Team; however any member of the Team can be asked to assist.

#### Manage Compatibility of the Products with Newer Versions of the App

This core activity collectively applies to all Products available on the
external website; and, perhaps Products that have only been released as
far as Internal Review. More specifically, this core activity generally
applies to all Products on the External Production site but sometimes it
takes some individual analysis to determine if there are some Products
which need to be specially handled.

From the perspective of the user and the data Provider, once a Product
is released on the External Production website it remains forever
unchanged. However, upgrades to the various layers that make up the AFF
website may require that Products be \'upgraded\' to remain compatible
with the AFF application. This is based on the fact that Product
metadata is stored in a common format in the Metadata Repository.
Therefore, all Products must conform to a metadata standard (as
determined by the IBM team) in order to be compatible with the AFF
application.

This activity can be triggered by a Defect or Feature; however, the most
common trigger is a major version upgrade of the AFF application (for
example, from 10.4 to 10.5).

This activity is generally the responsibility of one or more Data
Warehouse Team Developers. Upgrades that fall under this activity
generally involve structural changes to the MDR. The question of Product
compatibility arises and it is up the Data Warehouse Team Developers to
determine if the Product metadata stored in those structures requires an
upgrade. If so, the Developers are responsible for developing the
procedures to carry out the upgrade.

#### Monitor/Manage User Statistics and User Feedback

This core activity collectively applies to all Products available on the
external website. More specifically, this core activity generally
applies to the AFF application and is not Product specific. This is an
ongoing activity that is not critical for dissemination; whereas the
other parts of the AFF application are required for the AFF application
to functionally disseminate a Product, the User Statistics database and
the User Feedback database are not functionally critical parts.

It may be necessary for the DBA to perform some specific monitoring
and/or manage some of the lower level storage aspects of these
databases. These activities do not affect the functionality of AFF and
are handled in a manner such that the AFF website s not disrupted. These
activities are quite normal and considered normal DBA activities.

This activity is primarily handled by the DBA; however any member of the
Team can be asked to assist.

#### Permanently Remove a Product and Archive a Product

This core activity applies to a single Product. After a Product has been
deployed to External Production it may become necessary to remove that
Product. Products are removed at the direction of the BOC; IBM does not
determine if a Product is to be removed from the External website.

Since the decision to remove a Product rests solely with the BOC the
reason for removing a Product varies, However, Products are generally
removed due to the following reasons:

-   A disclosure issue has been identified with the Product.

-   The Product is being depreciated -- perhaps in favor of another
    Product. The \'rolling\' PEP Products are an example.

```{=html}
<!-- -->
```
-   The Product is out of date. 1992 Econ Products are an example.

The term \'remove a Product\' has several meanings depending on the
context in which it is used. Note that a Product, when deployed to any
environment, consists of one or more parts (see below). The parts work
together; so, for example, a Product will not be visible unless the
metadata has been deployed; however, even though it is visible, valid
pages cannot be rendered unless the data warehouse has been properly
populated. In other words, the availability of a Product is dependent on
which parts are available; Removing one part, namely the metadata, can
effectively render it unavailable.

The term \'remove a Product\' can be applied in the following manner:

**\'Temporary remove\', or \'Turn off a Product\'** -- Using an AFF
feature built into the AFF code, temporary make a Product unavailable by
altering a flag in the Metadata. All \'parts\' of the Product remain on
the External Servers but that Product is not visible in the Application
and is therefore unavailable to users.

**\'Remove a Product\'** -- Remove the metadata for that Product, and
optionally the data, spatial data, and FTP data. Removing the metadata
effectively removes the Product from the AFF website; without the
metadata the application cannot access the data or the spatial data. The
exception to this is the FTP data. Users can access the FTP independent
of the AFF application.

**\'Completely remove a Product\'** -- Remove all parts of the Product
from the External servers so that it appears as if the Product never
existed. This level of removal may be required if, for example, data was
found to have violated disclosure and had to be pulled back from public
release.

There is no formal procedure for archiving a Product. However, the
original parts that were used to build the Product are preserved as per
normal procedures. Therefore, all of the constituent parts that were
required to originally build and deploy the Product are archived.

This activity is generally the responsibility of one or more Data
Warehouse Team Developers and the DBA.

Parts to deploy a Product

-   Metadata - Mandatory

-   Data (data warehouse) -- Optional

-   Spatial data -- Optional

```{=html}
<!-- -->
```
-   Data, available on the FTP Site in a downloadable format -- Optional