COMR Process and Policy Overview

1.Process and policy has evolved over time. 2.Yes, it is confusing…but not by design. 3.Please don’t shoot the messenger! A Few Ground Rules

Two CMS documents govern COMR Process and Policy: CMS Central/Campus Development Responsibilities (DEVEL) CMS Central/Campus Development Responsibilities (DEVEL) Campus Object Migration Request (COMR) Process Guide (COMR) Campus Object Migration Request (COMR) Process Guide (COMR) The documentation

The policy document. Defines what campuses can and cannot do with campus-specific modifications. Defines how campus-specific modifications should be developed. CMS Central/Campus Development Responsibilities

The process document. Defines how campuses can get modifications approved (if necessary) and into production. Campus Object Migration Request (COMR) Process Guide

The 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 triggers Modify 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 entries Self-Service Launch Pages Workflow PeopleCode. Modify a component or page definition to enable expert entry or deferred processing. - DEVEL pg. 3-4 Except…

CMS Central/Campus Development Responsibilities (pg 3-4). This INCLUDES self-service pages. 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 Development Responsibilities (pg 3-4). This INCLUDES self-service pages. Except… (reworded)

CMS Central/Campus Development Responsibilities (pg 3-4). This INCLUDES self-service pages. 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 Development Responsibilities (pg 3-4). This INCLUDES self-service pages. Except… (reworded v2)

The “Exception” Policy 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 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 AND Contains only campus prefixed items or items that are predefined as exceptions to cloning process AND COMR 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. AND COMR 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