COVID-19
View the latest updates and emergency notifications on the COVID-19 News & Information website.
Enterprise Applications

EAPP Glossary

Table of contents:

Steering Groups

EAPP & DLT participate in a variety of steering groups that include representatives from multiple departments. Each steering group works to prioritize and coordinate the support, development, maintenance, communication, and release engineering for supported services. help to prioritize and coordinate the support, development, communication, and release engineering for supported services. Each working group meets periodically with stakeholders to discuss emerging support needs and ongoing projects.

Electronic Signature Review Group (ESRG): 

Steering group for electronic signature systems, such as Adobe Sign.

Enterprise Training Collaborative (ETC):

Steering group for training management systems, such as CSU Learn and LinkedIn Learning.

Data Analysis Working Group (Dawgs):

Steering group for PeopleSoft systems, such as the PeopleSoft CS, HR, and CFS databases.

Learning Management System Advisory Group (LMS Advisory):

Steering group for learning technologies systems, such as Blackboard Learn, Kaltura, and Zoom.

TeamDynamix Steering Committee:

Steering group for IT service management systems, such as TeamDynamix.

TeamDynamix

TeamDynamix (TDX) is the university’s enterprise IT services management system, often referred to as a “ticketing system” for IT services.

TDX includes multiple interfaces, including the customer-facing TDClient and technician-facing TDNext.

TDX Ticket Metadata

A ticket is digital record of work. Different ticket forms may track specific fields, but some fields and terms are common across all ticket types.

Age:

Days since the ticket was created.

Account/Department:

The primary group associated with the requestor.

Classification:

A broad category identifying the type of work associated with the ticket. Typically either an incident, service request, or change. See “TDX Ticket Classifications”.

Created:

The date and time when the ticket was created.

Form:

The set of fields associated with the ticket. Typically assigned by default based on the service catalog entry that was used to submit the ticket.

ID:

A unique numeric identifier for each ticket.

Modified:

The date and time when the ticket was last edited or updated.

Primary Responsibility:

The person currently responsible for handling the ticket, or “Unassigned” if the ticket is assigned to a group.

Requestor:

The person who is requesting work or reporting an incident.

Responsible Group:

The group currently responsible for handling the ticket. Typically assigned by default based on the service catalog entry that was used to submit the ticket. This may change if the ticket is escalated or reassigned.

Priority:

Low, medium, high, or emergency.

Status:

Indicates progress on the ticket. See “TDX Ticket Statuses”.

Subject:

Title of the ticket, should be a brief and memorable summary of the request.

Task:

A small unit of work within a ticket, which itself can be assigned to a group or person.

Task Template:

A standardized set of tasks that can be added to a ticket.

Workflow:

A set of automated or semi-automated steps that can be assigned to a ticket.

TDX Ticket Statuses

Each ticket has a status, which technicians update to indicate progress.

New:

Indicates that work on a ticket has not been started.

Open:

Indicates that a ticket has been accepted, but that work on it has not begun.

In Process:

Indicates that a ticket has been accepted, but that work on it has not been completed.

Pending (In Process):

Indicates that a ticket has been accepted, but that work is pending the completion of some other ticket. If possible, the ticket should be updated with a comment that explains the reason for the hold.

On Hold:

Indicates that work on a ticket has been suspended but may continue later. The ticket may be waiting for a customer response, vendor response, or technical resources. If possible, the ticket should be updated with a comment that explains the reason for the hold.

Closed:

Indicates that work on a ticket has been completed.

Cancelled:

Indicates that work on a ticket was no longer needed.

Each ticket status is associated with a status class, which can be useful for reporting and filtering.

TDX statuses for each status class

Status Class

Statuses

New

New

In Process

Open
In Process
Pending (In Process)

On Hold

On Hold

Completed

Closed

Cancelled

Cancelled

TDX Ticket Classifications

Each ticket has a classification, which broadly identifies the type of work associated with the ticket.

Change:

Identifies a work order that changes the configuration or functionality of services. The “Change Management” section of this glossary goes into more detail.

Incident:

Identifies an event which caused degradation of expected services.

Major Incident (MI):

An Incident which has significant impact, and which demands a response beyond the routine Incident management process.

Examples:

  • A widely used web service is down, and many users are not able to log in.
  • A technical glitch is affecting a crucial feature and many users have reported this.
  • An unplanned technical incident that requires communication to the campus community.

