Information Technology

Database Instance Usage

Strategy

Updated: 1/9/08

Table of Content
1
2
3
4

5
6
7
8

Purpose.................................................................................................................................. 2
Migration Paths To Production................................................................................................ 2
Migration Paths After Production............................................................................................ 2
Databases.............................................................................................................................. 3
4.1 Patch.................................................................................................................................. 3
4.2 DEV4................................................................................................................................. 3
4.3 PREPROD......................................................................................................................... 4
4.4 TRN................................................................................................................................... 4
4.5 DEV................................................................................................................................... 5
4.6 PRETEST.......................................................................................................................... 5
4.7 TEST.................................................................................................................................. 6
4.8 CRP................................................................................................................................... 6
4.9 CNV................................................................................................................................... 7
4.10
QA................................................................................................................................. 7
Clone Refresh Guidelines...................................................................................................... 7
Change Tracker...................................................................................................................... 8
Testing Approach.................................................................................................................... 8
Instance Flow Chart............................................................................................................... 9

Updated: 1/9/08

1 Purpose
The NCH Database Instance Usage Strategy supports and coordinates custom development,
system testing, database migration, user training, and issue resolution. Databases are used
for limited purposes by specific individuals and are refreshed on a regular basis or at
particular times. Migration paths are defined for NCH production support and module
implementation.

2 Migration Paths To Production

Production Support
Path: DEV4 > PREPROD > PROD
Production Support Small Patch
Path: PATCH > DEV4 > PREPROD > PROD
Production Support Large Patch
Path: PATCH > DEV4 > PREPROD > PROD
Alternate: PATCH > DEV > TEST > PROD
Implementation
Path: DEV > PRETEST > TEST > QA > PROD > PREPROD
* Conversions/CRPs: CNV or CRP (optional)
Fast Track Implementation
Path: DEV > TEST > QA > PROD > PREPROD
* Conversions/CRPs: CNV or CRP (optional)

3 Migration Paths After Production

To ensure consistency, within the instances, it is imperative all code, patches, setups and
stabilization be propagated back down through the below Production Support or
Implementation paths. Responsibilities are as follows: TECH Team code changes, FUNC
Team setups, DBA Team patches.
Implementation
Path: PROD > QA > TEST > PRETEST > DEV
Production Support
Path: PROD > PREPROD > DEV4

Updated: 1/9/08

4 Databases
The NCH Instance Usage Strategy will use eleven databases. Each database will be supported
by NCH I/T Technical Support and utilized by various individuals to support the seven migration
paths.

4.1

Patch
Name:

PATCH

Users:

DBA Team
*FUNC Team / TECH Team - Optional

Change
Control:

Refreshed from PROD as needed.

* Refresh of PATCH is outside Instance Review Boards governance.

Paths:

Production Support Small Patch / Production Support Large Patch

Testing:

System Check / Unit Test as required

Notes:

PATCH is considered the primary patching instance for performing a system

check in support of production and implementations.
All patches must be applied to this instance prior to applying to any other
instance.

4.2

DEV4
Name:

DEV4

Users:

PROD Support / TECH Team / FUNC Team

*Superusers - Optional

Change
Control:

Refreshed from PROD every 4-wks. Refresh request in addition to the 4-wk
cycle will be reviewed and approved by the Instance Management Team.
DEV4 must be refreshed in conjunction with PREPROD.

Paths:

Production Support / Production Support Small Patch / Production Support

Large Patch

Testing:

Unit Testing

Notes:

DEV4 is considered the primary instance for unit testing in support of

production.
Once a configuration is in production, support must be conducted via the
Production Support path. This includes stabilization of new implementations.

Updated: 1/9/08

4.3

PREPROD
Name:

PREPROD

Users:

PROD Support / FUNC Team / TECH Team / Superusers / Local Power

Users

Change
Control:

Refreshed from PROD every 4-wks. Refresh request in addition to the 4-wk
cycle will be reviewed and approved by the Instance Management Team.
PREPROD must be refreshed in conjunction with DEV4.

Paths:

Production Support / Production Support Small Patch / Production Support

Large Patch / Implementation / Fast Track Implementation

Testing:

System and Integration Testing

Notes:

PREPROD is considered the primary instance for system and integration

testing in support of production.
PREPROD is considered the secondary instance for system and integration
testing in support of implementations. Changes are promoted to PROD after
QA then cloned down to PREPROD for a final test.

4.4

TRN
Name:

TRN

Users:

All

Change
Control:

Refreshed from PROD as needed. Refresh request will be reviewed and

approved by the Instance Management Team.

Paths:

N/A

Testing:

None

Notes:

TRN is considered the secondary training instance.

Users will primarily be trained on new configuration and module
implementation before implementation into Production on QA. TRN will be
available as a backup when QA is not appropriate or available.

Updated: 1/9/08

4.5

DEV
Name:

DEV

Users:

TECH Team
*FUNC Team / Superusers - Optional

Change
Control:

Refreshed from TEST every 8-wks. Refresh request in addition to the 8-wk
cycle will be reviewed and approved by the Instance Management Team.

Paths:

Implementation / Fast Track Implementation

Testing:

Unit Testing & Development

Notes:

DEV is considered the primary instance for unit testing development and
patches in support of all Implementations.
* Setups are performed in DEV as requested by the technical team.

