COMR Process and COMR Process and Policy OverviewPolicy Overview

1.1. Process and policy has Process and policy has evolved over time.evolved over time.

2.2. Yes, it is confusing…but not Yes, it is confusing…but not by design.by design.

3.3. Please don’t shoot the Please don’t shoot the messenger!messenger!

A Few Ground RulesA Few Ground Rules

Two CMS documents govern Two CMS documents govern COMR Process and Policy:COMR Process and Policy:

• CMS Central/Campus CMS Central/Campus Development ResponsibilitiesDevelopment Responsibilities (DEVEL)(DEVEL)

• Campus Object Migration Campus Object Migration Request (COMR) Process Guide Request (COMR) Process Guide (COMR)(COMR)

The documentationThe documentation

The policy document. The policy document.

Defines what campuses can and Defines what campuses can and cannot do with campus-specific cannot do with campus-specific modifications.modifications.

Defines how campus-specific Defines how campus-specific modifications should be modifications should be developed.developed.

CMS Central/Campus CMS Central/Campus Development Development ResponsibilitiesResponsibilities

The process document. The process document.

Defines how campuses can get Defines how campuses can get modifications approved (if modifications approved (if necessary) and into production.necessary) and into production.

Campus Object Migration Campus Object Migration Request (COMR) Process Request (COMR) Process GuideGuide

The Basic PolicyThe Basic Policy

If a campus follows these rules, they can just follow the COMR

Process Guide to get modification into production

Develop modifications to meet campus specific needs associated with reports, interfaces, workflow, self-service, and other campus-specific functionality added to the application (“bolt-ons”)

- DEVEL pg. 1

Campuses Can

Submit Crystal, nVision and SQR file objects.Any type of PeopleTools object.Workflow objects (worklist records, wf maps, wf panels, wf PeopleCode)

- DEVEL pg. 2

Campuses Can

Modify COBOL Programs and stored statements.Modify Database-level triggersModify Baseline (CMS or PeopleSoft) objects.

- DEVEL pg. 2

Campuses Cannot

Submit objects that are prefixed with campus development designations.

- DEVEL pg. 2

Campuses Must

Campus can directly modify:Message catalog entriesSelf-Service Launch PagesWorkflow PeopleCode.Modify a component or page

definitionto enable expert entry or

deferredprocessing.

- DEVEL pg. 3-4

Except…

All campus modified objects must be prefixed with the campus development designation with the specific exception of those items listed in the CMS Central/Campus CMS Central/Campus

Development ResponsibilitiesDevelopment Responsibilities (pg 3- (pg 3-

4). This INCLUDES self-service 4). This INCLUDES self-service

pages.pages.

Except… (reworded)

Campuses needing to modify a delivered object MUST clone and prefix objects with the campus development designation with the specific exception of those items listed in the CMS Central/Campus CMS Central/Campus

Development ResponsibilitiesDevelopment Responsibilities (pg 3- (pg 3-

4). This INCLUDES self-service 4). This INCLUDES self-service

pages.pages.

Except… (reworded v2)

The “Exception” The “Exception” PolicyPolicy

You can’t have a policy in the CSU without having exceptions!

Pretty much modify anything, but they must obtain CMS Senior Director approval.

- COMR pg. 5

Campuses Can

Request exception approval prior to submitting development.Submit initial request through application team project director.Agree to fully support modification.Agree to remove modification when/if PeopleSoft or CMS addresses issue.

- COMR pg. 5 (but mostly not documented)

Campuses Must

Obtain exception approval for any modification that will include an object that is not prefixed with the campus development designation.

Campuses Must

… and yes, this does include self-service.

Inventory the exception and review periodically.

CMS will also review exception list and manage support responsibilities accordingly.

CMS Must

The ProcessThe Process

How campuses move to production.

Campus begins to document business requirements that will lead to a modification. At design/requirement time campus needs to answer a few basic questions.

Process overview

First, campuses must determine if modification will require a change to a baseline object (as defined in DEVEL pg2). If yes, campus project director must submit a request for exception through the CMS application PDs to the CMS Senior PD for approval. (COMR pg 5)

Modification to baseline?

Secondly, campuses must assess if modification will the agreed upon impact thresholds (COMR pg 6).

Impact to Infrastructure?

If modification will NOT exceed threshold, then campus PD approves modification on COMR Impact Analysis form. Approved COMR Impact Analysis must be submitted along with COMR package when production migration is requested.

- DEVEL pg 6

Impact to Infrastructure?

If modification WILL exceed threshold, then campus PD recommends to the CSU COMR Impact Analysis committee for review and approval. When/If approved COMR Impact Analysis must be submitted along with COMR package when production migration is requested.

- DEVEL pg 6

Impact to Infrastructure?

An approved COMR can be submitted to CMS for final review and migration to production.

Move to production

Adheres to all policies outlined in DEVEL ANDContains only campus prefixed items or items that are predefined as exceptions to cloning processANDCOMR Impact Analysis approved by campus PD or committee.

Approved COMR?

Contains objects not prefixed with campus development designation and those items are not predefined as exceptions to cloning process and CMS Senior Director exception approval given.ANDCOMR Impact Analysis approved by campus PD or committee.

OR…

Help Desk ensures that documentation attached to all COMRs (Impact & Migration Request form).

Application Teams review to ensure items comply with policy.

Technical Services schedules and then migrates modification to production.

CMS Process

Campus direct access to production is limited. In general CMS “owns” the SYSADM account and via our Change Control Policy is responsible for production application migrations.

Campus Access to Production