Major Incidents should be promoted from reported Incidents, based on the number or severity of incoming reports. This can be particularly useful for the help desk to keep track of ongoing issues that might generate multiple tickets.

Major Incidents can contain child tickets, which is useful for tracking the severity of the issue and for communicating to affected users.

Major Incidents will be reviewed periodically by a technical working group to ensure regular monitoring, identify opportunities for improvement, and coordinate best practices.

Major Service Request (MSR):

A Service Request which has significant impact, such as requiring several hours of work or changing a system that will impact many users.

Examples:

  • A widely used web service will be retired and migrated to a new platform.
  • A project which will add, modify, or remove services, requiring 2-80 hours of work.

Major Service Requests may be subject to additional review or approval with team managers.

Release:

Identifies a software release, especially if driven by third-party service providers, that may relate to existing services.

Service Request:

Identifies a work order that falls within current services. If the work requested falls outside of current operational standards, the ticket should be promoted to a Project (see below).

Note: TeamDynamix does not always make clear the distinction between Incidents and Service Requests.

Change Management

The Change Management process is handled by a committee that reviews TDX Change tickets before and after changes are made to production services. See also: Change Management in the knowledge base.

Area Change Coordinator (ACC):

A person who reviews RFCs prior to discussion at CAB.

Change Advisory Board (CAB):

A committee that reviews RFCs to discuss topics such as resource contention, scheduling conflicts, or cross-cutting IT concerns.

Change Calendar:

A calendar of RFCs maintained by the Change Manager.

Change Manager:

The chairperson of CAB.

Request for Change (RFC):

A Change ticket in TDX which has an IT Change Management workflow applied to it.

RFC Workflows

RFCs have one of the following IT Change Management workflows applied.

IT Change Management – Emergency (ERFC):

The ERFC must be implemented as soon as possible to resolve or avoid serious disruption in services. If possible, an ERFC should be filed and reviewed before the changes are implemented; if that is not possible, an ERFC should be filed as soon as is practical to document the changes that were made.

IT Change Management – Normal:

The RFC will be reviewed by an ACC and discussed by CAB. Most RFCs fit into this category.

IT Change Management – Standard:

The RFC will be reviewed by an ACC and does not need to be discussed at CAB. Typically only used for routine changes such as monthly patching.

RFC Metadata

RFC tickets have some specific metadata based on use of the IT Change Management forms. The primary audiences for RFC tickets are CAB, IRES management and the ITSS helpdesk.

Subject:

Must be a clear summary of the systems being modified and changes being made.

Change Impact:

Minor, significant, or major.

Change Urgency:

Low, medium, or high.

Proposed Start Date:

Date and time for the maintenance window start. Needed for Change Calendar.

Proposed End Date:

Date and time for the maintenance window end. Needed for Change Calendar.

Affected Services:

A list of services affected by the Change. For each service, specify the duration of expected downtime, or no downtime.

Additional Teams Needed:

A list of teams or resources needed to complete the Change. Mark n/a if the Change can be completed by the assigned technician acting alone.

Change Communication Target:

Will the change be communicated to All Announce, Technotice, etc?

Change Communication Content:

Draft announcement for use in Technotice or All Announce emails. Mark n/a if no such communication will be made.

Description:

Must be a clear summary of the systems being modified and changes being made.

PeopleSoft Backdoor Scripts

PeopleSoft backdoor scripts are Change tickets that require an EAPP technician to make direct modifications to the PeopleSoft database. ISEC requires additional review and logging for these Changes. These backdoor scripts will be tracked by an RFC ticket that has the following tasks applied.

Technician Peer Review:

The script must be reviewed by a peer technician.

Data Owner Approval:

An appropriate data owner must approve the change.

User Approval:

An appropriate functional user must approve the change.

In addition, backdoor script tickets should have the "peoplesoft-sod" tag applied.

Change Freezes

Change freezes may be applied during periods when system stability is imperative. Change freezes will tend to be scheduled according to the following:

  • Start of Spring or Fall semesters (general)
  • Final exams for Spring or Fall semesters (general)
  • Student registration periods (PeopleSoft only)

For an inventory of scheduled change freezes, see Add Drop Periods and Change Freezes (requires login)(opens in new window).

IT Procurement Review

The IT Procurement Review (ITPR) process reviews information technology products to determine accessibility risk, security risk, and system compatibility. An ITPR is typically required before the university will purchase or use any IT product. See also: ITPR on the knowledge base.

HECVAT:

Higher Education Community Vendor Assessment Toolkit, a type of document that is used in security reviews.

