|
Access to the Banner Instances are based on the project timeline.
Depending on when you are logging into Banner there may be different
choices.
SEED
SunGardHE installed this instance as part of the initial Banner
installation. No data conversion, loading, configuration, training,
or testing is to take place in this instance. All Banner patches
are to be applied to this instance first to verify patching procedures
and viability of the patch. This instance is not INB-enabled (it
is not available through Internet Native Banner). Only DBA will
have access to this instance. If necessary this instance can be
recreated from the Banner installation scripts.
TRNG (SunGard SCT Training)
This instance is initially a clone of the SEED database. It is used
for training purposes, both technical and functional. Initially
this training is SunGardHE-provided and will use SunGardHE-provided
data. Following the completion of the Banner implementation (all
modules), it may be created periodically from the PROD database
for end-user training. Upgrades and patches will be applied here
second in order to train users on new features available with the
Banner upgrade or patch. It is INB-enabled. Significant amounts
of test data, including users, will be available in TRNG. Generic
training accounts are typically used for access to this instance.
TEST (Testing/Development)
Data are loaded here either from CONV (initially) or straight
from the Plus environments once the conversion scripts have stabilized.
Rules and validation tables are loaded here from the CONF instance
or later from PPRD. Security is set up in this instance to facilitate
full testing scenarios and so may not mimic security to be set
up in production. Each user will have separate accounts instead
of generic accounts. End users will verify and validate rules
and converted data in this instance. Later on in the Banner implementation
process data will be loaded here from PROD as well as from Plus
(e.g., during the student implementation all financial and HR
data will come from PROD, while student and financial aid data
will come from SIS). Testing of SQL scripts may take place here
if it is not used for end-user testing. This instance is INB-enabled.
Following implementation of all Banner modules this instance will
be used only by application developers for creation of "bolt on"
applications, Banner channels for Luminis, or similar value-added
tools.
CONV (Conversion)
This instance is the repository for data initially converted
from our legacy systems. It is usually not INB-enabled. It will
be "scrubbed" multiple times as tweaks to the conversion
programs progress. Rules and validation tables will be loaded
here from TEST in order to assist in the testing of data conversion.
IT staff may use this instance to test SQL loading scripts or
perform other testing if TEST is in use for rules and data validation.
Application developers will have update access to database objects
in this instance. Once all Banner modules are implemented this
instance will be deleted.
PROD (Production)
Once we are authorized to proceed with "go live," the
data migration utilities are run against production SIS files
and loaded into the production database. Rules and validation
tables are copied from TEST to PROD. No seed or testing data of
any sort, including test students or employees, are to be created
in the production environment. Application developers have read-only
access to production Banner objects.
Requesting A New Instance
All requests for new instances must be made in writing to the
IT process team leader. The request must contain the following
information:
- Intended use of the instance
- Proposed instance name (subject to change by the IT process
team)
- What data, rules, and validation tables will be housed in
the instance (e.g., seed, conversion, or production data)
- Where the data, rules, and validation tables in the instance
will originate
- How long the instance is intended to last
- Why existing instances are inadequate to the intended use
The IT process team will review all such requests for new instances
and recommend a course of action. Such course of action may be
to approve the request, deny it with a suggested course of action
using existing instances, or approve it with suggested changes.
Requests for new instances should be made no later than two weeks
prior to when the instance will be needed to allow for IT process
team consideration.
|