4.6

PRETEST
Name:

PRETEST

Users:

TECH Team / FUNC Team / Super Users / Local Power Users

Change
Control:

Refreshed from TEST as needed. Refresh request will be reviewed and

approved by the Instance Management Team.

Paths:

Implementation
*Fast Track Implementation Optional

Testing:

Unit Testing

Notes:

PRETEST is considered the primary instance for unit testing initial

configuration setups performed by the FUNC team in support of projects on
the Implementation path.
PRETEST is considered the primary instance for unit testing development
and patches in support of Implementations.
* Fast Track Implementations may use PRETEST for high risk changes.

Updated: 1/9/08

4.7

TEST
Name:

TEST

Users:

TECH Team / FUNC Team / Super Users / Local Power Users

Change
Control:

Refreshed from PROD every 6-months. Refresh request in addition to the 6month cycle will be reviewed and approved by the Instance Management
Team.

Paths:

Implementation / Fast Track Implementation

Testing:

CRPs, Unit, System and Integration Testing

Notes:

TEST is considered the primary instance for testing in support of projects on

the Implementation and Fast Track Implementation path. This is where we
ensure all rollouts are being tested together.
TEST is considered the primary instance for CRPs in support of projects on
the Fast Track Implementation path.

4.8

CRP
Name:

CRP

Users:

FUNC Team / Superusers / Local Power Users / Users

Change
Control:

CRP has a short lifecycle. Refresh are performed from TEST as needed.
Refresh request will be reviewed and approved by the Instance Management
Team.

Paths:

Implementation
*Fast Track Implementation Optional

Testing:

Conference Room Pilot

Notes:

CRP is considered the primary instance for CRPs in support of projects on

the Implementation path.
CRP is considered the secondary instance for CRPs and data conversions in
support of projects on the Fast Track Implementation path.

Updated: 1/9/08

4.9

CNV
Name:

CNV

Users:

TECH Team / FUNC Team / Superusers / Local Power Users / Users

Change
Control:

CNV has a short lifecycle. Refresh are performed from TEST as needed.
Refresh request will be reviewed and approved by the Instance Management
Team.
* Refresh could occur multiple times within a week.

Paths:

Implementation
*Fast Track Implementation Optional

Testing:

Conversion Test & Data Validation

Notes:

CNV is considered the primary instance for testing data conversions. This
instance is shared between projects.

4.10 QA
Name:

QA

Users:

FUNC Team / Superusers / Local Power Users / Users

Change
Control:

Refreshed from PROD every 3-months. Refresh request in addition to the 3month cycle will be reviewed and approved by the Instance Management
Team.

Paths:

Implementation / Fast Track Implementation

Testing:

User Acceptance Testing

Notes:

QA is considered the primary instance for User Acceptance Testing.

* FUNC Team includes third party acknowledgment on behalf of NCH.

5 Clone Refresh Guidelines

Standard Clone Procedure request for all clones/refreshes will be made through the PMO
office. All clone/refresh requests will be placed on the Instance Management schedule in a
status of Pending. Once approved by the Instance Review Board the status will be changed
to Approved.
It is the responsibility of all Functional Project Managers to line up their project plans with the
current Instance schedule. If they have an exception to that plan the Functional Project
Manager must put their cloning requesting into the PMO office for approval. This will give us
immediate visibility into future request and ensure other project teams can plan around
scheduled refreshes.

Updated: 1/9/08

6 Change Tracker
Technical and Functional users must enter production changes, as defined below, into Change
Tracker. At this time we do not have a requirement in place to use change tracker for other
instances.

Functional Changes
-

Concurrent Jobs
Profile Settings
Setups (options)
Descriptive Flexible Fields (DFF)
Personalizations (shared with Tech Team)

Tech Team Changes

-

Code Changes
Form Changes
Views
Reports
Personalizations (shared with Functional Team)
Workflow

7 Testing Approach
Testing is a significant part of our instance migration strategy. NCH employs a method of
continuous testing to help ensure the system delivers functions according to specification and
each group of rollouts is being tested together. Test cycles are tied to business requirements and
signed off by business users and I/T. A few objectives of our testing cycles are:

Validating the Detailed Business Design Solution

Testing focuses on actual business scenarios and processes
Verifying system configuration and master data
Systematically testing interfaces, conversions, enhancements, and reports
Establishing system security based on actual work roles
Testing proper control criteria for each transaction
Verifying compliance criteria

Our detailed system testing methodology is made up of several components:

o

Unit Testing verifies that individual programs execute without error, perform within
set standards and are of good quality. Unit testing is an iterative process that occurs
during the system development effort.

System Testing functional testing executed to verify that the transactions selected
and/or any configuration performed in Oracle and bolt-ons work to support a
specific business process. A single business process typically spans a number of
transactions.

Integration Testing verifies that the appropriate transactions, business processes,

policies, procedures, controls and systems are integrated and performing as
expected.

User Acceptance Testing provides an opportunity for the end-user community to

test and take ownership of the designed system, processes and procedures. Super

Updated: 1/9/08

users and other identified members of the organization conduct this testing so that
they can verify the business is supported.

Updated: 1/9/08

8 Instance Flow Chart

Updated: 1/9/08

10