VPAT:

Voluntary Product Accessibility Template, a type of document that is used in accessibility reviews.

SOC 2 Type 2:

A security evaluation developed by the American Institute of Certified Public Accountants, also a type of document that is used in security reviews.

Projects and Operations

Operational work:

Ongoing in nature, and typically involves support and maintenance of existing services.

Project work:

Temporary in nature, and typically involves the analysis, development, and testing of changes to services, including software releases, system migrations, and service end-of-life transitions.

An operational ticket may be considered project work if it requires more than 10 hours of work, or budget over $0.

University leadership may require additional review and planning for projects that require staff time over 40 hours, or budget over $20,000.

Projects as TDX Major Service Requests

MSR Form

In addition to the standard fields listed in “TDX Ticket Metadata”, the following is a list of fields that are specific to the Major Service Request form.

Application:

Indicates the primary application(s) impacted by this project.

Project Size:

See “MSR Project Sizes”.

Tasks:

See “MSR Tasks”.

If desired, we can add links to project files, charter, scope, communication plans, etc.

If desired, we can create multiple forms, workflows, or templates based on the Project Size field (examples: S, M, L), or based on the type of integration (examples: B2, LTI, PeopleTools). Initially we will focus on the basic process, and opportunities for improvement can be identified as we go.

MSR Tasks

Work on the MSR may involve multiple teams or tickets. Creating ticket tasks can be

Work by another team or technician:

Open a task and assign it to an appropriate liaison.

Work on another ticket:

From time to time, it may be necessary to open additional tickets. When that happens, a task can be opened on the MSR to indicate the additional ticket ID. This creates a single location where all work associated with the MSR can be tracked and reported on.

MSR Change Management

When the project is ready to be deployed, technicians can create an associated RFC ticket by selecting Actions -> Create Parent.

If multiple RFCs will be required, consider opening the earliest RFCs as standalone tickets and associate them with the MSR by creating ticket tasks. The final RFC can be created as a parent to the MSR.

MSR Project Sizes

Estimating project size enables capacity planning, resource allocation, and prioritization.

The following project size estimates are derived from the implementation details of the project. If a project meets criteria of multiple size estimates, consider estimating upward.

MSR Project Sizes

Size

Notes

Estimate

S

  • Small modifications to existing functionality
  • Architecturally insignificant
  • Only involves one Team
  • Similar to work done in the past by the Team
  • No new technologies involved
  • May require new vendor contract, CSU experience

3-9 hours

M

  • Significant modifications to existing functionality
  • Minor architectural changes
  • Only involves one Team
  • Similar to work done in the past by the Team
  • No new technologies involved
  • May require new vendor contract, CSU experience

10-19 hours

L

  • No existing functionality to leverage
  • Moderate architectural changes required
  • Multiple dependencies across 1-2 teams
  • No precedents exist for the work, or no experience on the team
  • Involves new technologies

20-29 hours

XL

  • No existing functionality to leverage
  • Major architectural changes required
  • Multiple dependencies across multiple teams
  • No precedents exist for the work, or no experience on the team
  • Involves new technologies

30-39 hours

XXL

  • Too big to size; more than one project?

40-79 hours

Planner Board

The Planner Board, hosted in Office 365, can be used by team members, collaborators, and stakeholders to visualize progress on projects.

The following is a list of buckets used on the Planner Board, as developed by Applications and Data Services (ADS).

Queue:

New work that has been requested and prioritized.

Analysis:

Work is being analyzed. Gather requirements, investigate technology, try to determine rough order of magnitude.

Development Ready Queue:

Analysis is complete, and the work is waiting for an available technician. Some projects skip directly from Analysis to Development.

Development:

Main work to complete the task. Writing code, configuration servers and applications, etc.

Build Ready:

Development is complete. Project is ready for peer review and deploy to staged environment.

In Testing:

Internal testing in staged environment.

User Sign-Off:

Customer acceptance testing in staged environment.

Production Ready Queue:

Testing is complete. Project is ready for deploy to production environment.

CAB Requested:

Change requested.

Scheduled:

Change approved and scheduled.

In Production:

Change has been deployed to production environment. Projects may wait here if it’s necessary to monitor after the deploy.

Completed:

Project is complete, ready for final review by stakeholders and/or steering committee, then closure.

Parking Lot:

This is a special bucket for cards that will be on hold for an extended period. When possible, please schedule a date to review the card’s status, or make a note of circumstances that would prompt that review.